ReceizAcademy

Search the complete system

Foundation 02 · Primary unit

The proof object

A proof object has stable identity, verifiable payload or integrity material, inspection behavior, durable state, and a source of truth stronger than display state.

What this enables

The solved state

You can test whether an object carries proof, locate its authority boundary, and verify the stronger artifact before trusting an embedded projection.

Governing statement

Five conditions establish a proof object

A proof object carries stable identity, verifiable material, inspection behavior, durable state, and a source of truth stronger than generic display state.

You can identify the object, test its integrity, inspect what it proves, keep the truth across ordinary interface boundaries, and point to an authority stronger than the current screen.

What was broken
A visual item can display a claim while carrying no durable identity, integrity test, provenance, or independent verification path.
What is established
The proof-object contract requires all five conditions instead of accepting appearance as evidence.
What you can do now
You can distinguish a proof object from an ordinary display item by testing observable properties.
Why it matters
Proof becomes an enforceable object contract rather than a label placed on a screen.
Established example

A sealed artifact with deterministic identity, embedded proof, verifier behavior, durable bytes, and sealed-file authority satisfies the proof-object contract.

How the result is proven
  • AGENTS.md
  • packages/receiz-sdk/src/artifacts.ts
  • packages/receiz-sdk/src/artifactVerification.ts

Governing statement

Verify the stronger enclosing artifact first

An embedded subpayload may validate its projection, but admission, ownership, access, transfer, Settlement, and public proof bind to the enclosing stronger proof object unless Receiz law defines a separate sealed object.

A correct inner hash proves that the inner data stayed consistent. It does not automatically grant the authority carried by the sealed object around it.

What was broken
A self-hashable fragment can be mistaken for the authority of the complete artifact that carries it.
What is established
Verification begins with the enclosing sealed artifact and projects embedded data only after that stronger proof passes.
What you can do now
You can reject a valid-looking fragment when the artifact that should authorize it fails verification.
Why it matters
A weaker projection cannot bypass ownership, admission, transfer, or Settlement law.
Established example

The verifier authenticates the sealed artifact bytes first, then parses the embedded payload. A failed artifact rejects the payload even when the payload hash matches.

How the result is proven
  • AGENTS.md
  • docs/sigil-registry-proof-payload-kernel.md
  • packages/receiz-sdk/src/artifactAdmission.ts