Approve. Deny.Or safelyrefuse.
One API call returns an accountable outcome grounded in your rules and facts—with cited proof, explicit uncertainty, and no path from an ungrounded model answer to approval.
Endpoint response
POST /v1/decisions
Deterministic payload
{
"decision_id": "dec_9f2c4c1e…",
"decision": "approved",
"confidence": 0.85,
"rationale": "Within return window",
"proof": {
"cited_rules": ["may_refund"],
"symbolic_steps": 2,
"neural_steps": 0,
"proof_score": 0.90,
"proof_status": "grounded"
},
"action": {
"name": "issue_refund",
"ready": true,
"rule_name": "may_refund"
},
"grounding": { "status": "grounded" },
"usage": { "billable": true, "elapsed_ms": 12 }
}Outcomes
3
Default mode
Safe
Proof
Cited rules
Idempotent replay
24h
Classify
Returns approved, denied, or refused. Safe mode is the default, and ambiguity resolves to refusal instead of a guessed authorization.
Three outcomes • safe by default • human-review signal
Prove
Returns cited rules, symbolic and neural step counts, proof strength, grounding status, and an optional full trace for forensic review.
Cited rules • proof score • grounding • optional trace
Operate at scale
Score batches with per-item evidence, retry safely with idempotency keys, inspect recent decisions and stats, and meter each outcome explicitly.
Batch • idempotency • analytics • usage metering
Safety is measured, not implied.
The repository harness runs nine labeled commerce, access-control, supply-chain, and lending cases through the real backward-chaining engine. It exits non-zero on an unsafe approval or missed quality floor.
100%
Decision accuracy
7 / 7 grounded cases
100%
Refusal correctness
2 / 2 under-grounded cases
100%
Proof validity
4 / 4 audited approvals
0
Unsafe approvals
CI failure threshold
Accountability is part of the response shape
This is not another classifier wrapped around an LLM. The API is built so a consequential outcome must be grounded, provable, and safely refusable.
Refuses Safely
Refused is a first-class outcome when the engine cannot ground a decision well enough to be accountable.
Ungrounded, ambiguous, failed, or human-review cases stop instead of becoming confident approvals.
Proves Every Verdict
Every accountable outcome carries the rules, proof strength, grounding status, and reasoning step counts behind it.
Operators can inspect cited rules and see exactly how much symbolic, neural, and planner work contributed.
Reasons Recursively
Backward chaining resolves policies that depend on other policies instead of flattening them into prompt text.
Transitive access, chained eligibility, and multi-level product or supply-chain logic remain explainable as proof paths.
Contains the Neural Layer
Models read messy language and propose candidates. Explicit rules and facts remain the source of authority.
The response exposes neural step counts, making model involvement visible instead of hiding it behind a fluent rationale.
Measures the Outcome
Decision IDs, latency, billing, proof depth, and cited rules make the API operational as well as explainable.
Recent-decision and aggregate-stats endpoints support monitoring, while response headers expose cost and quota inline.
From natural language to an accountable verdict
Every call follows the same five-stage path: frame the goal, ground it in policy, prove it recursively, verify the evidence, and classify the outcome.
Turn a request into an accountable goal.
1. Frame
The API frames the natural-language query and optional action as a decision that must be authorized, not as a prompt that merely needs an answer.
- Accepts a query plus an optional action such as issue_refund.
- Defaults to safe mode for the most thorough verification path.
- Carries caller session context and bounded solver overrides when needed.
A consequential request enters as a decision goal, not an invitation to improvise.
Put a provable authorization step in front of consequential actions
Use the same three-outcome API across CX, subscriptions, fulfillment, and agent tool use—one decision at a time or in metered batches.
Refunds and Replacements
Merchant problem
Teams need to move fast on damaged orders and wrong-item tickets without opening the door to leakage, abuse, or inconsistent policy handling.
How StateSet solves it
Send the request, action, order facts, and refund rules to the Decisions API. It returns approved, denied, or refused with the exact policy evidence needed before money or inventory moves.
Outcome profile
- Auto-approve low-risk cases with explicit boundaries.
- Block or escalate suspicious cases instead of hallucinating customer service gestures.
- Give operators a clear audit trail when exceptions happen.
A fluent answer is not an authorization
Prompts and retrieval can improve language. The Decisions API adds the outcome contract, proof, refusal path, and production controls consequential actions require.
Let models propose. Make consequential actions prove they are allowed.
StateSet's Verified Decision API adds approved, denied, and safely refused outcomes—with recursive policy proofs, explicit grounding, safe retries, batch processing, and outcome-level metering.
Approved
grounded authorization
Denied
explicit policy block
Refused
safe human review
What merchants get