Integration

Admission flow

From intent to signature: normalize, evaluate, discharge obligations, issue a one-shot token, gate publication. Policy admission produces roots that every downstream boundary verifies.

Secret operations follow the flow below. Orchestration code drives it; the crypto core accepts secret use through a valid token produced by steps 1–5.

Sequence

  • 1. Intent. The client submits an operation intent (raw payload, claimed metadata).
  • 2. Normalization. A versioned normalizer decodes the payload, derives verified fields (asset, amount, destination, payload class), and emits a NormalizationReceipt binding its version and every derivation. Verified claims enter the context.
  • 3. Evaluation. The engine runs the active PolicyPackage over the PolicyContext and snapshot. Deny ends the flow with a trace. Allow yields obligations.
  • 4. Obligations. Approval challenges go to approver devices (see Approval devices); meters reserve; holds queue. Failure or expiry produces DENY.
  • 5. Token. A one-shot, request-bound, node- and core-scoped token is issued and recorded.
  • 6. Secret use. The crypto core verifies token signature, audience, expiry, and purpose, then creates an internal one-shot permit per protocol step.
  • 7. Publication gate. External submission requires a separate gate consuming the admission decision root before broadcast.
  • 8. Evidence. Every step appended to the hash-linked audit chain; the receipt closes the loop for replay.

Admission artifacts

The decision binds policy, trace, reservation, audit, and receipt roots. The receipt binds package, schema, trace, resolved objects, and attestations for replay.

Decision and receipt roots
json
{
  "AdmissionDecision": {
    "operation_id": "op_7f3a",
    "kind": "Approved",
    "policy_bundle_root": "cid:pkg_v43",
    "policy_epoch": 118,
    "trace_root": "cid:trace",
    "derived_level": "Quorum",
    "reservation_root": "cid:meters",
    "audit_root": "cid:audit",
    "receipt": "cid:policy_receipt"
  },
  "PolicyReceipt": {
    "package_root": "cid:pkg_v43",
    "schema_root": "cid:schema_custody_v3",
    "trace_root": "cid:trace",
    "resolved_objects_root": "cid:objects",
    "attestation_root": "cid:attestations"
  }
}

Trust boundaries in the flow

  • Orchestration sees tokens as opaque bytes in transit; minting, alteration, and reuse are engine/core responsibilities.
  • The engine handles policy state; the core handles key-share use.
  • Approvers sign over normalized data rendered by the approval device.

Publication gate

External submission consumes the admission decision root after token-backed secret use. The publication receipt records the operation id, decision root, token root, external transaction id, and audit root.