Proof Object First
Proof Object First
Receiz v108 restores the direction of authority: the same account remains the actor, the complete artifact remains intact, and every application, adapter, database, and server remains beneath the proof it serves.
I am publishing the full release book for Receiz v108.0.0: Proof-Object-First Authority.
This release is not primarily about adding another feature.
It is about correcting something more fundamental:
Which part of a digital system is allowed to decide what is true?
Most software quietly answers that question in the wrong direction.
A database row can overrule the identity it was supposed to describe.
A session can become more authoritative than the person already admitted through it.
A developer adapter can begin imposing requirements on the native application it was built to expose.
An extracted payload can be passed around as though it were equivalent to the complete signed artifact that originally contained it.
A server projection can replace known local truth simply because the network responded later.
And when these authority inversions accumulate, the user may still appear to “own” an account, file, asset, profile, or record—but only for as long as the surrounding infrastructure agrees to continue recognizing it.
Receiz was built to reverse that relationship.
The proof object comes first.
The server serves it.
The database projects it.
The application renders it.
The SDK adapts it.
MCP exposes it.
AI skills teach agents how to operate beneath it.
Documentation describes it.
Release evidence confirms that the implementation still honors it.
None of those layers may silently become stronger than the proof itself. receiz-v108-proof-object-first-release-book.pdf
⸻
The regression was small. The constitutional problem was not.
The immediate correction in v108 involved established profile behavior.
A first-party profile save had been routed through a developer-operation preflight. That developer path consulted a newer identity_keys projection and could reject an account that Receiz had already admitted.
On the surface, this could look like a normal profile-saving bug.
But the deeper problem was an inversion of authority.
An authenticated account was already present.
Its identity continuity had already been accepted.
Yet a weaker, later, potentially missing database projection was being allowed to re-decide whether that same account could act.
That cannot be the law.
A projection may help describe an identity. It may help synchronize it, discover it, index it, or make it easier for another service to interact with it.
But the projection is not the identity primitive.
A username is also not the identity primitive.
A username can change. The account UID does not.
So in v108, an inline rename or full profile save remains the action of the same already-admitted account before, during, and after the mutation.
Global username uniqueness is coordinated at commit time.
The prior username is released only after a successful change.
The public profile projection refreshes.
But the underlying actor does not disappear and re-enter existence simply because a mutable label changed.
The same account performs the save.
That sounds obvious when stated plainly.
Yet much of modern software is constructed in ways that allow secondary tables, delayed services, stale indexes, or newly introduced developer layers to contradict what the system already knows.
V108 freezes the opposite rule:
A weaker projection cannot re-decide an admitted identity.
Zero identity_keys rows is valid for an already-admitted account.
A missing projection is not proof of mismatch.
A delayed projection is not proof of mismatch.
A failed service lookup is not proof of mismatch.
A contradiction requires actual contradictory evidence.
Absence is not contradiction.
Infrastructure unavailability is not identity invalidation.
And a developer rail may never acquire the power to deny the native operation it was created to expose.
⸻
Developer tools conform downward
The SDK is not a second Receiz.
MCP is not a second Receiz.
An AI skill is not a second Receiz.
They do not invent parallel authority models.
They adapt authenticated intent into the same native commands already governing the first-party system.
The direction matters.
The native profile operation does not call into a developer abstraction and ask whether the first-party user is allowed to exist.
The developer abstraction composes the native operation.
The SDK calls the typed Receiz.com adapter.
MCP calls the current SDK.
AI skills teach the same boundary.
Each layer moves downward toward the primitive.
None of them may climb upward and become the primitive.
This is the difference between an ecosystem extending a system and an ecosystem gradually replacing the system’s constitutional center.
Receiz supports developers precisely because that center is defined.
A developer can create new applications, interfaces, markets, games, agents, records, and experiences without needing to reinvent identity, custody, verification, or continuity.
But compatibility does not mean dilution.
Every new surface must preserve the same authority direction.
⸻
Native Record. Then Seal.
V108 also makes the proof-object creation boundary exact.
A proof object is not merely a payload with a convenient extension.
It is not a JSON object wrapped in branding.
It is not an extracted record that can be repackaged later and still be called equivalent.
A current proof object is issued only after the native Record → Seal path succeeds.
Integrity verification must pass.
Signature V4 must pass.
Owner, record, claim, path, and payload bindings must pass.
If those conditions do not pass, no downloadable proof artifact is issued.
This is essential because there is a difference between possessing some data that once appeared inside a proof and possessing the complete proof object itself.
The artifact’s bytes are indivisible.
The SDK must retain the exact runtime-issued native bytes.
A download must return those complete bytes.
The digest must survive a round trip.
The artifact may not be silently unpacked, reconstructed, relabeled, or replaced with its embedded payload.
The complete carrier verifies first.
Only after the enclosing artifact verifies may payload extraction occur as a deterministic projection.
Domain-specific parsers receive verified payload bytes.
They do not receive arbitrary carrier input and hope the surrounding proof was probably valid.
This sequence prevents a subtle but devastating class of downgrade:
A valid proof object is received.
Its payload is extracted.
The payload is then treated as though it carries the same identity, custody, provenance, and integrity guarantees as the enclosing object.
It does not.
The payload is content.
The proof object is the complete authority-bearing artifact.
V108 refuses to confuse the two.
⸻
Ownership follows carried custody
This distinction becomes even more important when ownership changes.
Ownership cannot be appended to a loose payload while pretending the original custody chain remains intact.
Bearer ownership begins with the complete SDK-verified artifact.
The server derives the prior custody state from the verified carried document.
It binds the authenticated Receiz owner.
It appends the ownership event.
Then it returns a newly verified native Record → Seal artifact.
The result is not merely a database update saying that ownership changed.
The result is a new proof object carrying the continuity of that change.
That is the real difference between a platform assigning an asset to an account and an object carrying a verifiable history of custody.
The database can project the current owner.
The market can display the current owner.
A profile can show the current owner.
But the continuity is not trapped inside those projections.
It travels with the object.
⸻
Verification is not enough without continuity
This is one of the most important distinctions Receiz has made explicit.
A file can be sealed and verify offline.
That is meaningful.
It can prove integrity and origin without depending on a live database.
But not every verifiable file automatically has the complete status of a proof object with portable continuity.
A true proof object preserves more than a single verification result.
It preserves immutable object identity, payload, provenance root, prior history, custody, and the ability to append new authenticated history without destroying what came before.
Any lawful platform may verify it.
Any lawful platform may append ownership or history.
Unknown application namespaces must survive.
Prior events must remain preserved.
The object cannot become captive to the application that currently renders it.
That is what turns verification into continuity.
And that is why proof-object-first authority is larger than “putting a signature on a file.”
It defines how the artifact remains itself across applications, devices, owners, servers, and time.
⸻
Offline truth is immediate. Offline proposals are not falsely committed.
Receiz also maintains a precise distinction between what is already known and what has merely been proposed.
Known verified local truth paints first.
It does not disappear while the application waits for a server to restate it.
A settled surface does not remount just because background infrastructure is warming, reconnecting, or checking for new history.
The network may append.
It may synchronize.
It may discover a later event.
But it does not erase verified truth that is already present.
At the same time, an offline command must not be falsely presented as globally committed.
Queued is not committed.
Offline developer work remains a signed proposal with globallyCommitted: false until verified admission occurs.
When connectivity returns, the system may append the command only after the enclosing proof and causal order verify.
This preserves both sides of the law:
Local truth does not need to wait for permission to appear.
But local intent does not impersonate global settlement before admission.
That distinction is how an offline-capable system avoids becoming either server-dependent or dishonest.
⸻
History remains history
V108 also records what did not become part of the system.
Two SQL designs created during v107 were never applied.
They are not active migrations.
They are absent from supabase/migrations.
They are preserved byte-for-byte only as non-deployable .sql.txt historical evidence.
V108 does not recreate their tables, storage bucket, RPCs, or authority model.
This matters because abandoned infrastructure has a way of returning later.
Someone finds an old migration.
A table name still appears in a document.
An outdated design looks official because it exists in the repository.
A retired authority model slowly re-enters the runtime without anyone explicitly deciding to restore it.
V108 closes that door.
Historical evidence should remain available.
But history is not deployment guidance.
Future database work must establish new authority from current law.
It cannot inherit authority merely because an old design once existed.
⸻
Evidence confirms the release. Evidence does not become the authority.
The v108 release book includes desktop and mobile mutation evidence.
The desktop inline rename confirms same-account, same-UID continuity with zero developer-route requests.
The mobile full-profile save confirms the updated identity and canonical public projection with zero identity_keys rows.
The evidence digests match the v108 manifest.
But the screenshots do not become identity.
The manifest does not become proof.
The release book does not become the artifact.
Evidence has a specific role: it confirms that the implementation behaved according to the law.
And that role includes the power to block release when contradiction appears.
A contradictory screenshot, recording, DOM snapshot, UID trace, or network trace would block release even if every automated test passed.
That is an important boundary.
Automated gates are not permitted to overrule visible contradictory reality.
The test exists to measure the system.
The system does not become correct merely because the test returned green.
⸻
The law is now sealed
The final v108 constitutional registry contains 33 laws, sealed at real Kai-Klok time with a canonical whole kaiPulseEternal and a recorded SHA-256 digest.
Those laws govern the relationship between proof, identity, ownership, migration, first paint, adapters, artifacts, and release evidence.
The release also records controls against nine major threat boundaries:
proof-object downgrade, actor substitution, username takeover, developer authority inversion, embedded-payload confusion, ownership continuity break, retired SQL resurrection, settled-surface replacement, and release-evidence escalation.
The purpose is not to make software sound constitutional.
The purpose is to prevent rules from changing silently whenever a new feature, database table, SDK abstraction, or integration becomes convenient.
If a system claims that proof outranks the server, that claim must survive contact with actual implementation pressure.
It must survive profile mutations.
It must survive developer tooling.
It must survive offline operation.
It must survive ownership transfer.
It must survive release engineering.
It must survive the temptation to treat whatever layer was edited most recently as the new source of truth.
That is what v108 restores.
⸻
Exactness also means stating what has not happened
The repository qualification is recorded.
The focused v108 gates passed.
The inherited release freeze and governance verification passed.
Desktop and mobile mutation evidence is recorded.
But the release book is equally clear about the external boundary.
The local signed release attestation remains pending because the authorized signing metadata and Ed25519 key values were not present.
Production database state was not verified.
Repository qualification does not itself publish npm packages.
It does not deploy Receiz.com.
It does not mutate production data.
It does not perform production signing.
Each external action requires separate authorization and separate evidence.
That is not a weakness in the release.
That is proof discipline.
A release document should never imply that an action occurred merely because the repository is prepared for it.
The record must distinguish what passed, what remains pending, and what was never attempted. receiz-v108-proof-object-first-release-book.pdf
⸻
One truth chain
V108 continues the same chain established across the prior releases:
Living proof.
Portable continuity.
Indivisible verification.
Native Record and Seal.
Executable application law.
Browser-safe developer access.
Constitutional execution.
Developer compatibility.
And now, explicit authority restoration.
The point of the chain is not the version number.
The point is that each version remains subordinate to the same primitive:
The object carries the proof.
Not the database alone.
Not the platform alone.
Not the account page alone.
Not the SDK alone.
Not the AI agent alone.
Not the release document alone.
The proof object remains the authority, and every surrounding system is judged by whether it preserves that authority without substitution, downgrade, or interruption.
That is what “proof object first” means.
The same account remains the actor.
The complete artifact remains the artifact.
Verification precedes extraction.
Custody governs ownership.
Known local truth paints first.
Offline proposals remain proposals until admitted.
History remains preserved without pretending to be current law.
Contradictory evidence outranks a passing test.
And no weaker projection is allowed to re-decide what has already been lawfully admitted.
First admission only. Then append forever.
Proof remains authority.
Read the complete Receiz v108 Proof-Object-First Release Book