In this piece
Parallel Decisions API: RAG for Decision Models in Practice
A supplier adds a feature on Monday. On Friday, your qualification workflow still marks it unsupported because the model never received the announcement. A perfectly valid JSON answer can carry an outdated decision.
Parallel Decisions API combines web retrieval with bounded questions in one request. Give it context and the choices your application understands; it retrieves public evidence and returns typed answers. Your application can use those classifications once it checks whether the evidence supports the exact product, plan and date.
Parallel announced the API on 25 October 2026. Its Decisions API launch describes the combined workflow. Sources checked: . We reviewed the documentation and API schema, and tested the accompanying example with offline fixtures. Live API accuracy and latency remain untested here.
What does RAG for decision models mean?
RAG for decision models means retrieving evidence before answering a predefined question. The output might be a category, a probability or an ordered score. Parallel handles retrieval inside the request, so your application can ask for the decision directly.
The official Decisions quickstart describes shared state, named questions and typed answers. The integration combines retrieval and classification behind one API boundary.
Jev evaluates typed questions over supplied state, as TypeSafe’s introduction explains. You can retrieve current evidence and supply it in that state yourself. Our Jev decision-model guide covers that interface. Parallel packages retrieval with the decision service.
When should you use Parallel instead of separate retrieval?
Use Parallel’s integrated endpoint when you need a small answer about public information and its retrieval controls fit the task. Keep a separate retrieval layer when you need to choose the corpus, enforce access permissions or control which passages reach the model.
| Approach | Where evidence comes from | Good fit | Work you retain |
|---|---|---|---|
| Decision model over supplied state | Your application provides the relevant facts | Classifying a support ticket or a known record | Keep the supplied state current and complete |
| Separate retrieval plus a decision model | A retriever you configure, followed by your chosen model | Private documents, publisher restrictions or detailed provenance | Retrieval quality, access checks, model integration and evaluation |
| Parallel Decisions API | Public-web evidence retrieved within the service | Vendor capability checks, company classification and current-fact verification | Question design, evidence review and the application’s action policy |
For private company knowledge, enforce access permissions before supplying evidence. Our permissions-first RAG guide for SharePoint, Confluence and Drive covers that architecture.
What does the Parallel Decisions API return?
Parallel returns a typed answer for each named question and a shared citation list for the request. Its predicate type is called noul. Choices select a declared option; scores evaluate an ordered rubric. Any question can instead return a refusal. Handle the answer type before reading its value.
| Type | Question definition | Answer | Interpretation |
|---|---|---|---|
noul | A condition in instructions | noul, from 0 to 1 | Estimated probability that the condition is true |
choice | A criteria object of named options | choice and probabilities | A selected category and its distribution |
score | An ordered criteria array | score, legend and probabilities | A probability-weighted mean of zero-based level indices |
refusal | Possible for any question | No decision value or probabilities | A separate outcome that needs handling |
The question-type documentation recommends an explicit unknown choice when evidence can be insufficient. That is different from a refusal, which can result from downstream filtering. Missing documentation should not silently become a confident claim that a feature is unavailable.
The published OpenAPI schema makes confidence optional and nullable on choice and score answers; the noul answer has no separate confidence field. Preserve the selected option’s probability separately from any returned confidence. The top-level citations array can be empty and has no per-answer source mapping.
Parallel and OpenAI both have a product named Decisions API. Check the host and request shape before copying code between them. Our OpenAI Decisions API routing guide covers that provider’s interface; the example below calls api.parallel.ai.
How do you check one vendor without mixing up its products?
Name the product, plan and date in every capability question. A vendor-wide announcement may apply to only one API. Ask each product question within the shared vendor context, and offer an unknown option for missing, ambiguous or conflicting evidence.
Consider a buyer checking which Parallel APIs document EU processing under an enterprise agreement. The example asks separately about Search in basic mode and Decisions. Both questions concern product capabilities under the same agreement.
Send this JSON to POST https://api.parallel.ai/v1/decisions with Content-Type: application/json and your server-side x-api-key:
{
"mode": "fast",
"state": {
"company": "Parallel",
"website": "https://parallel.ai",
"agreement": "Enterprise agreement",
"as_of": "2026-11-03"
},
"questions": {
"search_eu": {
"type": "choice",
"instructions": "Does Parallel document EU processing for Search API in basic mode (POST /v1/search) under an enterprise agreement, as of state.as_of? Evaluate this endpoint only; do not transfer a claim about another product.",
"criteria": {
"documented_yes": "Official documentation explicitly supports this endpoint, mode and agreement.",
"documented_no": "Official documentation explicitly excludes this endpoint or requires processing outside the EU.",
"unknown": "Evidence is missing, conflicting, ambiguous, outdated or applies to a different endpoint."
}
},
"decisions_eu": {
"type": "choice",
"instructions": "Does Parallel document EU processing for Decisions API (POST /v1/decisions) under an enterprise agreement, as of state.as_of? Evaluate this endpoint only; do not transfer a claim about another product.",
"criteria": {
"documented_yes": "Official documentation explicitly supports this endpoint, mode and agreement.",
"documented_no": "Official documentation explicitly excludes this endpoint or requires processing outside the EU.",
"unknown": "Evidence is missing, conflicting, ambiguous, outdated or applies to a different endpoint."
}
}
},
"advanced_settings": {
"include_excerpts": true
}
}The Decisions best-practices guide recommends grouping related questions over shared evidence. A request for official documentation guides the model but cannot enforce a source allowlist. The as_of field supplies task context; historical snapshots and fetch-time controls require separate support.
Download the Node.js vendor-check example for Node.js 22 or later. It includes the request builder, timeout handling and response review. The JSON above matches its 3 November 2026 default; the following caller explicitly substitutes today’s UTC date. Save it beside run-example.mjs containing:
import {
buildRequest, requestDecision, reviewAnswer
} from "./parallel-decisions-vendor-screen.mjs";
const request = buildRequest(new Date().toISOString().slice(0, 10));
const response = await requestDecision(request, {
apiKey: process.env.PARALLEL_API_KEY
});
for (const name of Object.keys(request.questions)) {
console.log(name, reviewAnswer(response, name));
}Run node run-example.mjs with your key set in the environment. This caller makes one API request under the published tariff. Importing the module alone makes none. The offline tests use synthetic responses to check application behavior; they do not measure retrieval quality.
How should the application use shared citations?
Treat Parallel’s citation list as shared evidence to inspect. Before accepting a capability, check a passage for the exact endpoint, agreement, region and date, then attach that passage to the individual claim in your workflow. A source in the shared list may support only one question.
| Observed result | Meaning | Next step |
|---|---|---|
| Documented yes or no, valid distribution, usable citation excerpts | A formed classification with candidate evidence | Inspect whether a passage supports this exact claim |
unknown | The declared evidence category is unresolved | Request better evidence or contact the vendor |
refusal | The provider declined that question | Record the refusal and use the review path |
| Missing answer, malformed distribution or transport failure | The integration has no usable answer | Keep the record unresolved; diagnose or retry under a bounded policy |
| Empty citations or no usable excerpts | The example lacks inspectable evidence | Retrieve evidence separately before accepting the claim |
The helper requires HTTPS source URLs without embedded credentials and at least one nonempty excerpt. These are local review rules we chose for the example. Passing them produces evidence_review, a queue state that still requires checking source support. Set any later automation threshold from labeled application cases.
Keep the raw distribution, optional confidence, decision_id, request version and response receipt time. Record source publication and retrieval times separately when available. A Search residency page could accompany both classifications while supporting only one; field-level attribution needs its own verification.
What does batching cost?
Parallel lists Decisions at US$1 per 1,000 requests, with up to 100 questions in each request. Grouping related checks for the same vendor can reduce request charges. Verify the current tariff before budgeting.
The official pricing page gives that tariff as checked on 3 November 2026. For an illustrative workload of 10,000 vendors with three related questions each, one request per vendor gives 10,000 × US$0.001 = US$10 in listed request charges. Three requests per vendor would give 30,000 × US$0.001 = US$30.
This request-cost illustration excludes retries, infrastructure, additional research and human review. Track cost per accepted, evidence-supported record alongside API spend.
Group related questions about the same entity. Split batches when evidence becomes difficult to attribute, or when one question needs another’s result before it can be defined.
Can you enforce fresh sources or EU processing?
The reviewed Decisions contract does not establish forced source freshness or EU processing. Its advanced settings expose search location and excerpt inclusion. Enforced publisher allowlists, publication-date filters and fetch policies are not documented for this endpoint.
Parallel’s Source Policy guide documents domain and freshness controls for other APIs. When those controls are acceptance requirements, retrieve evidence through an API that supports them and pass it to a separate decision step.
The EU data-residency documentation covers Search in basic mode and Extract under an enterprise agreement. Decisions needs its own confirmation. The advanced_settings.location field targets search geography; processing residency is a separate requirement.
For dated checks, record what the source says and when it applies. Historical decisions need retained evidence or a suitable archive. Confirm the provider and data flow before adding private customer documents to a test.
What do the benchmarks establish?
Parallel’s benchmark compares complete API configurations with different access to web evidence. Its results help choose a baseline to test on your own workload; they do not isolate the underlying classifiers' accuracy.
The PWS-Decisions published methodology describes 300 questions, with 100 public and 200 private. Competing native decision endpoints received the same state and questions without supplied web context. Read the headline comparison with that configuration in mind.
For three runs conducted on 29 October 2026 over 300 questions, Parallel’s recorded results report 76.22% accuracy for its endpoint and 97.33% for a separate Luna configuration with native web search. The search-enabled configuration had higher reported cost and latency. These are vendor measurements on that challenge set. Compare complete workflows when choosing your baseline.
How would we evaluate this before rollout?
We would evaluate whether each classification is supported by the right evidence before allowing it to change a business record. Start with one decision type and dated reference cases. Include easy positives, explicit negatives and cases where the correct outcome is unresolved. Run the candidate beside the existing workflow until the errors are understandable.
| Case | What the test should detect |
|---|---|
| A capability launched or withdrawn recently | Whether the classification reflects the applicable source and date |
| Same company, different plan or endpoint | Whether a broad announcement leaks into an unsupported product claim |
| Missing or contradictory documentation | Whether the workflow preserves uncertainty instead of inventing a negative |
| A plausible citation that concerns another entity | Whether evidence review catches a correct-looking answer with the wrong support |
| Sources in each production language | Whether translated product names and qualifiers preserve the same decision |
Label the expected answer and its supporting passage separately. Report how often accepted records are correct and supported, how many need review, and which wrong records escape review. Measure end-to-end latency and the cost of completing a record, including follow-up work.
Our starting recommendation is a bounded vendor-screening or enrichment pilot with an explicit evidence review step. Choose the decision and its failure cost first. If you want help turning that into a product workflow, our AI product and agent development service is the relevant next step.
Parallel Decisions API questions
Can I try Parallel Decisions through MCP?
The reviewed quickstart lists the web_decisions tool in Parallel’s MCP server at https://mcp.parallel.ai/mcp, with free use without an account or API key and higher limits after sign-in or authentication. That is an access route for an MCP client. The direct HTTP example in this article requires your API key and uses the published request tariff.
Can I use a noul probability as a boolean?
A noul answer is a number between 0 and 1. In JavaScript, even a small nonzero number is truthy, so an if statement over the raw value is unsuitable. Define and evaluate a decision rule explicitly. For documentation checks where missing evidence matters, a choice with an unknown option usually expresses the task more clearly.
Can one question depend on another answer in the same request?
Group questions when each can be defined from the shared state. If question B needs the returned value of question A, our recommendation is to wait for A, validate it and construct B in a subsequent request. Do not treat a questions object as a sequential program or assume its key order establishes a dependency.
Can Parallel Decisions update my CRM automatically?
The decision response supplies data for your application. A separate integration must authorize and perform a CRM update. In our example, evidence_review is a queue state for checking the evidence, not permission to write an approved-vendor flag. Tie any eventual update to the reviewed claim and the record version you intended to change.
Does a score always correspond to one rubric level?
No. A score is the probability-weighted mean of zero-based level indices, so it can fall between levels. For example, probabilities of 0.25 and 0.75 on levels 0 and 1 produce 0.75. Interpret that value under your rubric; use choice when the application needs one discrete category rather than an average.
Should I evaluate German, Spanish and Chinese sources separately?
We recommend testing every language your workflow will encounter. A product can use different plan names or publish a change in one language first. Keep reference answers tied to dated evidence and inspect translation-sensitive qualifiers. Good results on an English test set do not establish the same evidence quality for another language.