> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stateset.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Jev + NSR Industry Pack Examples
> Explore 106 scenarios across seven industries and learn how model readings, trusted evidence, and explicit policy produce a decision.
**Start with a business question:** should this refund, credit, or authorization proceed?
Each pack supplies a policy, model questions, evidence requirements, and cases that exercise
the boundaries. Jev reads the message; NSR evaluates the premises and policy. Your application
handles any subsequent business action.
These seven packs contain 106 synthetic scenarios. Their thresholds are demonstration policy
choices, not legal, medical, or contractual standards. Expected outcomes use controlled model
readings; a live Jev run can differ. Review your actual policy before adapting a pack.
## Pick an industry
Open the [public demo](https://nsr.stateset.com/jev), or select an industry in your signed-in
Playground. The public demo fixes the policy and evidence; the private Playground lets authorized
users edit them. Check the deployed catalog for available scenario IDs.
| Industry and pack download | Decision | Start with | Then compare |
| ------------------------------------------------------------------------ | ------------------------------------ | --------------------------------- | ------------------------------------------------------------------------------------------ |
| [Financial services](/examples/jev/packs/01_financial_services.json) | Provisional credit on a card dispute | `TX-1001`: ordinary dispute | `TX-1004`: over cap; `TX-1006`: abuse deny; `TX-1012`: conflicting amounts |
| [Travel and hospitality](/examples/jev/packs/02_travel_hospitality.json) | Compensation for a delayed flight | `BK-2001`: carrier delay | `BK-2003`: short delay; `BK-2004`: weather deny; `BK-2007`: conflicting records |
| [Healthcare](/examples/jev/packs/03_healthcare.json) | Imaging prior authorization | `PA-3001`: documented case | `PA-3004`: safety deny; `PA-3006`: untrusted allegation; `PA-3010`: conflicting diagnoses |
| [Retail](/examples/jev/packs/04_retail.json) | Damaged-goods refund | `RT-4001`: cracked mug | `RT-4002`: confirmed return; `RT-4005`: abuse deny; `RT-4010`: conflicting prices |
| [Telecommunications](/examples/jev/packs/05_telecommunications.json) | Outage service credit | `AC-5001`: material outage | `AC-5003`: short outage; `AC-5005`: arrears deny; `AC-5010`: conflicting feeds |
| [Technology](/examples/jev/packs/06_technology.json) | SaaS overage credit | `ACC-6001`: incident-driven usage | `ACC-6002`: SLA evidence; `ACC-6004`: terminated contract; `ACC-6011`: conflicting amounts |
| [Media](/examples/jev/packs/07_media.json) | Failed-stream refund | `EV-7001`: delivery failure | `EV-7002`: blackout; `EV-7006`: open chargeback; `EV-7011`: conflicting telemetry |
Downloads are the reviewed documentation snapshot. Financial services has 16 cases; each
other pack has 15. The deployed catalog can change independently.
## Read one retail case end to end
In `RT-4001`, the shopper says the box arrived crushed and the mug is cracked. The order system
supplies an amount of 45 and an order placed two days ago. The pack asks Jev three questions:
| Predicate | Type | What the policy does with it |
| ------------------ | ------------------ | ----------------------------------------------------- |
| `damage_plausible` | `noul` probability | Requires at least `0.8` for the transit-damage permit |
| `damage_kind` | `choice` | Requires `transit` for that permit |
| `abuse_signal` | `noul` probability | A reading of at least `0.7` satisfies a deny rule |
The fixture supplies `0.93`, `transit`, and `0.04` respectively. These are **test inputs**, not
promised live readings. NSR then checks:
1. The order and amount meet their source-trust and freshness requirements.
2. The amount is at most 200, damage is plausible enough, and the kind is transit.
3. The serial-returner condition does not block the permit; rejected evidence cannot simply
be treated as proof that a disqualifier is false.
4. No applicable deny or review condition supersedes permission.
The controlled case expects `approved`, with `refund_transit_damage_under_cap` as the relevant
permit. Inspect the actual returned proof, model readings, and review signals after a live run.
The API has evaluated `may_refund(RT-4001)`; it has not sent money.
## Learn from the neighboring cases
| Scenario | Controlled expectation | Lesson |
| --------- | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| `RT-4002` | `approved` | A warehouse-confirmed return has a separate permit with a 1,000 cap; the amount is 890. Low damage plausibility need not block that separate route. |
| `RT-4005` | `denied` | A satisfied abuse deny can override a permit. |
| `RT-4006` | `not_approved` | Instructions inside the message cannot rewrite policy. The case also tests an over-cap amount. |
| `RT-4007` | `refused` | A shopper's claimed price cannot substitute for the authoritative order amount. |
| `RT-4008` | `refused` | Rejecting an untrusted allegation of serial returns does not establish that the allegation is false. |
| `RT-4010` | `refused`, human review | Authoritative claims of 150 and 950 conflict; `order_amount` is functional and its conflict policy is `escalate`. |
| `RT-4013` | `refused` | An amount of 201 exceeds the transit-damage cap despite a plausible complaint. |
`not_approved` is a fixture assertion accepting either `denied` or `refused`; it is not a fourth
API verdict. These scenarios can change several inputs at once. For a causal comparison,
duplicate one case in the private Playground and change only the field you are studying.
## What the other industries teach
### Financial services: arithmetic boundaries and explicit denies
The sample provisional-credit permit requires a filed dispute, an amount at most 2,500, a
plausibility reading at least `0.7`, and no blocking prior-abuse premise. `TX-1003` sits exactly
at the cap; `TX-1004` is one cent over it. `TX-1006` demonstrates the separate fraud-pattern
deny. These are pack rules, not an implementation of all card-dispute obligations.
### Travel: measurements and causes belong to evidence
The sample permit requires a flown seat, a carrier-caused delay of at least 180 minutes,
claim specificity at least `0.7`, and no prior compensation. Compare `BK-2002` with `BK-2003`
for the time boundary. A weather cause satisfies the deny in `BK-2004`; changing the passenger's
wording does not change the operations feed.
### Healthcare: rejected evidence is not a negative fact
`PA-3006` supplies an untrusted allegation of a contraindication. The admission gate rejects
the claim, but that does not prove the absence of a contraindication required by the permits.
The expected result is refusal. `PA-3007` provides the allegation from the trusted pharmacy
source and also blocks permission. This illustrates evidence semantics, not a clinical workflow
validated for patient care.
### Telecommunications: a persuasive complaint cannot alter network data
The example requires at least 240 outage minutes, a monthly charge at most 150, and a
genuineness reading at least `0.7`, along with the remaining policy premises. Compare `AC-5002`
and `AC-5003` at the outage boundary. `AC-5014` shows that a high retention-risk reading does
not create a policy exception.
### Technology: separate permits need separate evidence
The incident permit caps credit at 5,000 and requires attribution of at least `0.75`.
The SLA permit caps it at 25,000 and requires `sla_breach_attested`. Compare `ACC-6001` and
`ACC-6002`, then inspect the source and trust requirement that admits the SLA premise. A
fixture's provenance label does not itself verify a signature or establish a real SLA breach.
`ACC-6011` exercises contradictory authoritative amounts.
### Media: telemetry, complaint type, and duplicate-payment guards
The failed-delivery permit requires at most ten delivered minutes, price at most 60, and a
delivery complaint matching the failure strongly enough. The blackout permit has its own 200
cap. `EV-7004` and `EV-7005` test the minute boundary; `EV-7006` demonstrates the chargeback
deny. Complaint classification alone cannot issue a refund.
## Understand the pack file
| Field | Meaning |
| ---------------------- | ------------------------------------------------------------------------------ |
| `action` / `goal` | Business operation and exact predicate to prove for the scenario subject |
| `rules` | Explicit permits, denies, conditions, and conclusions |
| `judgments` | Typed Jev questions, criteria, and optional complementary question |
| `source_trust` | How this demonstration policy classifies each evidence source |
| `premise_requirements` | Required trust, freshness, functional values, and conflict handling |
| `scenarios[].facts` | Claims and provenance for a case; `age_secs` is a fixture convenience |
| `scenarios[].message` | Untrusted text supplied as judgment context |
| `scenarios[].judge` | Controlled readings for the engine test harness; never submit as live evidence |
| `scenarios[].expect*` | Assertions for tests; not request fields or guarantees |
The [Decisions API walkthrough](/guides/jev-decisions-api) provides a builder that converts any
downloaded pack scenario into a complete request. It expands the subject, materializes fixture
timestamps, and excludes test-only readings. You do not POST the pack file itself.
## Adapt a pack to your system
Start in a test organization. Replace sample amounts and thresholds with reviewed business
policy. Map each authoritative premise to a connector or record your backend actually
verifies; do not let a customer choose a source label, trust map, or authorizing rule.
Keep the original observation times on real records.
Preserve tests for ordinary approval, an explicit deny, missing evidence, stale evidence,
conflicts, an untrusted allegation, and injected instructions. Run a small shadow evaluation
before connecting execution, retain the evidence and policy version, and compare outcomes
with what operators actually decided. Every live Jev test can consume provider usage.
Build a full request, submit it once, and read the decision and evidence.
Connect your organization and edit policy, evidence, and saved tests.
Source basis: the seven `nsr-app/public/industry-packs` files, `src/industryPacks.ts`,
and `stateset-nsr/src/api/handlers/decisions.rs`, reviewed 2026-09-21.
[Snapshot provenance](/examples/jev/manifest.json) records the exact pack hashes.