Live proof artifact

One pricing exception, end to end.

This is the canonical Decide proof: a revenue-sensitive software action asks whether it should proceed, the Decision API returns a deterministic record, and the handle follows the downstream CRM or billing action.

This artifact is a representative proof run. It shows the integration API contract customers evaluate before production traffic: request, verdict, evidence, storage fields, execution receipt, outcome, intelligence readout, replay behavior, and production handoff.

Run the playground Read quickstart Request API access

Artifact review packet

Use this packet when a buyer, implementer, or security reviewer asks what exactly gets inspected before production access. It keeps the live proof tied to the same Decision Packet v1 evidence, verifier, and operational review path.

Record

Decision Record v1

Review the verdict, policy version, evidence, hashes, replay handle, and verify link before trusting the action.

Execution

Action receipt

Confirm the authorized billing or CRM mutation was attempted and bound back to the original decision.

Outcome

Business result

Attach the observed result so policy effectiveness and anomaly review have real lifecycle evidence.

Verification

Portable packet

Export Decision Packet v1, verify hashes and signatures, and forward the proof without requiring console access.

Proof pageBuyer-ready proof narrative and packet checklist. First-hour examplesInstall, call, verify, and fail-closed implementation path. Verification docsHosted, API, CLI, packet, registry, and fixture checks. Hosted verifierPaste or upload a record and inspect verification output. Status packetRuntime readiness, public monitor view, and export controls. Trust packetReview sequence for product, security, legal, and launch owners.

Artifact snapshot

The core product surface is small on purpose: one action boundary, one API call, one decision record your system can store.

POST /api/decide 200 record created

Request

{
  "question": "Approve 15% annual-plan discount exception?",
  "mode": "single",
  "context": {
    "workflow": "pricing_exception",
    "owner_role": "revops",
    "margin_floor": "passed",
    "owner_rule": "verified",
    "account_segment": "growth",
    "source_system": "crm"
  }
}

Response

{
  "decision_record_version": "decision_record_v1",
  "verdict": "yes",
  "request_id": "req_9f3c",
  "decision_id": "dec_43b2",
  "policy_id": "pricing_exception",
  "policy_version": "v3",
  "policy_bundle_hash": "b81c...",
  "evidence": ["MARGIN_FLOOR_OK", "OWNER_RULE_VERIFIED"],
  "action": "approve_discount",
  "input_hash": "8d51...",
  "output_hash": "48aa...",
  "record_hash": "7f3a...",
  "replay_url": "/api/decision/dec_43b2/replay"
}

CallerCRM or billing workflow

DecisionApprove discount

Storedrequest_id + decision_id

ReplayEvidence and hash check

Lifecycle proof pack

The strongest proof is not only that Decide can answer. It is that the answer becomes a durable protocol trail: record the authorization, receipt the attempted mutation, report what happened, then score the policy against outcomes.

1. Decision Record

Authorization

dec_43b2 approves the discount with evidence, hashes, replay, and verify links.

2. Execution Receipt

Mutation proof

exec_71af records billing mutation, executor, target object, and before/after state hashes.

3. Outcome Record

Business result

out_9a3c reports the successful discount and observed margin after action.

4. Intelligence

Policy readout

Effectiveness is healthy and anomaly review is stable for pricing_exception:v3.

Proof artifact	Endpoint	Buyer-readable readout
Decision Record v1	`POST /api/decide`	Verdict `yes`, `record_hash` `7f3a...`, `receipt_hash` `c91e...`, replay and verify links attached to the action.
Action Execution Receipt	`POST /api/decision/dec_43b2/execution`	Billing mutation `discount.create` executed against `sub_1042` with state hashes and matching action binding.
Outcome Record v1	`POST /api/decision/dec_43b2/outcome`	Outcome `succeeded`, observed `margin_after_discount: 0.182`, and outcome hash linked to the original receipt.
Policy intelligence	`GET /api/decision/policies/pricing_exception/effectiveness`	Effectiveness score `0.94`, recommendation `healthy`, anomaly recommendation `stable`.

Replay artifact

The proof is not just the first answer. The stored decision_id gives reviewers a way to compare the original record against the declared policy state later.

Replay handle dec_43b2 against pricing_exception:v3

Replay compares verdict, evidence, and record hash, so review starts from the original policy run instead of chat history or screenshots.

Replay comparison

{
  "decision_id": "dec_43b2",
  "replay_against": "pricing_exception:v3",
  "compare": ["verdict", "evidence", "record_hash", "policy_bundle_hash"],
  "replay_status": "matched",
  "drift": []
}

The end-to-end path

A customer can wire this without adopting a new workflow UI. Decide sits at the action boundary.

1. Trigger

Action requested

A discount, payout, access change, policy check, or agent step asks to proceed.

2. Decide

API returns verdict

The payload is evaluated against context, owner rule, and guardrails.

3. Attach

Record travels

The caller stores the full Decision Record v1 object next to the action.

4. Replay

Review is deterministic

Disputes use the original record instead of reconstructing a thread.

What this proves

This page is meant to remove buyer ambiguity: it shows what is purchased, where it integrates, and what evidence compounds.

Buyer pain

Money is at stake

Pricing exceptions affect margin and revenue quality before anyone talks about broad governance.

Developer surface

One endpoint

The integration can start as one POST /api/decide call that records why the system acted.

Durability

Decision records compound

Each action creates a replayable record of why software acted, which becomes harder to replace over time.

60-second demo script

Use this sequence to explain the artifact in under a minute.

What the viewer sees

A pricing exception asks for a decision before CRM or billing changes.
The application sends question, context, and guardrails to Decide.
Decide returns Decision Record v1: verdict, IDs, evidence, action, hashes, policy version, and replay URL.
The downstream system stores the record with the action.

What this clarifies

This is not another dashboard to migrate into.
The API adds a recorded decision layer at one boundary.
Pricing is only the first production boundary. The same API contract gates other actions.
The durable asset is the decision record attached to software behavior.

Production evaluation checklist

Before requesting production access, confirm these items with the workflow owner and implementation owner.

Question	Required answer	Why it matters
What action is gated?	One exact action such as approve discount, deny payout, route to owner review.	Prevents broad platform drift.
What facts enter the payload?	Owner, source system, guardrails, risk context, and any policy evidence.	Determines whether the verdict is useful.
Where is the record stored?	The full Decision Record v1 object attached to the downstream action.	Creates replay and audit value.
What happens on missing evidence?	Fail closed, route to owner review, or request more context.	Keeps high-risk automation from guessing.

Production handoff

Production access should make this proof callable by your system without widening the scope beyond the first action boundary.

Access

Server-side x-api-key calls scoped to one production boundary.

Controls

Monthly record tier, quota headers, telemetry, and replay visibility.

Evidence packet

Export Decision Packet v1 and verify hashes, signatures, execution receipts, and Outcome Records before forwarding to a buyer or security reviewer.

Launch proof

First live readout confirms stored records, review/no routing, and replay checks.

Expansion

Only after the first boundary is trusted, apply the same API contract to another gated action.