Approval intents and safe resume

BailingHub emits approval intents for agent-triggered tool calls. It does not replace an enterprise approval system. The hub pauses and freezes a call; the business system decides who may approve and still performs final authorization on resume.

Approval intent

{
  "kind": "tool_approval_request",
  "approval_id": 123,
  "job_id": "job_...",
  "route": "inventory_ops",
  "provider": "erp",
  "tool": "inventory.adjust",
  "scope": "inventory.write",
  "risk": "high",
  "on_behalf_of": "tenant_1:user_1001",
  "args": { "store_id": 8, "sku_id": 10086, "delta": -20 },
  "args_hash": "sha256:..."
}

Return the decision

POST /approvals/{approval_id}/decision

{
  "kind": "tool_approval_decision",
  "schema_version": "bailing.approval-decision.v1",
  "approval_id": 123,
  "job_id": "job_...",
  "request_id": "req_...",
  "args_hash": "sha256:...",
  "decision_id": "oa:approval:9001",
  "decision": "approved",
  "approver": "user_2002"
}

Only approved and denied are valid. decision_id is the business approval system’s idempotency key; args_hash must match the frozen call.

0.9.2: continuation of recorded decisions

External callbacks and the console save the decision and immutable continuation coordinates in one transaction. Retry the original decision_id after an audit or queue failure; maintenance also checks unfinished continuations. A recorded decision with failed continuation returns 503 with decision_recorded=true / continuation_pending=true. Do not create another approval.

Original-job admission and a separate decision marker are atomic, with a consumed-approval check inside the admission critical section. Lost acknowledgements, process reopening and a completed later run do not requeue the same decision. An original job still in flight waits for maintenance. Denials only complete auditing; consumed decisions and historical decisions without new continuation records are not automatically backfilled. Lost audit acknowledgements may produce repeated observations with the same detail.continuation_id. Admission deduplication does not guarantee exactly-once business effects across systems.

Direct Agent invocations still require the original local Agent to explicitly resume the original invocation_id; approval does not launch a Core model loop. Apply 066 and matching state/config continuation interfaces before upgrading. New decisions are explicitly unavailable with unsupported custom adapters. See the 0.9.2 upgrade guide and reliability and rollback boundaries.

Conditions that must still hold on resume

The trusted subject is still valid;
route, provider, and exact operation are still allowed;
normalized arguments have not drifted;
approval is unexpired and unconsumed;
final tenant, permission, and state checks still pass in the business system.

A timeout does not prove that the tool failed. Reconcile unknown finality using the same business idempotency key before any retry.