Runtime Proof

Prove one action can be gated.

Decide is strongest when every claim points back to a software action that required a deterministic verdict before it changed state: the API contract, request-linked evidence, replay, source-backed reference applications, and protected telemetry.

Reference applications: source-backed checks, hosted products built on Decide, and execution gates.

Live proof artifact Runtime docs Book workflow review Request API access Protected telemetry

Proof review packet

Use this packet when a buyer, developer, or security reviewer asks “what exactly proves the Decision API is working?” It keeps the proof path anchored to one action boundary, the records produced, and the public artifacts that can be inspected.

1. Inspect
Start with the live proof artifact: request, Decision Record, execution receipt, Outcome Record, and intelligence readout.
2. Run
Use the first-hour examples path to install the SDK, run the lifecycle proof pack, and wire one fail-closed action.
3. Verify
Check exported records or packets against hashes, receipt signatures, public keys, and lifecycle links.
4. Review
Use status, security, trust, and terms pages to separate proof artifacts from commercial or compliance claims.
Canonical artifactLive proof artifactCanonical request to Decision Record to execution to outcome path. Implementation packetFirst-hour examplesInstall, run proof pack, verify packet, and gate one action. Production docsVerification docsRecord, packet, receipt, key, and conformance checks. Live verifierHosted verifierPaste or upload records for browser-side verification checks. Public readinessStatusOperational readiness, public monitors, and exportable readiness view. Buyer packetTrust packetForwardable buyer review sequence for security, legal, engineering, and operations.

Forward the same proof packet to the reviewer who owns the next question.

Flagship proof artifact

The primary proof run is a pricing exception because it is concrete, monetizable, and easy for buyers to understand: software wants to change state, but the action needs a deterministic decision record first.

Use the live proof artifact as the customer-facing version of this proof run.

Boundary Input Required output Downstream action
Pricing exception Approve 15% annual-plan discount exception? Decision Record v1: verdict, IDs, evidence, action binding, policy version, receipt hash, verify URL, and replay URL. CRM, billing, queue, or agent records approve / review / deny with the decision record attached.

Lifecycle proof path

The proof now reads past the first verdict: a Decision Record authorizes an action, an execution receipt proves the attempted mutation, an Outcome Record reports the result, and policy intelligence turns those outcomes into effectiveness and anomaly review.

Record
decision_record_v1 binds verdict, evidence, policy bundle, hashes, replay, and verify links.
Receipt
decision_execution_v1 records target system, mutation, executor, state hashes, and action binding match.
Outcome
decision_outcome_v1 links business result and observed metrics to the original Decision Record.
Intelligence
Effectiveness and anomaly reports show whether the policy is healthy after real outcomes arrive.

Copy the runnable path in Developer Examples.

Contract invariants

These are the parts a customer can build against. The reference apps exist to prove the same primitive in more than one workflow, not to make the product story bigger than the API.

Same input
Same decision context returns the same verdict unless declared state changes.
One handle
Every production call carries request_id, decision_id, record_hash, and receipt_hash for logs, dispute review, verification, and replay.
Evidence first
The response explains why the action was approved, blocked, escalated, or ranked.

Customer evaluation checklist

A serious proof run should answer these questions before production access is approved.

Action boundary
What exact software action is blocked until Decide returns a verdict?
Source facts
Which fields prove owner, guardrail, margin, eligibility, or risk context?
Downstream record
Where will request_id, decision_id, action_binding, hashes, and evidence be stored?
Failure behavior
Does the caller approve, deny, review, retry, or fail closed when evidence is missing?
Owner
Who can change the guardrail and who reviews disputes?
Success metric
Which rollout metric proves the integration is worth keeping?

Proof hierarchy

Decide proof should read in this order: first the API contract, then one monetizable boundary, then reference applications and hosted products that show the same API contract can travel.

1 · Primitive
/api/decide returns a deterministic Decision Record v1 object.
2 · First boundary
Pricing exceptions prove the API contract on a revenue-sensitive action before CRM or billing changes.
3 · Applications
Source-backed checks and hosted product examples prove the same decision layer in adjacent workflows without changing the core API contract.

