Operate / Businesses
Business launch outcome
Convert transactions, documents, inventory, and Settlement events into independently verifiable operational evidence.
Implementation rail · local sealing and verification plus optional HTTP/OpenAPI coordination
Exact execution and operator checks
- 01
Operator check
Seal and bind the business event
Hold the complete sealed event artifact and bind its exact identity, source document or transaction bytes, owner or custodian, amount precision, value source, Settlement terminal states, and accountable operator.
Substantive records: /learn/primitive-atlas · /reference/http-openapi
Expected: The business event has a held proof object and distinct custody and Settlement boundaries before checkout.
- 02
Exact mechanic
Verify the event artifact
import { createReceizClient } from "@receiz/sdk"; 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")); const receiz = createReceizClient(); const verification = await receiz.verification.verifyArtifact(artifactBytes); if (verification.status !== "verified-artifact") throw new Error(verification.status); console.log(verification.status);- Mechanic
- receiz.verification.verifyArtifact
- Authentication and account boundary
- Account-free local verification of the value-source event.
- Exact source
node_modules/@receiz/sdk/dist/index.d.ts· SHA-256 3278d551808697d9936ffdf75931358c903bb0cc5a211191b611d4474895f6be
Expected: The held business-event artifact returns verified-artifact before any checkout mechanic is allowed to represent it.
- 03
Exact mechanic
Create a hosted Settlement checkout bound to the verified event
curl --fail-with-body --request POST "https://receiz.com/api/payments/embed/checkout" --header "content-type: application/json" --data "${RECEIZ_CHECKOUT_JSON:?RECEIZ_CHECKOUT_JSON is required}"- Mechanic
- POST /api/payments/embed/checkout
- Authentication and account boundary
- No Auth
- Exact source
receiz-docs/generated/openapi-reference.json· SHA-256 2278eb9ab1dfcc90d61d4a6f9daac1bc55e17aeeab0d2d5d39228f88654bc20a
Expected: The no-auth embed route returns a checkout session or stable rejection for the request bound to the verified event identity.
- 04
Exact mechanic
Run test:settlement-conformance
pnpm test:settlement-conformance- Mechanic
- pnpm test:settlement-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: Value source, precision, ledger, idempotency, and terminal-state contracts pass.
- 05
Operator check
Reconcile proof, custody, and Settlement
Keep the verified event verdict primary, inspect ownership or custody separately, and reconcile checkout, ledger, and Settlement receipts without collapsing their statuses.
Substantive records: /reference/operations-receipts · /trust/conformance
Expected: Every business claim maps to its own exact evidence.
Complete operating anatomy
Every boundary required to ship.
- Solved outcome
- Each governed business event has a sealed proof object, custody and Settlement boundaries, exact receipt, verification path, and release assurance record.
- Prerequisites
- Hold business event identity, exact source record, artifact custody, owner or custodian, amount precision, value source, Settlement and ownership boundaries, operator roles, credential scopes, evidence retention, and rollback authority.
- Exact primitive
- business event proof, ownership, and settlement
- Governing law
- Business launch outcome is governed by settlement-conformance: A passing execution confirms the checked settlement invariants for the exact repository state exercised. market-conformance: A passing execution confirms the checked market ownership invariants for the exact repository state exercised. governance-controls: Required control records exist and satisfy the script's exact structural checks.
- 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 sealed business-event artifact and distinct Ownership or Settlement proof bound to exact operation identity.
- Inspection
- Inspect the business artifact, provenance, custody, value source, Settlement state, and independent status dimensions. Inspection exposes structure and receipt fields; inspection never establishes verification.
- Independent verification
- Independent verification for business-outcome: pnpm test:settlement-conformance && pnpm test:verification-conformance. This establishes only the business event proof, ownership, and settlement boundary named by the bound sources; The implementation rail remains beneath proof authority: local sealing and verification plus optional HTTP/OpenAPI coordination.
- Offline behavior
- Documents, inventory objects, admitted operational events, and supported Note Settlement remain executable and verifiable offline. External-provider mutation or optional global publication stays a separate coordination boundary.
- 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
- Separate operational roles, protect transition authority, preserve immutable evidence, and disclose external provider dependencies.
- Conformance command
pnpm test:settlement-conformance- Deployment checks
- Qualify event sealing, independent verification, ownership disclosure, Settlement precision and terminal state, ledger reconciliation, role separation, idempotency, provider failure, evidence retention, incident response, and dated business smoke.
- Production checklist
- Seal one event; verify; execute checkout or Settlement; inspect custody separately; reconcile receipt and ledger; test duplicate, stale head, provider failure, wrong role, offline document verification, incident containment, and rollback.
- Rollback and containment
- Containment for business-outcome: The business claim is rejected. Record and seal the exact event bytes anew. The operation remains incomplete and separately inspectable. Reconcile each governed receipt by operation identity. Coordinated mutation stops; held proof remains valid. Restore scoped access or provider availability and reconcile before retry. Preserve every stronger held artifact and admitted state while the named boundary is corrected.
Fail closed
Mutation and failure matrix
Business source record and sealed artifact do not bind to the same event.
- Effect
- The business claim is rejected.
- Retry
- Do not substitute database state.
- Recovery
- Record and seal the exact event bytes anew.
Ownership and Settlement statuses are collapsed or disagree.
- Effect
- The operation remains incomplete and separately inspectable.
- Retry
- Do not infer one state from the other.
- Recovery
- Reconcile each governed receipt by operation identity.
Provider or credential failure occurs after local proof custody.
- Effect
- Coordinated mutation stops; held proof remains valid.
- Retry
- Retry only the uncommitted idempotent operation.
- Recovery
- Restore scoped access or provider availability and reconcile before retry.
Exact authority
Claim-to-source bindings
A passing execution confirms the checked settlement invariants for the exact repository state exercised.
scripts/test_settlement_conformance.tsexecutable-conformance · SHA-256 021f52595eaaa948337dbe5e01fd4d053a1bab161aea1cad7d053ee1886836baA passing execution confirms the checked market ownership invariants for the exact repository state exercised.
scripts/test_market_conformance.tsexecutable-conformance · SHA-256 47c7ebb7eb9f3854f31dbc7266909f9e4c9726908930d236f3a76eaacae54eb7Required control records exist and satisfy the script's exact structural checks.
scripts/check_governance_controls.tsgovernance-control · SHA-256 8fa9d6429e8775c2fbea9b731078aab4a7d978f649bd6323d01b1199e8c7c4a8
One complete system