Operator Approval Loop

Delivering

The SQLite reference is references/approval_claims.py. It grants dispatch permission but never calls transport. Use an existing local reference database initialized from the SQL fixture; the module does not apply schema or production migrations. Only a trusted decision writer may populate approval records. All writers must enable foreign keys and recursive triggers and honor the schema guards; administrative database tampering is outside this model.

1. Discover bound approved drafts. Discovery is not permission. claim() opens its own BEGIN IMMEDIATE transaction, validates the current approved epoch, exact text, computed SHA-256 and full destination against the snapshot, and inserts a unique claim before returning its token. A conflict stops the worker before transport. Completed receipts cannot be claimed again.
2. begin_dispatch() revalidates the binding and atomically changes claimed to dispatching using the token. Only its winning caller receives the exact draft_text and destination after commit. Never regenerate text, reread a mutable sidecar for transport, or reuse the payload for another attempt. A nested caller transaction is refused; permission cannot depend on a later caller commit. No database transaction remains open across transport.
3. A confirmed successful result goes to complete(), which atomically records the delivery coordinate, marks the claim delivered and flips the obligation to sent. Identical completion is a no-op; conflicting coordinates fail. The receipt UNIQUE key deduplicates records, not prior external effects.
4. Exceptions, timeouts, worker death after begin-dispatch, or failed receipt persistence leave a blocked attempt. mark_unknown() records uncertainty. Unknown claims never expire, reopen, auto-retry or allow another decision for that obligation to bypass them. A trusted caller may use reconcile() with confirmed successful coordinate and evidence; the module does not verify that evidence. An absent receipt is not proof of non-delivery.

The guarantee is one automatic dispatch attempt per approved decision, not exactly-once external delivery. A crash after begin-dispatch but before transport can leave zero sends and a held claim. Releasing an unknown outcome for a new attempt would require fencing the original executor and verifying provider semantics; this reference deliberately provides no such retry operation.

While a claim is active, database guards freeze obligation, draft and decision writes, including replacements. Snapshots and claims cannot be erased. Cancel a claimed operation with its token before re-filing; the stale token then grants nothing. After dispatch begins, hold new edits or revocation for reconciliation. This serializes changes instead of pretending to recall an in-flight operation.

Rejected decisions and legacy rows without draft sidecars/snapshots never enter this external draft-send path. Report them on the internal operator surface for manual handling. Internal receipt footers remain internal: approved by <operator> · receipt <decision_id> · draft sha256 <prefix>. Never alter already-approved external text to append workflow metadata.

Focused local validation uses temporary databases, separate connections and a simulated attempt counter, not a provider or real message: python3 -m unittest discover -s tests/skills -p 'test_approval_delivery_claims.py'. The tests require Python 3.11+ with SQLite serialization support; the reference uses only the standard library. The existing desk-pattern contract checks remain a separate compatibility check.

Time-boxed auto-approval (optional)

A draft may carry auto_send_after (epoch seconds). A sweep approves drafts whose deadline passed with no decision, recording operator auto-ttl, then delivery proceeds through the normal path. Operator actions always win: a decision flips status before the sweep sees it, and a re-file rotates the epoch and moves or clears the deadline. The sweep re-checks status and epoch inside the write transaction so a race resolves as a no-op. Drafts without a deadline stay hard-gated forever.

Signal linkage

A draft can name the inbound obligation it answers (signal_obligation_id). This is the only truthful link for latency measurement (inbound signal to drafted response) and lets the SLA scan treat that inbound item as answered. Reject the filing if the referenced row does not exist.

Examples

File a draft

file_request(
  draft="Thanks, we can hold the slot until Friday. Which start date works?",
  counterparty="acme-supplier",
  context="reply to delivery window question",
  origin_platform="slack", origin_channel="#acme-shared",
  origin_thread="1712345678.000100", priority="P1",
  signal_obligation_id=412)
-> {obligation_id: 431, draft_sha256: "9f2c...", refiled: false}

The configured, verified internal ops destination sees: Draft filed for approval (P1, sha 9f2c8a1b). Waiting on operator. The counterparty-visible origin channel receives no filing notice. If no verified internal destination is available, the receipt stays in the internal tool result or operator surface, with no external fallback.

Re-file after a steer

The operator asks for a shorter draft. Filing again for the same (counterparty, channel) returns refiled: true, the sidecar text and hash change, and updated_at advances. An approve clicked on the old panel row carries the old epoch and is ignored.

Gate refusal

DeskApprovalError: baseline gate refused this draft: the ledger shows a
signed contract for 'acme-supplier'. Evidence: master agreement executed
2026-08-14. Recommendation: do not ask. Re-file with
force_despite_signed_contract=true if this is genuinely a new thread.

Delivery footer in an internal channel

Confirmed for Friday, start date 2026-09-08.
approved by operator-a · receipt 118 · draft sha256 9f2c8a1b2d3e4f50

Invariants to test

• Filing receipts go only to configured, verified internal ops; the origin receives one only when it is that verified internal destination.
• An unknown origin stays quiet. An unavailable internal destination uses the internal tool result or operator surface, with no external fallback.
• Same (counterparty, channel) filed twice yields one obligation, two epochs.
• A decision with a stale epoch never results in a delivery row.
• Two concurrent claimants yield one dispatch permission; losers never attempt transport.
• Unknown outcomes and failed receipt persistence never enable an automatic retry.
• Successful completion records the receipt and sent status in one transaction.
• An altered epoch, text, hash or destination cannot acquire or begin a claim.
• Active claims block re-file; only pre-dispatch cancellation can release that hold.
• Gate unavailable stamps the marker; gate signed refuses without force.
• Auto-ttl never fires against text the operator has since re-filed.