Proof Verifies Where It Is Held
Proof Verifies Where It Is Held
Receiz v109 makes complete proof-object verification locally computable: no server permission, no database lookup, no active session, and zero network calls.
I am publishing the full release book for Receiz v109.0.0: Local-Offline Verification.
V108 restored the correct direction of authority:
The proof object comes first.
V109 answers the next unavoidable question:
Can the object actually prove itself where it is held, or does it still need to ask the platform what to believe?
That distinction separates portable proof from remotely authorized data.
A file can look self-contained while its verification button secretly calls an API.
An SDK can expose a method named verify() while merely requesting a verdict from a server.
An application can advertise offline access while requiring a cached session, registry lookup, database row, or previously downloaded response to decide whether an artifact is valid.
In each case, the object may travel—but its authority remains captive.
Receiz v109 closes that gap.
A complete sealed Receiz proof object carries the material required to recompute its truth locally.
The verification code travels.
The Signature V4 roots travel.
The Groth16 verification key travels.
The verifier runtime travels.
The artifact schemas travel.
The complete decision substrate is installed with the public SDK.
The result is exact:
Complete artifact. Local recomputation. Zero network calls.
The object does not ask Receiz.com whether it is valid.
It does not ask a database whether it exists.
It does not ask a registry whether it should be trusted.
It does not require an access token, cookie, session, or running platform process.
The proof verifies where it is held. receiz-v109-local-offline-verification-release-book.pdf
⸻
Verification is computation, not permission
This release establishes a boundary that is easy to blur:
Issuance and verification are different operations.
Issuing a new proof object remains an authenticated mutation.
Receiz performs the native Record → Seal process.
The actor must be authenticated.
The new record must be lawfully admitted.
Ownership, claims, paths, and state transitions must be bound correctly.
That operation may involve Receiz.com because something new is being created or appended to the shared history.
Verification is different.
Once the complete proof object has been sealed and delivered, determining whether those bytes satisfy the proof should not require asking the issuer again.
The evidence is already present.
Verification is therefore not a request for permission.
It is local recomputation over the carried artifact.
Receiz v109 changes verification and opening.
It does not weaken issuance authority.
It does not grant offline mutation permission.
It does not pretend an unadmitted local command has become globally committed.
It simply ensures that a proof object already in someone’s custody can be evaluated without dependence on the infrastructure that issued it.
That is what makes proof portable rather than merely downloadable.
⸻
The complete object enters the verifier
The public SDK now exposes complete-artifact verification directly:
receiz.verification.verifyArtifact(file)
But the method name is not the accomplishment.
Anyone can name a function verifyArtifact().
The question is where its verdict comes from.
In v109, the function accepts the complete .receizbundle carrier and recomputes the carried proof locally.
The returned verdict does not originate from an API response.
It does not originate from a database query.
It does not originate from a registry service.
It is derived from the artifact’s bytes and the verification material packaged with the SDK.
That boundary matters because the complete carrier binds several domains together:
identity,
integrity,
provenance,
canonical path,
payload,
signature,
seal,
custody,
and continuity.
A payload extracted from the carrier is not equivalent to that carrier.
A database record describing the artifact is not equivalent to that carrier.
A manifest, metadata object, SDK handle, filename, or API response is not equivalent to that carrier.
Those things may describe, transport, index, or project the proof object.
They cannot substitute for it.
The complete native carrier enters the verifier because the complete native carrier is the authority-bearing object.
⸻
Opening never outruns verification
V109 also introduces the public artifact-opening path:
receiz.artifacts.verifyAndOpen(file)
The order is deliberate.
First, verify the enclosing object.
Then—and only then—extract the verified payload.
The method returns the complete sealed artifact separately from the verified payload so the two custody domains remain explicit.
That distinction prevents one of the most common proof downgrades.
A system receives a signed artifact.
It extracts the useful content.
It throws away the enclosure.
Then it begins treating the content as though it still carries every guarantee previously supplied by the complete object.
It does not.
The payload may be the photograph, record, media file, card data, receipt, identity document, or application-specific content a developer wants to use.
But its authority comes from its binding to the enclosing proof.
Extraction does not transform the subpayload into a standalone proof object.
In v109, the payload digest must agree with the enclosing artifact.
Verified payload bytes become available only after the carrier structure, artifact basis, and proof binding pass.
Domain parsers therefore receive content that has already passed complete-artifact verification.
They never receive arbitrary carrier input and retroactively declare it trusted.
Verify the enclosure. Then project the payload. Never reverse the order.
⸻
Malformed proof does not partially succeed
Local verification must be stricter, not weaker.
When no server exists to “help” interpret an artifact, the verifier cannot improvise.
Carrier framing must be valid.
Canonical bytes must agree.
The artifact basis must match.
Document structure must be coherent.
Identity and canonical path must bind to the sealed carrier.
The payload digest must agree with the enclosure.
Signature V4 must verify.
The Groth16 seal must verify.
Where portable ownership continuity applies, that history must verify too.
Any broken boundary rejects the artifact.
There is no partial success in which the payload appears valid even though the carrier is malformed.
There is no compatibility mode that silently ignores a binding mismatch.
There is no server fallback that converts a local rejection into remote approval.
There is no “verified enough” state.
V109 freezes a fail-closed matrix covering:
one-byte mutation,
malformed carrier structure,
artifact-binding mismatch,
Signature V4 failure,
Groth16 failure,
and invalid portable continuity.
Each produces rejection.
None becomes a partially verified object.
That is necessary because proof is not the accumulation of several independent green checkmarks.
The proof object is one bound statement.
If a required boundary fails, the statement does not survive intact.
⸻
One changed byte changes the verdict
The clearest demonstration of local authority is mutation.
The release evidence begins with a production-signed complete artifact.
That artifact verifies locally.
Then one byte is changed.
The modified artifact fails locally.
Both outcomes occur with zero fetch calls.
The verifier does not see the mutation and ask the server whether the artifact was once valid.
It does not retrieve a clean copy.
It does not match the object against a database row and approve it because the ID looks familiar.
It does not fall back to checking only the extracted payload.
The changed bytes produce a changed verdict.
Immediately.
Locally.
Without permission.
That is what integrity means when the object itself carries the evidence required to evaluate it.
A remote verification service can tell you what its database currently believes about an identifier.
A local verifier tells you whether the exact bytes currently in your possession satisfy the proof they claim to carry.
Those are not the same capability.
V109 makes the second capability public and package-complete.
⸻
Signature V4 verifies locally
The Signature V4 certificate root no longer depends on decision-time server confirmation.
Pinned Signature V4 roots ship with the SDK.
Certificate agreement is recomputed locally.
Owner and claim bindings are recomputed locally.
Canonical path agreement is recomputed locally.
Root agreement is recomputed locally.
A caller cannot relabel an object by passing a different filename, transport path, API route, or identity hint.
Successful verification requires the object’s canonical identity and path fields to agree with the sealed carrier itself.
The artifact says what it is.
Transport cannot rename it into another proof identity.
A platform may display the object under a convenient label, but that label does not rewrite the sealed identity.
This is the same authority direction established in v108, now enforced inside the public offline verifier.
The SDK reports the truth carried by the artifact.
It does not select a new truth for it.
⸻
Groth16 verification travels with the SDK
Receiz proof objects also carry a document-seal Groth16 proof.
For that seal to be genuinely offline-verifiable, the developer cannot be required to download the verification key at the moment a decision is needed.
That would turn “offline proof” into an online dependency with a temporary cache.
V109 ships the document-seal Groth16 verification key and the snarkjs runtime with the SDK.
The installed package therefore contains the material required to recompute the zero-knowledge seal locally.
No verifier-state download is required at decision time.
No live registry must answer.
No Receiz.com process must be running.
The proof object and installed verifier substrate are sufficient.
This is an important difference between using zero-knowledge proof technology and delivering zero-knowledge verification as a real product capability.
A Groth16 proof inside an artifact is not practically portable when the verifier still depends on private infrastructure to interpret it.
The proof becomes operationally portable only when the complete verification path travels too.
V109 packages that path.
⸻
Portable continuity is part of the object
Verification does not stop at the artifact’s original moment of issuance.
Where a proof object carries portable ownership history, that continuity is evaluated as part of the complete object.
Prior custody matters.
Ownership appends matter.
Portable history matters.
The relationship between the original object and later verified states matters.
Invalid continuity is not softened into “missing enrichment.”
That phrase matters because optional platform data and broken proof history are not the same thing.
A marketplace description may be missing.
A profile image may not be cached.
A public index may be unavailable.
Those may be enrichment failures.
But when the artifact claims a custody chain, and that custody chain does not verify, the verifier cannot simply omit it and approve the remaining object.
The history is part of the statement being made.
Where continuity applies, continuity must pass.
This is how the object remains itself while changing owners, applications, and environments.
Its history is not merely looked up from wherever it currently appears.
It is carried and verified.
⸻
Zero network is normal operation
Offline verification is often described as a fallback.
The main application verifies online.
Then, when the connection fails, a reduced local path attempts to provide some partial functionality.
V109 rejects that framing.
For public artifact verification and opening, network absence is normal operation.
The verifier contains no fetch path.
It requires:
no access token,
no cookie,
no database connection,
no registry lookup,
and no running Receiz.com process.
The network-call count during verification is not “low.”
It is zero.
This is now constitutional release law under ARTIFACT-011:
Complete SDK artifact verification and extraction must remain available without network, session, database, or server state.
The denial code is explicit:
LOCAL_ARTIFACT_VERIFICATION_MUST_NOT_REQUIRE_WEAKER_STATE
That wording captures the deeper principle.
A server response is weaker state than the complete proof object when the question is whether that object’s carried proof verifies.
A session is weaker state.
A database projection is weaker state.
A registry lookup is weaker state.
Those systems may transport, index, synchronize, or explain the proof.
They may not become prerequisites for its local verdict.
If a future implementation introduces that dependency, the release must fail.
⸻
Every verification dependency must travel
Offline claims are easy to make when the test environment still has hidden access to build artifacts, development files, or previously installed dependencies.
V109 therefore treats packaging as part of proof correctness.
The public SDK package must actually include the full decision substrate:
Signature V4 roots,
Groth16 verification material,
local verifier code,
snarkjs runtime,
and artifact schemas.
The package is built, packed, installed externally, and tested from the resulting tarball.
That external installation boundary matters.
It verifies that consumers receive the capability—not merely that it exists somewhere inside the Receiz monorepo.
A repository can pass internal tests while publishing an incomplete package.
A developer can import files that never make it into the distributed tarball.
A test runner can resolve workspace dependencies unavailable to real users.
V109 qualifies the package after packing and external installation because offline verification only exists publicly when another developer can install the SDK and reproduce the local verdict from the shipped artifact.
⸻
Clean-before-build is part of correctness
There is another packaging risk that appears mundane but can silently preserve obsolete authority.
Compiled output can outlive its source.
A version-specific SDK entry point may be deleted from the source tree while remaining inside a stale dist directory.
The next package build may then include code that no longer exists in the maintained implementation.
The repository appears corrected.
The published package quietly retains the old behavior.
V109 makes clean-before-build part of package correctness.
Stale output is removed.
Current source is compiled.
The resulting tarball is inspected.
Obsolete implementations are rejected.
This is not cosmetic build hygiene.
When developer APIs express authority boundaries, stale compiled code can resurrect a retired authority model.
Deleting the source is not enough.
The packable output must prove that it is gone.
⸻
Historical proof survives without historical SDK authority
Receiz preserves historical truth.
Previously sealed artifacts remain valid historical artifacts.
Receipts remain.
Registry records remain.
Release evidence remains.
But preserving historical proof does not require permanently shipping every historical SDK implementation.
V109 removes obsolete v107 SDK and MCP implementations, exports, generators, and migration commands from the installable surface.
The maintained public imports remain unversioned:
@receiz/sdk
@receiz/sdk/react
@receiz/sdk/compiler
@receiz/sdk/testing
@receiz/mcp-server
Existing v108 method names and the separation between complete artifact and verified payload remain source-compatible.
This establishes another critical distinction:
Historical truth must remain readable without allowing historical developer code to remain current authority.
A sealed proof should not become unverifiable because an old SDK entry point is removed.
And an obsolete SDK should not remain installable merely because old proof exists.
The current verifier reads the historical artifact.
The historical artifact does not require resurrection of the old developer authority model.
⸻
MCP orchestrates. It does not verify differently.
MCP artifact operations reuse the same public SDK verifier.
There is not one proof standard for direct SDK users and another for agents.
MCP may help plan an operation.
It may invoke the verifier.
It may structure the returned result.
It may explain why an artifact passed or failed.
But it cannot mint a stronger verdict than the SDK produced.
It cannot extract the payload before the enclosure verifies.
It cannot convert orchestration into authority.
It cannot make a network-dependent statement and call it local proof.
The artifact remains the authority.
The SDK recomputes the verdict.
MCP orchestrates that computation.
The layers remain exact.
⸻
AI explanation remains beneath evidence
V109 validates 31 AI skills against the same boundary.
For an artifact-related skill to make a production-ready claim, it must include the exact statement:
Network calls during verification: 0
It must also include a recorded local verifier result.
That requirement prevents AI-generated confidence from being mistaken for verification evidence.
An AI system can explain what the verifier checked.
It can translate a structured verdict into human language.
It can guide a developer through a failure.
It can distinguish a malformed carrier from a Signature V4 or Groth16 rejection.
But it cannot reason an invalid artifact into validity.
It cannot summarize a server response and call it offline verification.
It cannot replace missing executable evidence with persuasive prose.
Generated explanation remains evidence beneath the verified object.
The object carries the verdict.
The AI describes it.
That direction cannot reverse.
⸻
Product behavior remains exact
V109 is a coordinated developer verification release.
Receiz.com product behavior remains v108 exact.
The database paths remain unchanged.
No database schema was added.
No migration was introduced.
No production query path changed.
No production row was mutated.
No application mutation behavior was added.
Visible release labels, the service worker version, runtime-coherence identification, and offline-verifier identification move to v109.
But the product is not being altered merely to create the appearance of a larger version change.
That is intentional.
Versions should name real boundaries.
They should not force payload schema renames, behavior changes, or database migrations where none are required.
V109 strengthens the public verification capability without pretending that unrelated application data became a new format overnight.
⸻
The constitutional register now contains 34 laws
V109 adds ARTIFACT-011 to the constitutional registry.
The registry now contains 34 laws and preserves the v108 digest as its previous witnessed root.
The new law seals zero-network artifact verification as part of the continuing Receiz truth chain.
This is larger than documenting a current SDK feature.
Features can quietly regress.
A helper function can be rewritten.
A remote lookup can be added for convenience.
A verifier can begin consulting a registry “just to be safe.”
A package can stop shipping a large verification dependency to reduce size.
Each change may look reasonable in isolation.
Together, they would restore server permission beneath the language of offline proof.
By placing the boundary in constitutional release law, v109 makes those regressions explicit release failures.
The implementation is not merely expected to remain offline.
It is forbidden from requiring weaker state.
⸻
The release evidence is executable
The v109 release record qualifies the developer boundary through executable evidence:
120 SDK tests
32 MCP tests
31 validated AI skills
a production-signed local verification result,
a one-byte mutation rejection,
zero fetch calls for both,
type checking,
tarball inspection,
external installation,
release-freeze gates,
registry verification,
and governance controls.
The release book also states exactly what evidence is not present.
There is no dedicated v109 product-surface screenshot manifest.
No product mutation is claimed.
The rendered pages verify the release document’s layout, not Receiz.com application behavior.
That honesty matters.
Evidence should prove only what it actually observed.
A release should not invent screenshots to make a developer capability look visual.
It should not turn a PDF rendering check into evidence of application behavior.
V109 records the executable boundary it changed and leaves unrelated claims outside the release.
⸻
Repository qualification is not publication
The repository and packages are qualified for the recorded boundary.
That does not mean every external action has occurred.
The release book does not claim that npm packages were published.
It does not claim that Receiz.com was deployed.
It does not claim that a production database changed.
It does not claim that the final release attestation was signed.
npm publication and release signing remain separate actions requiring separate authorization and their own evidence.
This is the same discipline applied to the proof object itself:
Do not allow a label to outrun the underlying evidence.
“Release-ready” is not the same statement as “published.”
“Qualified” is not the same statement as “deployed.”
“Signing pending” is not “signed.”
The record remains exact because exactness is part of authority.
⸻
The object carries the verdict
V109 refuses to forget five boundaries:
No public verifier may depend on an API response.
No stale compiled output may preserve deleted developer code.
No extraction may precede enclosure verification.
No historical SDK is required to read historical proof.
No version bump may rename unchanged product payload schemas merely to perform version theater.
Together, these rules establish what offline proof actually requires.
It is not enough that the user can download a file.
It is not enough that a browser once cached a response.
It is not enough that an SDK exposes a function called verify.
It is not enough that a server can confirm the object when contacted.
The complete artifact must be present.
The verification material must be present.
The computation must occur locally.
A mutation must change the verdict.
A broken boundary must fail closed.
The network-call count must be zero.
And every surrounding tool must remain beneath the artifact it is evaluating.
That is the release.
The object carries the verdict.
Verification recomputes locally.
Weaker systems may transport, never authorize.
Read the complete Receiz v109 Local-Offline Verification Release Book