Skip to main content
Outcome: submit one industry case and explain the resulting decision using its model readings, evidence admission, and policy proof. This walkthrough uses the retail pack; the same request builder supports all seven industries.

Choose the correct API

The public response wraps the decision in result. The direct engine returns the decision at the top level. A pack’s industry and scenario identifiers alone are not a direct-engine decision request. See public first decision for the shorter demo path.

1. Confirm your engine and credentials

Use Bash, curl, jq, and Node.js 20.20+. Set the variables below through your normal credential mechanism. NSR_BASE_URL is the trusted engine origin without a /v1 suffix; use HTTPS outside local development. An NSR key authenticates your tenant access. A Jev key pays for the model readings and is not interchangeable with the NSR key.
Proceed only if that check succeeds. Capability discovery describes support; it does not prove your Jev key is valid or that a provider call will succeed. Direct calls do not retrieve the Jev key saved in the console. Use a test organization for these synthetic cases.

2. Build a complete request locally

Download the retail pack as 04_retail.json and the request builder as build-request.mjs. Inspect both files, then run:
This step is offline. It preserves the pack’s rules and trust requirements, replaces {subject} in the model questions, and translates fixture age_secs values into provenance.observed_at. Generate shortly before a test; keep the emitted JSON to preserve what you submitted. Do not refresh real evidence timestamps this way. The builder excludes judge, expect, and other test metadata. Jev must produce the readings for the actual request. hydrate_org_context: false avoids adding the org knowledge base to this example; it does not bypass authorization, tenant controls, or all organization policy.

3. Understand the request before sending it

Keep the authorization goal, evidence subjects, and judgment subjects aligned. For a real integration, facts come from verified records and the policy comes from your controlled configuration. Neither is supplied by an untrusted customer or generated to obtain approval.

4. Submit one decision

This step makes live model calls and may incur usage. It evaluates permission; it does not execute the refund. Continue in the shell configured above:
Inspect the curl exit status and HTTP status before treating the file as a decision. There are no automatic retries in this example. A timeout leaves the outcome unknown; public-demo idempotency capabilities do not establish the same behavior on the direct engine endpoint.

5. Read the decision, not just HTTP 200

Treat routing.band == "escalate", evidence.requires_human_review, and refusal.requires_human_review as review signals. An approved result is not an instruction to skip confirmation or execution controls. denied and refused are both non-authorizing outcomes, but only a denial establishes an applicable blocking policy; a refusal may mean missing evidence, uncertainty, or review is needed.
Complete when: you can identify the subject and goal, explain the readings and admitted evidence, and point to the rule result or refusal reason. An approval is not required. Retain the exact request, response, and request/decision identifiers according to your data policy.

6. Compare a boundary or conflict

Build RT-4010 to inspect contradictory authoritative amounts, or RT-4013 to inspect the amount above the transit-damage cap. Run each as a separate, deliberate call and save its request and response under a distinct filename. Do not automatically loop over 106 live cases. The fixture expects refusal for both, with human review in RT-4010. Compare the evidence and proof, not just the verdict. For another industry, download its pack and use its scenario ID with the same builder. The public demo catalog and this snapshot can differ.

7. Move from a test to an application

Keep four responsibilities explicit: your backend gathers authentic records, your policy defines permission, NSR evaluates it with Jev readings where needed, and your executor carries out an authorized operation. Recheck resource state and permission at execution time and use the downstream service’s idempotency contract. A decision ID or external_ref alone does not deduplicate a payment. When available, retain and verify the original verifiable_bundle using the proof-verification workflow. Do not rebuild a bundle from a few displayed fields. A valid derivation proves the relationship between supplied premises and rules; it does not independently authenticate real-world records. Record the actual outcome through the outcome loop to evaluate policy performance rather than counting approvals as successful business actions.

Troubleshooting

Source basis: nsr-app/src/industryPacks.ts, server/public-jev.mjs, and stateset-nsr/src/api/handlers/decisions.rs and src/api/jev_credentials.rs, reviewed 2026-09-21. The downloadable builder is tested offline across all 106 cases; this guide does not claim live provider verification.
Last modified on September 21, 2026