Build with Perplexity Decisions

Start from the user-visible behavior and identify the semantic judgments it requires. Keep deterministic rules and execution in application code. Preserve the user's stack and requested scope.

Choose the relevant guidance

• To investigate opportunities in an existing project, read project-opportunities.md.
• To implement or troubleshoot an integration, read implementation.md.
• To compare models, validate thresholds, or measure a workflow, read evaluation.md.
• To migrate a TypeSafe/Jev workflow, read porting-from-typesafe.md.
• To use public web evidence, read web-grounding.md to choose between built-in grounding and application-managed retrieval.

Load only what the task needs. Audit when assessing project fit or when unresolved architecture affects the work; concrete integrations need no mandatory audit. The exploration companion includes patterns and cookbook links.

Consult current documentation

Use Perplexity documentation as the source of truth:

• Index: https://docs.perplexity.ai/llms.txt ↗
• Quickstart: https://docs.perplexity.ai/docs/decisions/quickstart.md ↗
• Request/response schema: https://docs.perplexity.ai/api-reference/decisions-post.md ↗

Check relevant current documentation before implementing or claiming current models, limits, pricing, or performance; reuse sufficient documentation already checked in the task. If Markdown retrieval fails, try the ordinary page.

For a dated baseline or unavailable docs, use api-snapshot.md. Follow current docs over the snapshot and surface material contradictions. Use documented request fields and verified SDK interfaces.

Preserve the important distinctions

Use noul for yes/no probability, choice for an option, and score for an ordered rubric. noul has no separate confidence field; near 0.5 means uncertainty, not medium intensity.

Treat probabilities as model judgments requiring task-specific validation. Keep confidence distinct from the probability of the selected answer.

Standard v1.2 evaluates questions jointly within each processing group. Hosted Flash v1.2 evaluates questions separately and bills state per question. Distinguish the hosted API contract from checkpoint implementations.

Choose the evidence path deliberately: supplied state, optional built-in web grounding, or application-managed retrieval. Check evidence sufficiency separately from model probabilities. Use separate components for generated prose and execution; validate permissions and action arguments in code.

Complete the requested work

For exploration, deliver grounded opportunities and a decisive next experiment. For implementation, complete the requested integration and verify the affected behavior within the available environment.

State what was inspected, implemented, and tested. Distinguish live API results from mocked tests and unmeasured proposals. Respect the user's requested review or deployment boundary.