Operate / Developers

Developer launch outcome

Ship a complete Receiz integration from first proof object through verification, failures, conformance, and release.

end-to-end proof object implementationSDK, HTTP, MCP, or AI mechanics selected from exact Reference recordsComplete production checklist

Implementation rail · SDK, HTTP, MCP, or AI mechanics selected from exact Reference records

Exact execution and operator checks

  1. 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.

  2. 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.

  3. 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.

  4. 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

F1

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.
F2

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.
F3

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

  1. The verifier classifies the supplied artifact. Embedded subpayloads and remote responses remain subordinate.

    packages/receiz-sdk/src/artifactVerification.tsimplementation-verifier · SHA-256 c10cdba92568fea273e1d9e7a3321083d52945378ab0cc83aee9720d44f0bba3
  2. A passing execution confirms the checked artifact verification invariants for the exact repository state exercised.

    scripts/test_verification_conformance.tsexecutable-conformance · SHA-256 8832d6deab2b117bfaefce67285dd3da6247957d5674eff74514ed1f75cb6678
  3. A passing command verifies every bound attestation field for the supplied artifact.

    scripts/verify_release_attestation.tssigned-evidence-verifier · SHA-256 f04e07009107c30a2c41a2f237ed08a581b4773caef3771d8167b762e23d6606