S0
Invalid
Condition code != OK
This receipt is cryptographically invalid, structurally broken, or tampered with. Do not trust it.
Developers
Sigils S0–S6
Sigils are deterministic trust marks computed by verification — never awarded manually. The same receipt bytes always produce the same Sigil for a given verifier implementation.
S1
Draft
Condition code = OK, on_log = false, and no stronger mapping applies
The receipt has basic cryptographic structure but minimal verification. It's a "draft" state — valid but not fully assured.
S2
Scoped
Condition code = OK, on_log = false, 2 ∈ dotSet, and no stronger mapping applies
The receipt is valid and operating within defined bounds (egress limits, resource constraints).
S3
Governed
Condition code = OK, on_log = false, 3 ∈ dotSet, and 4 ∉ dotSet, 5 ∉ dotSet
The receipt is valid with policy and routing rules applied, but not yet "Proven" (offline-valid) or "Recorded" (on-chain).
S4
Proven
Condition code = OK, on_log = false, 4 ∈ dotSet, and 5 ∉ dotSet
Cryptographically valid anywhere, anytime; no network call is required because mathematics alone carries the validity guarantee.
S5
Recorded
Condition code = OK, 5 ∈ dotSet, and on_log = true
Valid AND permanently recorded on ZK-AI Chain. Anyone can verify it was anchored at a specific time with an inclusion proof.
S6
Hardened
Condition code = OK, 6 ∈ dotSet, and hybrid = true
Quantum-resistant signature protection. The receipt has both classical and post-quantum signatures. Future-proofed against next-generation attacks.
Sigil-first interpretation
Default views show the Sigil computed from verifier output. DoT levels, profile IDs, and raw verifier codes belong in details view. 3DVC is a separate certification mark — not required to interpret Sigils.
Offline vs on-log
S4 (Proven) means cryptography carries validity without a network call. S5 (Recorded) adds governed on-log witness evidence via attachments. S6 (Hardened) adds post-quantum hybrid signatures over the same preimage.