The governance model

• Execute. Inside policy, the action runs without waiting for anyone.
• Route. The action needs authority, so it goes to the role that holds it. That is not necessarily the person in the conversation. The approver is reached on an Adaptive Card in Microsoft Teams or in Sherpa Approvals, and the first decision wins.
• Block. A hard rule applies, and no approval overrides it. The block is recorded like any other outcome.

Thresholds are set per loop and per commercial exposure, not per model. The same rules bind people: cumulative exposure counts agents and people together, so no agent gets more latitude than the person it assists.

Approval is a control. Execution is a cost. Exos Systems

Every loop follows one path, and each stage maps onto the Sherpa envelope.

Control sits in the path of the call, not in the prompt. Sherpa agents never write on their own authority. Only Exosphere holds write scopes, and an outage stops writes rather than passing them through.

Before deciding, Exosphere resolves the facts that matter to authority:

• the initiating principal's role and limit
• the action type and the loop it belongs to
• the value against the applicable limit
• the customer segment
• cumulative exposure, per contact and per period
• an open dispute or a bill on hold
• a vulnerability flag

The most restrictive outcome applies. Block outranks route, and route outranks execute. Anything unmatched or unresolvable goes to a person, and an unknown fact fails closed. Segregation of duties keeps a proposer from approving their own proposal.

Rules enforce. The corpus grounds. Each recommendation cites the clause of the operator's own credit policy or delegation-of-authority matrix that supports it.

Illustrative policy, not commercial terms. Each operator sets its own limits and roles.

• Signed, single-use, expiring. The approval request cannot be replayed, or stretched to cover a changed action.
• Re-validated at execution. Policy and data are checked again at the moment of action. If the facts have changed, the approval lapses and the proposal is evaluated afresh.
• Once per proposal id. Exosphere's orchestration writes each approved action exactly once. That idempotency is Exosphere's design, consistent with the TMF630 task and monitor patterns.
• Applied, refused or unconfirmed, never assumed. Under TMF630, a 202 Accepted means the request was taken, not that it took effect. An unconfirmed write is read back before it is reported, and it is never shown as success.
• Compensation follows the original approval. Multi-step work runs as a saga. If a later step fails, the cancellation (for example TMF622 cancelProductOrder, itself tracked through a monitor) runs under the approval that started it. A rejected cancellation escalates to a person.

The lifecycle: proposed, policy evaluated, then executed inside policy, awaiting a person, or blocked. Approved proposals are re-validated, executed once, and confirmed, refused, unconfirmed or compensated. Every path ends in the audit record. See propose, approve, execute for the sequence.

The Canvas gateway enforces identity and scope. Exosphere adds business authority above it. TM Forum's AI-Native direction gives people the ability to constrain, correct and terminate agents at any autonomy level, and Exosphere sets autonomy per action type. See earning autonomy.

Exos Systems is a TM Forum member and aligns to ODA. Standards bodies named here describe the context we work in; they are not an endorsement by those bodies.