High-Risk Workflow

This deployment profile shows a difficult combination: a material external effect that is compensatable but not safely repeatable, multiple policy-required approvers, and cross-tenant scope. The custom gate/audit envelopes below are illustrative profile contracts; the canonical base schemas remain those in API Contracts.

Admit exact contextos.enterprise@1 and contextos.durable-delegated@1 requirements for this long-running workflow, plus controls activated by its actual network, sensitive-data and external-effect features. If the deployment requires contextos.high-assurance@1, independent current fault/recovery evidence is also mandatory. A high-risk label, a WebAuthn example or passing reference checks does not establish that evidence or domain compliance. Execution Contract supplies the compatible action/approval, boundary, operation, checkpoint and budget attachments; production services supply actual enforcement and atomic stores.

Scenario: invoice credit adjustment

A finance operator requests a credit adjustment on an invoice issued to a counterparty tenant. Native risk is an external-state, user-delegated, compensatable API effect over restricted data. The v1 compatibility projection is destructive; separate policy requires recipient consent and finance-lead approval.

End-to-end workflow

1. Receive the request

{
  "request_id": "req_inv_22",
  "session_id": "sess_inv_22",
  "tenant_id": "tenant_acme_prod",
  "user": { "user_id": "usr_finops_11", "delegation": { "auth_type": "oauth2", "scopes": ["finance.invoice.write"], "subject": "u:user:finops-11" } },
  "agent": { "agent_id": "agt_finops", "workload_identity": "spiffe://contextos/agents/finops", "role": "finance_ops" },
  "context_pack_refs": ["ctxpack.finops@3.1.0"],
  "input": { "intent": "finance.invoice.credit_adjust", "message": "Issue credit memo on inv_8810 for INR 12000" },
  "mode": "long_running",
  "runtime": { "max_session_duration_ms": 14400000, "max_tool_calls": 12 },
  "trace": { "trace_id": "9d290000000000000000000000000001", "span_id": "7c41000000000001" }
}

2. Compile

The Compiler emits a CompiledContext with:

• runtime_controls.approval_gates_active = ["GATE_FINANCE_LEAD", "GATE_RECIPIENT_TENANT"]
• runtime_controls.must_escalate = [] on the successful path; an active tax-compliance escalation blocks continuation to the GL effect until handled under explicit policy.
• The decision’s evidence_gates list all four requirements. evidence_manifest contains only the admitted current verified artifacts; unresolved recipient consent cannot already be marked satisfied.

Applicable policy-expression errors stop compilation with a structured ContextCompileError. The runtime safely reports the error and does not proceed with a partial compiled context.

3. Plan

{
  "plan_id": "plan_inv_22",
  "steps": [
    { "id": "s1", "tool": "adp_invoices.lookup", "params": { "invoice_id": "inv_8810" } },
    { "id": "s2", "tool": "adp_policy.eval", "depends_on": ["s1"] },
    { "id": "s3", "tool": "adp_recipient.notify", "depends_on": ["s2"], "approval_mode": "delegated", "requires": ["GATE_RECIPIENT_TENANT"] },
    { "id": "s4", "tool": "adp_gl.post_credit_entry", "depends_on": ["s3"], "approval_mode": "destructive", "requires": ["GATE_FINANCE_LEAD"] }
  ],
  "decision_checkpoints": [
    { "decision_id": "finance.invoice.credit_adjust.eligibility", "after_step": "s2" },
    { "decision_id": "finance.invoice.credit_adjust.execute",     "after_step": "s3" }
  ]
}

4. Execute through the gates

s1 (read_only)               → tc_901 → ok
s2 (read_only)               → tc_902 → ok
[checkpoint] eligibility     → DECIDED:eligible
 
s3 (delegated)
  → propose with frozen snapshot snap_a (sha256:e6f1...)
  → obtain verified recipient consent through the separately authorized approval channel
  → recipient operator approves → GATE_RECIPIENT_TENANT closed
  → current authorization/data checks → tc_903 → notification confirmed
 
