Operate / Developers
Developer launch outcome
Ship a complete Receiz integration from first proof object through verification, failures, conformance, and release.
Implementation rail · SDK, HTTP, MCP, or AI mechanics selected from exact Reference records
Exact execution and operator checks
- 01
Operator check
Bind the application contract and held proof
Choose the exact SDK, HTTP, MCP, or AI rail and bind package version, source digest, identity boundary, complete held proof input, stable failures, and conformance suite.
Substantive records: /reference · /trust/hierarchy
Expected: The implementation rail is exact and subordinate to sealed proof already in custody.
- 02
Exact mechanic
Recompute the held proof locally
import { createReceizClient } from "@receiz/sdk"; // Begin with the complete proof object already held by the person or runtime. const encoded = process.env.RECEIZ_ARTIFACT_BASE64; if (!encoded) throw new Error("RECEIZ_ARTIFACT_BASE64 is required"); const artifactBytes = Uint8Array.from(Buffer.from(encoded, "base64")); // Local verification is account-free and precedes every transport projection. const receiz = createReceizClient(); const verification = await receiz.verification.verifyArtifact(artifactBytes); if (verification.status !== "verified-artifact") { throw new Error(`Artifact verification status: ${verification.status}`); } console.log(verification.status);- Mechanic
- receiz.verification.verifyArtifact
- Authentication and account boundary
- Account-free local verification precedes separate SDK, HTTP, MCP, or AI mechanics.
- Exact source
node_modules/@receiz/sdk/dist/index.d.ts· SHA-256 3278d551808697d9936ffdf75931358c903bb0cc5a211191b611d4474895f6be
Expected: The application receives verified-artifact for the exact held bytes before any optional transport or authenticated issuance mechanic.
- 03
Exact mechanic
Run test:verification-conformance
pnpm test:verification-conformance- Mechanic
- pnpm test:verification-conformance
- Authentication and account boundary
- Authorized local repository checkout; the command proves only the checked repository boundary.
- Exact source
package.json· SHA-256 132f99232dfaf26f7186b73752938d1377042808f42d60d374fe7b2e57c7646b
Expected: Canonical verification statuses and byte-domain contracts pass.
- 04
Operator check
Ship the exact mechanic and failure contract
Test credential denial where a chosen mechanic requires credentials, input mutation, idempotency conflict, verifier rejection, network loss, stable errors, and rollback from the last held proof.
Substantive records: /reference/stable-errors · /reference/releases
Expected: The application ships proof, mechanics, failures, recovery, and conformance as one contract.
Complete operating anatomy
Every boundary required to ship.
- Solved outcome
- The application records moments as sealed PNG proof objects, seals existing files, verifies exact artifacts, preserves receipts, handles every declared failure, and passes release gates.
- Prerequisites
- Hold the exact v124 rail, package or OpenAPI source digest, proof input, account boundary, operation identity, artifact custody, status branches, stable failures, conformance command, deployment target, and rollback plan.
- Exact primitive
- end-to-end proof object implementation
- Governing law
- Developer launch outcome is governed by canonical-artifact-verifier: The verifier classifies the supplied artifact. Embedded subpayloads and remote responses remain subordinate. verification-conformance: A passing execution confirms the checked artifact verification invariants for the exact repository state exercised. release-attestation-verify: A passing command verifies every bound attestation field for the supplied artifact.
- Source-of-truth order
- Receiz law → sealed artifact truth → deterministic proof object state → verified durable local or register truth → authenticated snapshot → server distribution, synchronization, indexing, and publication → database, session, observability, and interface projections.
- Expected artifact, receipt, or state
- A verified proof object plus typed operation receipt, failure evidence, conformance output, and bounded release evidence.
- Inspection
- Inspect the artifact bytes, SDK or API receipt, stable failures, source digests, and conformance output. Inspection exposes structure and receipt fields; inspection never establishes verification.
- Independent verification
- Independent verification for developer-outcome: pnpm test:verification-conformance. This establishes only the end-to-end proof object implementation boundary named by the bound sources; The implementation rail remains beneath proof authority: SDK, HTTP, MCP, or AI mechanics selected from exact Reference records.
- Offline behavior
- Implement local inspection and verification first; network mechanics distribute existing proof or coordinate separately verified mutations without becoming their authority.
- Identity and account boundary
- Public Record Moment, Seal File, Verify, Export, and public proof reading are account-free. Identity is optional and adds continuity, custody, recovery, and governed private controls after proof admission.
- Security boundary
- Keep credentials server-side or in authorized callbacks, enforce idempotency, and never expose private material in client output.
- Conformance command
pnpm test:verification-conformance- Deployment checks
- Pin exact mechanics, typecheck, execute Record Moment, Seal File, or authenticated SDK proof-object issuance according to the selected rail, retain sealed bytes, verify locally, map stable failures, test idempotency and network loss, run conformance, deploy the same build, and smoke exact routes.
- Production checklist
- Bind source; typecheck; execute the selected proof operation; hold bytes; verify; inspect receipt; test denial, mutation, replay, conflict, timeout, offline use, recovery, conformance, deployment, smoke, and rollback.
- Rollback and containment
- Containment for developer-outcome: The integration is invented and cannot ship. Use an exact installed SDK, CLI, HTTP, MCP, AI, or repository record. Verification rejects the changed boundary and preserves the previously held bytes. Restore the held bytes or record the changed moment as a new operation, then seal and verify it. Production qualification does not apply. Deploy the exact qualified artifact and rerun dated smoke. Preserve every stronger held artifact and admitted state while the named boundary is corrected.
Fail closed
Mutation and failure matrix
Implementation token or path is absent from the bound source bytes.
- Effect
- The integration is invented and cannot ship.
- Retry
- Do not approximate the mechanic.
- Recovery
- Use an exact installed SDK, CLI, HTTP, MCP, AI, or repository record.
Exact artifact bytes or declared digest change after custody.
- Effect
- Verification rejects the changed boundary and preserves the previously held bytes.
- Retry
- Never retry changed bytes under the same operation identity.
- Recovery
- Restore the held bytes or record the changed moment as a new operation, then seal and verify it.
Deployment or smoke uses bytes different from the qualified build.
- Effect
- Production qualification does not apply.
- Retry
- Do not claim launch completion.
- Recovery
- Deploy the exact qualified artifact and rerun dated smoke.
Exact authority
Claim-to-source bindings
The verifier classifies the supplied artifact. Embedded subpayloads and remote responses remain subordinate.
packages/receiz-sdk/src/artifactVerification.tsimplementation-verifier · SHA-256 c10cdba92568fea273e1d9e7a3321083d52945378ab0cc83aee9720d44f0bba3A passing execution confirms the checked artifact verification invariants for the exact repository state exercised.
scripts/test_verification_conformance.tsexecutable-conformance · SHA-256 8832d6deab2b117bfaefce67285dd3da6247957d5674eff74514ed1f75cb6678A passing command verifies every bound attestation field for the supplied artifact.
scripts/verify_release_attestation.tssigned-evidence-verifier · SHA-256 f04e07009107c30a2c41a2f237ed08a581b4773caef3771d8167b762e23d6606
One complete system