Compliance Envelope v1 · evaluate → seal → verify
Policy decisions you can carry with you.
The Compliance Envelope evaluates one action against an immutable, versioned policy you
published, and returns allow, deny, or review — together
with a sealed record of why. The verdict, every rule outcome, the state of every
source it consulted, and the exact policy version are written into write-once evidence
storage with an audit receipt, then published at a verification URL and as a signed bundle
anyone can check offline.
The authoritative description of the deployed API is the Compliance Envelope v1 specification. Everything on this page is a plain-language reading of it.
Policy evidence
The problem: the decision survives, the reasoning doesn't
Most systems record that a payment was approved, a login was allowed, or a document was released. Almost none of them can later reproduce why. The rules have been edited since. The sanctions list has moved on. The vendor that answered the call has no record of that specific question. Six months later, the honest answer to "what policy was in force and what did it see?" is usually a shrug and a database row.
Mutable rules
If the policy can be edited in place, an old verdict has no fixed meaning. Compliance Envelope ruleset versions are immutable and identified by a hash of their canonical rules, so an old verdict still points at the exact policy that produced it.
Silent degradation
The dangerous failure isn't a source going down — it's a source going down and the system returning allow anyway. Here a missing or unavailable required source produces review, and names itself in the record.
Self-describing logs
A log that only its own operator can vouch for is an assertion. The sealed record is content-hashed, carries an audit-chain receipt, and is published at a verification URL that needs no credentials.
How it works
Publish an immutable policy
Create a ruleset, then publish a version containing up to 32 rule primitives. The version is stored with a SHA-256 hash of its canonical rules and the engine version that will run it. Publishing the same configuration twice is rejected rather than duplicated.
Evaluate an action
Post the action, its parties, the ruleset, and an idempotency key. Pin a specific ruleset version, or let it resolve to the current one. Replaying the same key with the same body returns the original record; replaying it with a different body is refused as a conflict.
Seal before answering
The privacy-safe record is written to the evidence vault, an audit receipt is written to the chain, and the index row is written — in that order. No verdict is issued at all if the audit receipt cannot be written.
Charge last
The credit is consumed only after every integrity operation has succeeded. An infrastructure failure must never consume a customer credit, so a failed seal costs nothing and produces no record.
Verify, publicly or offline
The response carries a public verification URL and a bundle URL. The bundle is a signed factset you can check with a zero-dependency verifier, with no network access and no call back to CapchaCloud.
Re-screen without rewriting
Re-screening is a new evaluation that references the prior record, never a mutation of it. The change in source state between the two is itself recorded, so drift is visible rather than silently absorbed.
Three verdicts, and the precedence between them
Each rule returns its own outcome. The envelope's verdict is the most conservative one present: any deny wins; otherwise any review wins; only an unbroken set of allows yields allow.
allow
Every rule was satisfied against a source that actually answered. It means the policy passed — not that the action happened.
review
Something needs a human. A required source was missing, unavailable, or returned a potential match; a threshold was breached; a referenced piece of evidence didn't resolve. This is the fail-safe direction, by design.
deny
A hard policy condition matched — an exact sanctions hit, a blocked jurisdiction, a deny-list match, or a consent reference the policy required and could not resolve.
Fail-closed is enforced, not encouraged. If a rule's own evaluation throws, it is recorded as a safely-failed source and pushed to review — never dropped, never optimistically allowed.
What a policy can express
Eight rule primitives, composable up to 32 per ruleset version, over an action of type payment, login, document_signature, agent_action, iso20022, banking, or other, with up to 16 parties.
| Primitive | What it evaluates | Behavior when its source can't answer |
|---|---|---|
sanctions | Screens the named parties against a versioned OFAC/SDN source; the record keeps the list version and its hash per result. | review, with the source's status recorded |
geofence | Party jurisdictions against an immutable blocked-country list, hashed into the record. | review when a required country is missing |
amount_velocity | This action's amount plus the tenant's rolling 24-hour count and sum for the same subject. | review when the velocity source is unavailable |
new_payee | Whether the payee has prior sealed history for this tenant — a first-time payee forces out-of-band confirmation. | review; never fabricates "not new" |
human_bot | A referenced prior sealed human-check record, scoped to your tenant. | review when the reference is missing or cross-tenant |
identity_assertion | A referenced prior sealed identity record, which must also match this action's subject. | review on any mismatch |
consent | A referenced consent record resolvable within your tenant. | deny when required and unresolvable; review when the source itself is down |
custom_list | Your own deny list or allow-only list, matched on hashes, with the list configuration hashed into the record. | review when a required allow-list entry is absent |
The sanctions primitive screens against the same OFAC/SDN service you can exercise yourself in the live sanctions demo. That service matches on exact-normalized strings only — case-fold, diacritic-strip, punctuation-collapse, then exact equality; no fuzzy, phonetic, or partial matching. A "clear" result means no exact-normalized hit against that list snapshot. It is not a compliance clearance.
What the sealed record contains
The evidence written to the vault uses schema compliance-envelope-1.0.0 and is deliberately privacy-safe: raw party references and the raw action reference are not retained in the sealed record — only their hashes.
| Field | Purpose |
|---|---|
| Evidence id | The ce_… identifier you reference from your own systems and from later evidence. |
| Action type and reference hash | What kind of action was evaluated, and a hash that reproduces its identity without exposing the reference itself. |
| Subject hash | A canonical hash over the parties' roles and references — comparable across evaluations, not reversible to the raw values. |
| Ruleset id, version id, version label, config hash, engine version | The exact immutable policy that ran, and the engine that ran it. |
| Verdict | allow, deny, or review. |
| Reasons | Per primitive: its own verdict, a human-readable detail line, and the source data behind it — including list versions and list hashes for sanctions. |
| Sources | The state of every consulted source, including the ones that were unavailable. Absence is recorded, not omitted. |
| Related evidence ids | Up to 16 references binding this decision to other sealed evidence — an earlier evaluation, an authentication record, a signature envelope, an ISO 20022 message, a proof record. |
| Request hash | A canonical hash of the exact request, which is what makes idempotent replay safe and a changed replay detectable. |
| Vault hash, audit receipt id, chain hash | Where the record lives, the receipt proving it was written to the audit chain, and that chain position. |
| Sealed-at timestamp and advisory note | When it was sealed, and the standing statement that this is compliance evidence only. |
The public verification endpoint returns this record plus its chain-inclusion state. The bundle endpoint returns it as a signed factset with an explicit does_not_prove field carried inside the bundle itself, so the boundary travels with the evidence instead of living only on this page.
Integration
The canonical call, from the v1 specification:
POST /api/v1/evaluate
Authorization: Bearer cc_live_...
Idempotency-Key: customer-action-00042
{
"action": {"type":"document_signature","reference":"signature-request-42"},
"parties": [{"role":"signer","reference":"person_opaque_1","jurisdiction":{"country":"US"}}],
"ruleset_id":"crs_...",
"related_evidence_ids":["ce_..."]
}
The surrounding endpoints:
POST /api/v1/compliance/rulesets # create a ruleset
POST /api/v1/compliance/rulesets/{id}/versions # publish an immutable version
POST /api/v1/evaluate/{evidence_id}/rescreen # new evaluation, references the prior one
GET /api/v1/evaluate/verify?evidence_id=ce_... # public record + inclusion state
GET /api/v1/evaluate/{evidence_id}/bundle # signed, offline-checkable factset
And to check a bundle yourself, with no network access and nothing installed but Node:
curl -O https://capchacloud.com/verify-evidence-bundle.mjs curl -o bundle.json "https://capchacloud.com/api/v1/evaluate/<evidence_id>/bundle" node verify-evidence-bundle.mjs bundle.json
The bundle's factset is Ed25519-signed and checkable against the public key published at the chain pubkey endpoint. If a signing key is not configured on a deployment, the bundle states signed: false plainly — the content and its hash are still independently recomputable, and CapchaCloud never fabricates a signature.
Pricing
Evaluate + seal
Verification
One pool, one bill
A failed evaluation costs nothing. The credit is consumed only after the vault write, the audit receipt, and the index write have all succeeded; if any of them fails, the partial record is removed and no credit is taken.
What this does not prove
These boundaries are not marketing hedges — the first three ship inside every evidence bundle as a does_not_prove field, so they travel with the record.
- Not regulatory approval, legal compliance, or execution of an action. The bundle proves only the sealed evaluation record and its stated integrity evidence.
- Not proof that anything happened. CapchaCloud does not execute, settle, custody, issue, hold, freeze, or reverse funds or any other action. An
allowis a policy verdict, not a transaction; whether the calling system then honored or refused the action is outside this record. - Not a guarantee that the inputs were correct. The record proves what the sources said and when. It does not vouch for the underlying vendor or data being right.
- A sanctions "clear" is not a compliance clearance. It means no exact-normalized hit against a named list snapshot, from a matcher that does no fuzzy, phonetic, or partial matching.
- Not legal advice, and not a certification. This is technical evidence infrastructure. CapchaCloud holds no SOC 2 or ISO 27001 report today and claims no regulatory approval for this product.
- Storage is hash-verified, not automatically operator-proof. Evidence objects are content-addressed and hash-verified; write-once retention applies where the underlying bucket retention lock is configured. We do not treat a hash chain alone as operator-proof WORM hardware.
- Chain inclusion matures. A freshly sealed record carries its audit receipt immediately; full Merkle inclusion and external anchoring follow as blocks are produced and anchors settle. The verification endpoint reports the real state rather than an optimistic one.
- Not Gordian Envelope or IETF conformance. We align conceptually with hierarchical, digest-bound evidence, but the wire format is canonical JSON with SHA-256, Ed25519-signed factsets, write-once records, and signed Merkle blocks — not dCBOR or Gordian Envelope. We claim no conformance to either.
Questions people actually ask
What stops someone editing an old verdict?
Nothing edits it — there is no update path. Re-screening creates a new evaluation that references the prior record, and the change in source state between the two is recorded as its own event. Ruleset versions are immutable as well, so the policy behind an old verdict cannot be quietly rewritten either.
What happens if I retry a request?
The idempotency key is required. Retrying with the same body returns the original sealed record, flagged as a replay. Retrying the same key with a different body is refused as a conflict rather than silently producing a second, contradictory record. A request still in flight returns an explicit "in progress" response with a retry hint.
Does the record contain my customers' personal data?
The sealed record is privacy-safe by construction: the action reference and the party references are hashed, not stored raw. That is also why re-screening asks you to resubmit a fresh canonical input rather than replaying stored personal data.
How does this relate to CapchaSign, CapchaVerify, and CapchaShield?
They produce evidence; the Compliance Envelope decides over it. A CapchaSign envelope, an authentication record, or a screening result can be referenced as related evidence, and the identity_assertion, human_bot, and consent primitives check those references within your own tenant before allowing anything on their basis.
Can I try it without wiring anything up?
Yes. The live synthetic demo is a bounded, no-input production demonstration that seals server-generated synthetic evidence for a live versioned-source sanctions deny, a deliberate missing-credential unavailable-source review, and an immutable ruleset revision. The unavailable-source case proves fail-closed behavior; it does not claim the upstream source is down.
Seal a decision and try to break it
Publish a ruleset, evaluate one action, then download the bundle and verify it offline. The whole loop fits in an afternoon and costs 12 credits.
v1 specification · Technical overview · Compliance & trust program · Evidence methodology · CapchaSign