Built on Decide

Decide is the reusable engine. Krafthaus is a hosted product layer built on Decide, useful as proof that the Decision API can power packet reviews, memos, policy-facing product surfaces, and execution-gate demos without becoming the application itself.

Krafthaus
Decision memo and packet workflows that use Decide as the underlying decision engine.

Open Krafthaus

Policy product page
A Krafthaus product page for refund, cancellation, return, and trial checks while stable MCP and REST remotes stay on Decide.

Open policy page

Execution gate demo
A Solana-facing example where a proposed action becomes a decision packet before value moves.

Open demo

Known limits

These are intentionally explicit so customer conversations stay clean.

Playground
The public playground is a sandbox for payload and API-fit checks, not a production runtime.
Commercial controls
Production auth, quotas, retention, and contracted uptime/security terms require a paid API tier or enterprise agreement.
Reference apps
Reference routes are stable proof surfaces. The core product remains the Decision API contract.

Runtime proof snapshot

Protected production telemetry confirms that access requests, delivery, and decision-signal events are instrumented. Public values stay limited by design; authenticated metrics expose the full readout.

Protected
Access requests (24h)
-
Inbound API access and rollout requests captured in the last 24 hours.
Delivery success (24h)
-
Requests delivered to primary or backup access destination.
Delivery failures (24h)
-
Failures that should trigger follow-up and alert review.
Decision API signals (24h)
-
Events tagged with decide/decision for product activity checks.
MCP signals (24h)
-
Events tagged with MCP or reference application tool names.
Total tracked events (24h)
-
All runtime events during the latest 24-hour window.
Top Event (24h) Count
Public telemetry is limited by design; authenticated review exposes full production counters.

Public telemetry scaffold. Full production metrics are available under authenticated review.

Decision-boundary scorecard

Use this structure when one workflow moves from manual judgment to a deterministic API call. Keep baseline, target, and current values visible in one place for weekly readouts.

Escalation Rate
Baseline / Target / Current
Formula: escalated decisions ÷ total decisions handled.
Track by decision boundary and outcome class.
Handle-Time Variance
Baseline / Target / Current
Formula: spread between p90 and p50 handling time.
Measure only comparable action intents.
Dispute Readiness
Baseline / Target / Current
Formula: minutes to produce dispute evidence pack.
Evidence pack must include request_id and rationale trace.

What gets measured in every rollout

Metric Definition Collection Method Cadence
Escalation rate Percent of decisions escalated from the automated path. Source-system tags + decision run logs joined by workflow ID. Weekly
Handle-time variance Spread in resolution time for the same action class. Source-record timestamps grouped by decision intent and verdict. Weekly
Dispute readiness Time to assemble evidence for chargeback/dispute cases. request_id + deterministic rationale retrieval from audit trail. Per incident + monthly summary

Verification model

Every run logs the Decision Record v1 object, latency, and replay metadata. Reviews use this data to compare manual handling against API-gated execution.

Weekly rollout readout structure

Week Decision scope Required output
Week 0 Baseline extraction Decision boundary, metric formulas, and baseline values frozen.
Week 1-2 Routed decision rollout Daily run logs with request_id mapping to source records.
Week 3-4 Outcome comparison Before/after scorecard with variance analysis and exception list.

Minimum evidence packet

Use this package for customer sign-off, implementation reviews, and procurement diligence.

Trust escalation: start with a Decision Record. Add verification samples, Decision Packets, and audit-chain checks when the boundary becomes production-critical.

Decision Packet v1
Exported packet containing the Decision Record, optional input, execution receipts, Outcome Records, policy intelligence, chain hints, and packet_hash.
Runtime export
CSV or JSON export of decision runs including status, latency, source boundary, and request_id.
Verification samples
Representative record or packet checks that show hash integrity, receipt verification, replay behavior, and action mapping.
Packet anatomyWhat belongs in a portable Decision Packet. Packet verificationHow to verify exported records and packets. Security packetData boundaries, shared responsibility, and current security posture.