Foundation 01 · System boundary
What Receiz establishes
Receiz is an authority architecture and proof-native artifact system. Reproducible law and verifiable evidence carry truth; infrastructure serves, synchronizes, projects, coordinates, admits, displays, or interprets that truth beneath its authority boundary.
What this enables
The solved state
You can Record a moment as a sealed PNG proof object or Seal an existing file as a proof object, then preserve, inspect, and verify either artifact without surrendering authority to a screen or session.
Governing statement
The Dependency Test
Remove the database. Remove the API. Remove the network. Remove the interface. Remove the model. Remove the login session. Remove the clock server. Remove Receiz infrastructure itself. Ask what must remain knowable. If determining the valid state requires calling Receiz, the architecture is incomplete.
Receiz moves authority out of infrastructure and into portable proof, deterministic transition law, identity evidence, reproducible temporal law, and retained history. Infrastructure serves the state. It does not create the state.
- What was broken
- Conventional review can assume that a privileged server, authoritative database, timestamp service, model, session, or coordination layer must ultimately define truth beneath the proof object.
- What is established
- The server may coordinate state. It does not define state. The database may project or index state. It does not become canonical truth. The API may transport state. Its response is not proof. The receipt may report an accepted operation. It is not the authority that made the operation valid.
- What you can do now
- The interface may display identity. It does not create identity. The model may reason over memory. It does not own memory. The network may synchronize descendants. Connectivity does not retroactively create local validity.
- Why it matters
- Chronos may translate temporal position into conventional time. It does not originate Kai. The Kai-Klok does not require an authoritative server clock; it is deterministic, public, and independently implementable temporal law.
A holder can verify a sealed artifact, resolve its accepted history, inspect its identity evidence, and compute its Kai coordinate without asking a Receiz server, database, API, session, model, interface, network, or clock service to create that truth.
docs/reality-grade-systems-kernel.mddocs/invariant-first-kernel.mddocs/chronos-causality-kai-time-kernel.md
- STATE
- proof object
- HISTORY
- append-only accepted transition chain
- IDENTITY
- portable identity evidence / seal
- AUTHORITY
- explicit actor and operation law
- TIME
- Kai-Klok deterministic temporal law
- MEMORY
- retained identity-bound state derived from verified history
- SERVER
- publication, synchronization, indexing, mirroring, discovery, and named-domain coordination beneath already-valid truth
- DATABASE
- projection/index/cache beneath settled truth
- AI
- interpreter/reasoner over state
- INTERFACE
- presentation
Governing statement
Do Not Import the Old Architecture Into This One
Traditional application architecture often starts from these assumptions: the server owns state; the database is canonical; the server timestamps mutations; the session defines identity; the API response represents current truth; model context represents memory. Receiz does not start from those assumptions.
Receiz starts from one question: What must remain verifiable and reconstructable when the infrastructure surrounding the state disappears, disagrees, or is unavailable?
- What was broken
- A sophisticated engineer can accurately recognize conventional distributed-system mechanics and still misclassify those mechanics as Receiz authority.
- What is established
- Truth, verification, admission, execution, coordination, synchronization, projection, presentation, and interpretation are separate operations and must not be used interchangeably.
- What you can do now
- You can place expected-head binding, atomic commit, conflict detection, receipts, and Settlement beneath the authority model without weakening any of their guarantees.
- Why it matters
- Those mechanisms govern acceptance, conflict, and connected-domain coordination; they do not convert infrastructure into the source of the proof object's validity.
An API receipt can prove that a declared operation was accepted atomically against an expected head while the proof object and transition law remain the authority that makes the accepted state verifiable.
docs/invariant-first-kernel.mddocs/verified-history-first-principles.mdpackages/receiz-sdk/src/artifactAdmission.ts
Governing statement
Reproducibility Is the Trust Boundary
The strongest test is not whether Receiz-operated infrastructure works. It is whether an independent implementer can reconstruct the relevant machinery from the published law.
Do not trust the Receiz clock service. Implement Kai-Klok. Do not trust the Receiz database. Verify the object. Do not trust the current UI state. Resolve the accepted history. Do not trust a model’s narration. Read the retained state. Do not trust a current human retelling of prior state. Inspect the preserved chronology.
- What was broken
- Availability, institutional continuity, or a current representation can be mistaken for the trust boundary of the state it serves.
- What is established
- Portable proof, deterministic transition law, identity evidence, retained accepted history, and reproducible Kai law preserve the independently checkable machinery.
- What you can do now
- You can reproduce the relevant verification and derivation path without granting Receiz-operated infrastructure privileged epistemic status.
- Why it matters
- The architecture remains inspectable under origin-system loss, disagreement, disconnection, and hostile interpretation.
An independent verifier starts from held bytes and published law, recomputes integrity and accepted history, and treats UI, API, model, and database projections as removable representations.
docs/reality-grade-systems-kernel.mddocs/offline-verified-register.mdpackages/receiz-sdk/src/artifactVerification.ts
Governing statement
The Extinction Test
Suppose all Receiz-hosted infrastructure disappears. A holder retains the sealed artifact, the published protocol and specification, the necessary public verification material, the Kai-Klok specification, compatible verification code or enough specification to reproduce it. Artifact validity, integrity, accepted history contained by the object, identity evidence contained by the object, deterministic Kai temporal coordinates, and local state derivation remain establishable.
Local possession does not reveal state the holder never received. Discovery of later competing descendants, admission into a separate external domain, and synchronization with unseen state may require broader communication. None of those later knowledge events creates an accepted local Settlement.
- What was broken
- Independent local verification can be overclaimed as knowledge of every unseen descendant or as universal global finality.
- What is established
- Local validity and local Settlement are distinct from global knowledge and external-domain admission. The proof object establishes the claims supported by its carried evidence and accepted history; later sync changes distribution, not truth.
- What you can do now
- You can state exactly what survives infrastructure loss and exactly which discovery, admission, or coordination questions remain external to the held object.
- Why it matters
- Receiz removes unnecessary infrastructure authority without pretending that local possession grants omniscience about competing or later state.
A disconnected holder can validate an artifact and derive its known local state, but cannot claim knowledge of a later competing descendant that the holder has never received.
docs/offline-verified-register.mddocs/verified-history-first-principles.mdpackages/receiz-sdk/src/causalReplay.ts
Governing statement
One Rule
If a weaker representation can disappear without destroying the underlying truth, the representation must never be promoted above that truth.
Proof outranks presentation. Verified history outranks projection. Identity evidence outranks session. Deterministic temporal law outranks server timestamps. Retained state outranks model context. The source outranks the representation.
- What was broken
- Convenient representations acquire accidental authority when their disappearance is confused with the destruction of the truth they display.
- What is established
- Every representation remains explicitly beneath the durable source that survives it.
- What you can do now
- You can classify a proposed server, database, API, AI, session, clock, or interface dependency before it enters the architecture.
- Why it matters
- The system can improve coordination and presentation without re-centralizing truth.
Removing a database projection may remove an index, but it cannot invalidate the sealed proof object, its verified history, identity evidence, or deterministic Kai coordinate.
AGENTS.mddocs/receiz-reasoning-kernel.mddocs/reality-grade-systems-kernel.md
Governing statement
The artifact carries the truth
Receiz is a proof-native artifact system, not an application that adds proof after the fact.
The proof belongs to the object itself. The screen displays the object; it does not become the authority merely because it displays it.
- What was broken
- Ordinary digital records depend on an account, database, or interface to say what happened.
- What is established
- A Receiz artifact carries deterministic identity, sealed payload truth, provenance, and verification material.
- What you can do now
- You can keep, move, inspect, and verify the object as the same proof object across ordinary interface and session boundaries.
- Why it matters
- The proof object and its carried verification material remain legible when a screen changes, a session ends, or a weaker service is unavailable.
A sealed record remains the same proof object when it is downloaded, reopened, inspected, or presented on a public proof surface.
AGENTS.mddocs/receiz-reasoning-kernel.mdpackages/receiz-sdk/src/artifacts.ts
Governing statement
Artifact truth comes before distribution
The sealed artifact alone carries the proof-bearing public URL and the evidence required for local inspection and verification. No API, server, database, account, session, or prior publication is required. Append means a separately verified successor that extends proof history. Server distribution means publication, synchronization, indexing, mirroring, and discovery of already-valid proof objects and successors. Distribution does not append to the proof object.
Record or Seal first creates and saves the complete proof object. Its embedded bundle deterministically projects the receiz.com verification route. Verify reads the object itself. A lawful Append may later create a new verified successor. Export saves that successor unchanged. A server may then help other people find the predecessor or successor, but it neither creates the link nor completes the proof.
- What was broken
- Conventional application reasoning can invert the sequence by asking a server to create, confirm, or publish truth that the sealed artifact already carries.
- What is established
- Receiz starts from exact held bytes, projects the self-carrying proof URL locally, verifies locally, appends only through a separately verified successor, and treats server distribution as optional propagation beneath both objects.
- What you can do now
- You can Record or Seal, automatically save, open the proof-bearing receiz.com route, inspect, verify, append a lawful successor, and export without any API or server dependency.
- Why it matters
- Removing connectivity may reduce discovery of unseen history, but it cannot remove the held object's identity, verification route, carried evidence, local verdict, or lawful successor history.
Workbench reads the embedded receiz.proof_bundle from a recorded PNG, builds its compact proof-bearing /v route locally, renders that route as a clickable QR, and never calls an API to make the route valid.
docs/offline-record-seal-frozen-invariants.mdapp/lib/documentSeal/proofBearingVLink.tsreceiz-docs/lib/workbench/public-proof-link-runtime.tsreceiz-docs/test/workbench-public-proof-link.test.tsx
Governing statement
Record Moment and Seal File are separate entry operations.
Record Moment creates a sealed PNG proof object for this moment. The file carries the statement, deterministic identity, Kai time, integrity proof, provenance, and its verification route. Seal File creates a sealed proof object for an existing file, binding its exact source bytes. Both save automatically and continue through Verify → Append → Export.
Record Moment accepts optional text, including no text, and returns the moment card. Seal File starts from a file you already have. Neither operation requires the other.
- What was broken
- A captured moment can be copied, separated from its origin, or presented without a durable way to inspect what it is.
- What is established
- Record Moment returns a deterministic sealed moment proof object; Seal File returns a deterministic sealed file proof object.
- What you can do now
- You can present the recorded moment together with the proof that establishes its identity, integrity, and provenance.
- Why it matters
- The recorded claim and the proof that establishes it remain one durable object instead of becoming disconnected assertions.
Typing a moment claim—or leaving it empty—and pressing Record Moment returns the ‘This happened.’ PNG. Uploading an existing PDF to Seal File returns the sealed PDF artifact.
docs/offline-record-seal-frozen-invariants.mdapp/lib/documentSeal/prepareNativeProofObjectSeal.tsapp/lib/documentSeal/__tests__/offlineRecordSealFrozenInvariantContract.test.ts