Verifiable receipt
The receipt is the durable proof.
It binds boundary status, owner context, commitment ID, and signature material in one machine-readable record.
Enterprise activation path
Prove what was authorized before a high-risk action proceeds.
Craton adds an independently verifiable receipt layer before irreversible actions execute. Before execution, Craton returns a signed record that is verifiable offline, without relying on Craton's runtime. Your host keeps execution control; Craton supplies the pre-execution proof layer.
01 / Define
One covered path
02 / Review
Scope baseline
03 / Sign
Documents
04 / Pay
Activate API
05 / Verify
First receipt
Primitives
One receipt your auditors and systems can verify.
Before the action moves, Craton returns signed evidence your team can store with the downstream record and verify without calling Craton back.
Audit review
Evidence before execution
Show what was evaluated, which boundary applied, and which commitment was signed before the action proceeded.
Verification
Independent by design
Verify with Ed25519, the public JWKS, and the published Craton protocol. No callback required.
Host control
Your systems remain in control
Craton returns signed evidence; your host system decides how to apply its policy.
Protocol resources
Public, stable references
Review the protocol, verifier, schema, JWKS, and offline verifier kit from public resources.
Short version
Define the action, sign the receipt, verify it later.
One risky action becomes one boundary check, one signed receipt, and one audit-ready proof reference.
Define. Evaluate. Sign. Verify.
Craton receives the boundary request and returns a signed receipt the host system can carry forward.
Define
Define one covered action
The path is scoped to a specific high-risk action, system, owner, and threshold.
Evaluate
Evaluate before execution
The host calls Craton before the action moves and receives the boundary result.
Sign
Sign the result
The receipt keeps the commitment and verification material together.
Verify
Verify without callback
Anyone with the receipt, schema, and public key can verify the evidence later.
Start
Describe the covered action that needs pre-execution proof.
Start with the action. Craton maps it to a signed boundary path and asks only for the facts needed to issue verifiable receipt evidence.
Describe only the action you want covered. Craton maps the boundary and receipt evidence, not your full business payload. The path can be prepared from the scope facts you provide here.
Use one concrete action with the trigger, amount, or review gap if you know it.
Your boundary path is taking shape.
What Craton understood
The action crosses a threshold before it moves.
Mapped path
Before a high-risk action moves through the operations system, owned by the policy owner.
Your setup path
Start with one action.
Define result handling policy
Three policy outcomes are required: proceed, pause, and block.
Describe when the host should continue and what record it keeps.
Describe when the host should pause before it moves.
Describe when the host should stop the action as outside policy.
This only clears these draft answers.
Scope status
Scope summary is ready because the business response is complete.
Your action
Describe the action to get the next step.
Optional: see how Craton interpreted your action and view mapping examples.
Why this next step matters
Path posture pending action description.
Why
Craton keeps deeper checks here after the path is clear.
What unlocks
A concrete action unlocks the path.
Later
Shown after the path is narrow enough to save.
Next path
Real high-risk path, owner-controlled readiness.
Proof later
The machine-verifiable boundary result appears after the path clears contract, signing, and payment gates.
Path detail
Kind
Threshold Boundary
Activation
Automatic or pending CRATON review
Likely owner
Risk, finance, operations, or the named accountable owner.
Status
Needs one clear action. Describe the action so Craton can map the first boundary path.
Example patterns
Craton recommends the boundary pattern automatically. These options are available for teams that want to inspect or override the mapping.
01 / Threshold Boundary
Threshold Boundary
Before it executes, the boundary is already fixed.
Technical label
gate_type: threshold_gate
02 / Decision Identity
Decision Identity
The same boundary result survives every handoff.
Technical label
gate_type: decision_identity
03 / Break-glass Exception
Break Glass
Exceptions can happen, but they must leave proof.
Technical label
gate_type: break_glass
04 / Proof Reference
Proof Reference
A completed action leaves independently verifiable evidence.
Technical label
gate_type: audit_artifact
01 / THRESHOLD BOUNDARY
Before it executes, the boundary is already fixed.
When a high-risk action has a clear trigger, Craton fixes the boundary before execution and returns a machine-verifiable boundary result. Whatever the host does next, the signed receipt can be verified and carried forward.
Do you have a high-risk action with a clear trigger, but no fixed boundary before execution?
Technical label
gate_type: threshold_gate
Pattern / Threshold-triggered
A high-value transfer crosses an internal threshold. Before execution, the host system requests a boundary check and receives a machine-verifiable boundary result that can be carried forward.
Price and activation context
Coverage detail
Assignment
Calculated from the configured path.
Pricing
Shown after path configuration.
Client control
Craton assigns activation and price from the path's coverage, owner, and organization scope.
How buying works
Complete the first deployment stage.
Start with one high-risk action. Craton turns it into a machine-verifiable boundary path, then provisions API access after signing and payment are confirmed. Broader rollout can be added later through continuation or expansion documentation.
Protocol and verification resources
API calls return receipts that can be verified independently.
Contract, readiness packet, protocol spec, schema, and standard public keys.
Endpoint
POST /v1/boundary/check
Required
Company account, boundary, covered system, decision type, and decision owner.
Optional
Decision size, case ID, external reference, context.
Signed receipt
Boundary status, commitment ID, payload, signature.
Verify
Ed25519 / kid=k1 / public key from /protocol/v1/jwks.json
Continue
Pass the commitment ID downstream as the external reference.
Compact request and signed receipt shape
POST /v1/boundary/check
Request includes: boundary="privileged exception", covered system="operations console", decision owner="risk owner"
{ "verdict": "constrain", "commitment_id": "bnd_01J7X8...", "sig_alg": "ed25519" }
01
Call at the boundary
Send partner, gate, system, decision type, and owner before the action moves.
02
Read the result
The response includes verdict, receipt, commitment ID, and request ID.
03
Verify
Use the public protocol and keys to verify the receipt payload.
04
Carry forward
Pass commitment_id as the downstream reference.
After first path
After the first path, continue or expand from a signed baseline.
Save the path first. Continuation, expansion, and end-state choices stay available after the initial scope is clear.
Post-first-path choices
Continue
Continue current coverageKeep this production-bound boundary path covered through continuation coverage.
Expand
Expand this boundary pathAdd gate, system, authority, or new-path coverage from the current path.
End
Initial scope completedThe result remains available if production coverage does not continue.
Later: review expansion draft
Expansion draft
Current coverage
Primary path mapped
New coverage
Decision identity / Operations system
Why
Multiple gates in the same system should share signed-result semantics.
Live changes
No. Requires deployment review.
Expansion packet
{}
Scale
One pre-execution path first. Then expand the boundary.
Start with one machine-verifiable path. Add new gates, systems, or organizations only after the first runtime receipt exists.
Dimension 01
Path expansion
Add another action under the same gate when it can share the same receipt shape.
Dimension 02
Gate expansion
Decision identity, threshold checks, manual override, and risk escalation. Each gate adds a new boundary surface without changing the primitive.
Dimension 03
Cross-system
Carry the recorded result from one internal system into another after the runtime receipt exists.
Dimension 04
Cross-org
When multiple organizations depend on the same runtime boundary receipt, Craton becomes shared infrastructure.