[checkpoint] execute eligibility/evidence → ready for finance approval, not proof of execution
s4 (destructive)
  → propose with frozen snapshot snap_b (sha256:5a3c...)
  → finance lead approves → GATE_FINANCE_LEAD closed
  → current authority/approval/boundary/data checks + budget reservation
  → tc_904 → verified GL entry and postconditions (protected compensation reference retained)
 
[record after verified effect] execute → DECIDED:approved

The session is long_running. Persist an ExecutionCheckpoint at owned recovery points with exact artifact, run, operation and aggregate-budget pins. session_id is a lookup scope, not resume authority. Acquire current ownership/generation, enforce target fencing where required, and revalidate contract support, authority, approval, boundary, external preconditions and original shared budget. Expired approval requires a new approval; changed action or artifact interpretation requires explicit migration and reauthorization.

Approval-channel delivery is separately authorized work: its recipient, payload and credential scope need their own data/effect checks. Sending a notification does not establish recipient consent, and no tenant can approve access on another tenant’s behalf without explicit authority.

5. Post-execution audit

After s4 succeeds, the Critic computes the post-execution audit packet:

• reconciles the posted entry against tax_compliance_check,
• records a protected compensation reference in tool lineage or the effect ledger; raw reversal authority must not be promoted into model-visible memory,
• attaches the full scorecard to the DecisionRecord.

Approval gate contract

{
  "gate_id": "GATE_FINANCE_LEAD",
  "request_id": "req_inv_22",
  "decision_id": "finance.invoice.credit_adjust.execute",
  "approval_mode_required": "destructive",
  "required_approver_role": "finance_lead",
  "frozen_evidence_snapshot": {
    "hash": "sha256:5a3c...",
    "evidence_refs": [
      "tool:adp_invoices.lookup:tc_901",
      "tool:adp_policy.eval:tc_902",
      "tool:adp_recipient.notify:tc_903"
    ],
    "captured_at": "2026-05-04T10:14:00Z"
  },
  "proposed_action": {
    "tool": "adp_gl.post_credit_entry",
    "params": { "invoice_id": "inv_8810", "amount_inr": 12000, "reason_code": "billing_error_correction" }
  },
  "ttl_seconds": 7200,
  "trace_context": {
    "traceparent": "00-9d29...-7c41...-01",
    "baggage": "session_id=sess_inv_22,run_id=run_inv_22"
  }
}

The approver receives a permitted minimized view of the frozen proposal. Once approved, no parameter on proposed_action can change. Bind the complete ActionBinding, including all arguments, both trust-domain scopes, purpose, capability revision, evidence/policy/profile/release refs and INR amount in minor units. Abbreviated hashes and trace IDs here are display placeholders, not valid proof. A divergent binding requires new approval. Validate current approver entitlements, distinct quorum and any self-approval prohibition, then atomically redeem the stored approval for the same stable operation.

Approval response

{
  "gate_id": "GATE_FINANCE_LEAD",
  "decision": "approve",
  "approver": "user_finance_lead_77",
  "approver_assertion": { "method": "webauthn", "token_ref": "auth_3z..." },
  "rationale": "Vendor-side billing error confirmed; complies with policy R_BILLING_CORRECTION_V2.",
  "decided_at": "2026-05-04T10:25:00Z"
}

Audit artifact contract

The runtime persists one audit record per gate:

{
  "audit_record_id": "audit_inv_22_GATE_FINANCE_LEAD",
  "gate_id": "GATE_FINANCE_LEAD",
  "request_id": "req_inv_22",
  "decision_id": "finance.invoice.credit_adjust.execute",
  "approval_mode_effective": "destructive",
  "frozen_evidence_snapshot_hash": "sha256:5a3c...",
  "approver": "user_finance_lead_77",
  "approver_assertion": { "method": "webauthn", "token_ref": "auth_3z..." },
  "proposed_action_hash": "sha256:71b9...",
  "executed_action_hash": "sha256:71b9...",
  "match": true,
  "decided_at": "2026-05-04T10:25:00Z",
  "executed_at": "2026-05-04T10:25:11Z",
  "reversal_token": "effect-ledger-ref:inv_8810_compensation",
  "trace_id": "9d29..."
}

