Operate / Application developers
Operate with the SDK
Use the installed v124 SDK to issue through the authenticated HTTP rail, then inspect, verify, admit, recover, and export the sealed proof object. Use Workbench for account-free local Record Moment and Seal File.
Implementation rail · @receiz/sdk 124.0.2
Exact execution and operator checks
- 01
Operator check
Hold a complete proof object and choose the exact SDK rail
Begin with a Workbench, Offline Studio, imported, or separately issued proof object in custody. Use RECEIZ_ACCESS_TOKEN only when choosing the distinct authenticated HTTP issuance operation exposed by receiz.assets.createProofObject.
Substantive records: /reference/sdk · /learn/primitive-atlas
Expected: Held proof, local verification, and authenticated HTTP issuance remain distinct mechanics beneath the same proof-object law.
- 02
Exact mechanic
Verify the held object with the installed SDK
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 optional authenticated issuance, transport, or download receipts.
- Exact source
node_modules/@receiz/sdk/dist/index.d.ts· SHA-256 3278d551808697d9936ffdf75931358c903bb0cc5a211191b611d4474895f6be
Expected: The installed SDK returns verified-artifact for the complete held bytes without an account or network dependency.
- 03
Exact mechanic
Run sdk:test
pnpm sdk:test- Mechanic
- pnpm sdk:test
- Authentication and account boundary
- Authorized local repository checkout; the command proves only the checked repository boundary.
- Exact source
package.json· SHA-256 132f99232dfaf26f7186b73752938d1377042808f42d60d374fe7b2e57c7646b
Expected: Installed SDK runtime, declarations, failures, and package contracts pass.
- 04
Operator check
Qualify every selected mechanic
Exercise invalid bytes, optional issuance credential denial, idempotency replay, network loss after local custody, and digest mismatch; branch only on declared SDK result statuses.
Substantive records: /reference/stable-errors · /reference/schemas-test-vectors
Expected: The application preserves held proof and exact stable failures across every tested boundary.
Complete operating anatomy
Every boundary required to ship.
- Solved outcome
- SDK calls return exact typed artifacts and receipts while application code preserves sealed artifact authority.
- Prerequisites
- Install @receiz/sdk@124.0.2; hold exact source bytes; provide account access only for the authenticated HTTP issuance operation; preserve the returned sealed artifact; and keep local verification account-free.
- Exact primitive
- proof object mechanics
- Governing law
- Operate with the SDK is governed by canonical-artifact-verifier: The verifier classifies the supplied artifact. Embedded subpayloads and remote responses remain subordinate. artifact-conformance: A passing execution confirms the checked sealed artifact invariants for the exact repository state exercised. literal-product-law: Implemented primitives are named directly, stronger truth remains above weaker projections, and a contradiction is release-blocking.
- 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 typed sealed artifact, artifact SHA-256, verification result, and operation receipt defined by the installed SDK.
- Inspection
- Inspect the returned artifact bytes, artifactSha256, verification status, and receipt fields. Inspection exposes structure and receipt fields; inspection never establishes verification.
- Independent verification
- Independent verification for sdk: pnpm --filter @receiz/sdk test. This establishes only the proof object mechanics boundary named by the bound sources; The implementation rail remains beneath proof authority: @receiz/sdk 124.0.2.
- Offline behavior
- Artifact inspection and canonical verification execute locally; authenticated HTTP issuance remains an explicit network operation. Workbench Record Moment and Seal File execute offline after one-time anonymous enrollment and asset warming.
- 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
- Access tokens stay in environment or callback custody and never enter artifacts, logs, rendered documentation, or client bundles.
- Conformance command
pnpm --filter @receiz/sdk test- Deployment checks
- Pin the coordinated SDK, typecheck the integration, qualify authenticated issuance credentials, exact artifact custody, declared status branches, idempotency, stable failures, offline verification, network interruption, and package conformance.
- Production checklist
- Typecheck; execute authenticated issuance or use Workbench Record Moment or Seal File; retain artifact bytes; verify; inspect receipt digest; test invalid and denied status, idempotency replay and conflict, token absence, network loss, offline verification, and SDK conformance.
- Rollback and containment
- Containment for sdk: No proof object is claimed. Obtain authorized access or use Workbench Record Moment or Seal File after anonymous device enrollment. The artifact is not admitted as verified. Resolve the named input or support boundary and verify again. Receipt inspection fails closed. Preserve both values, contain the integration, and recover the original sealed artifact. Preserve every stronger held artifact and admitted state while the named boundary is corrected.
Fail closed
Mutation and failure matrix
Authenticated SDK issuance lacks valid account access or is denied.
- Effect
- No proof object is claimed.
- Retry
- Do not relabel HTTP issuance as account-free local Seal File.
- Recovery
- Obtain authorized access or use Workbench Record Moment or Seal File after anonymous device enrollment.
SDK returns invalid, unsupported, or denied verification status.
- Effect
- The artifact is not admitted as verified.
- Retry
- Branch on the exact status; never coerce it.
- Recovery
- Resolve the named input or support boundary and verify again.
Download receipt digest differs from the sealed artifact digest.
- Effect
- Receipt inspection fails closed.
- Retry
- Do not publish or replace bytes.
- Recovery
- Preserve both values, contain the integration, and recover the original sealed artifact.
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 sealed artifact invariants for the exact repository state exercised.
scripts/test_v108_artifact_conformance.tsexecutable-conformance · SHA-256 51bf8686e40fbb0031f6245cff975ca6dcb13614fce2471793a2c723bac7bf65Implemented primitives are named directly, stronger truth remains above weaker projections, and a contradiction is release-blocking.
docs/literal-product-law.mdnormative-doctrine · SHA-256 5548a8f32bbdf35f2ba5e4545cd31ef6e2842d2c3127a3e39e10e6eb6bc5efa1
One complete system