operator-approval-loop

Topics in the source

• Operator Approval Loop
• When to Use
• How It Works
• Objects
• Filing a draft
• Baseline gate
• Deciding
• Delivering

An agent that talks to external counterparties should never send on its own judgment and should keep the operator informed internally. This skill defines the contract: every outbound draft is filed as an obligation, an operator decides on the exact text, and a delivery ledger proves what went out. An agent drafts replies to customers, suppliers, investors, or partners in a shared channel, email, or chat, and a human must approve before send. You need an audit trail that links each sent message to the exact draft text, the operator who approved it, and the decision time. You have seen a stale approval release a rewritten draft, or two workers deliver the same approved message twice. Drafts keep re-asking counterparties for facts the ledger already holds. | Object | Meaning | | --- | --- | | Obligation | One thing we owe a counterparty. Status moves drafted, then approved or rejected, then sent. Carries direction, counterparty, channel, and an updatedat epoch. | | Draft | Sidecar row holding the exact draft text, a sha256 of that text, origin coordinates (platform, channel, thread, user), and priority (P0 to P3). One per obligation, replaced on re-file. | | Decision | An operator's a

This is an excerpt. Refer to the complete source and its current requirements.