Two properties matter most:

• proposed_action_hash and executed_action_hash must match — the action that ran is the action that was approved.
• reversal_token identifies the governed compensating operation; keep the sensitive token in the protected effect ledger and place only a resolvable reference in DecisionRecord lineage.

Matching hashes establish binding only after trusted verification; they do not prove dispatch or completion. Persist the stable OperationIntent before dispatch with atomic revision/generation checks. On a lost acknowledgement, record unknown and retain uncertain budget reservations until verified provider reconciliation; retry only with current provider-specific idempotency guarantees or definitive absence evidence under the configured recovery strategy. Compensation is a new governed operation with fresh authority, policy, approval and budget checks, and can fail or leave a partial effect.

Approval + audit sequence

Error packets

Approval denied

{
  "audit_record_id": "audit_inv_22_GATE_RECIPIENT_TENANT",
  "gate_id": "GATE_RECIPIENT_TENANT",
  "decision": "deny",
  "approver": "user_recipient_finops_3",
  "rationale": "Counterparty disputes credit basis; require formal billing dispute first.",
  "frozen_evidence_snapshot_hash": "sha256:e6f1..."
}

The Critic returns escalate; the DecisionRecord status becomes REJECTED; no GL entry is posted.

Policy denial mid-flow

{
  "envelope_version": "contextos.tool_result.v1",
  "tool_call_id": "tc_902",
  "run_id": "run_inv_22",
  "trace_id": "9d290000000000000000000000000001",
  "capability_id": "adp_policy.eval",
  "status": "rejected",
  "output": {},
  "artifacts": [],
  "citations": [],
  "mutations": [],
  "risk_tags": ["policy_denied"],
  "policy_decision_id": "pol_2210",
  "error": "TAX_COMPLIANCE_BLOCK: tax compliance check failed; manual review required.",
  "latency_ms": 48,
  "metadata": { "rule_ids": ["R_TAX_COMPLIANCE_BLOCK"] }
}

runtime_controls.must_escalate triggers; the runtime emits a must_escalate envelope to the operator’s queue and the DecisionRecord status becomes ESCALATED.

Cross-tenant invariants

• The tenant_id of the requester (tenant_acme_prod) never grants access to the recipient tenant’s records; cross-tenant reads return only the consent record.
• The recipient tenant approves at the policy level; the named approver is from the recipient tenant’s role registry.
• The audit record links to both tenant scopes; reciprocal access is granted only through explicit policy and redacted views.

Failure modes specific to high-risk

• Approver assertion method is weaker than the gate requires (e.g., password instead of WebAuthn) — gate refuses.
• proposed_action_hash differs from executed_action_hash — runtime aborts and emits a security event.
• Compensation reference lost or unindexed — recovery becomes manual; protect the token in the effect ledger and verify lookup during reconciliation drills.
• Snapshot freshness exceeded by the time the approver responds — runtime re-takes the snapshot and re-prompts the approver with the new hash.
• Gate TTL elapses without a decision — DecisionRecord status DEFERRED; any later resume requires current checkpoint ownership and a fresh valid approval within the run’s remaining limits.
• Stop requested during a provider call — propagate cancellation and fence stale workers; retain confirmed, partial or unknown effects until reconciled. Cancellation acknowledgement is not rollback or verified absence.

Common misconceptions

• High-risk needs demonstrated controls. Stricter declarations require actual enforcement, denied cases, recovery tests and owned escalation paths for the exact workflow and release.
• Approval is not a notification. It binds a complete frozen action under current eligible authority and validity conditions.
• Compensation is a separately governed effect. A protected reference supports recovery; it does not guarantee restoration of the original business state.