Put an explicit authority boundary in front of consequential external calls.

Payments, trades, and application mutations become governed only when the owning integration routes the exact call through ORBIT. These are integration patterns, not packaged connector claims.

Scope an integration Read the Stripe boundary

Illustrative scenarios · not live integrations

The contract is reusable; the enforcement path is specific.

Held

Payment pattern

payout.create USD 8,000

Required boundary: The application must route the payout call through a reviewed enforcing integration.

Blocked

Trading pattern

open position outside mandate

Required boundary: The broker order path must consult ORBIT before submission for the denial to prevent it.

Allowed

Application pattern

issue support credit inside limit

Required boundary: Permission covers the exact request; the application reports execution separately.

Non-collapse rule

Permission, execution, and verification remain separate facts.

Request

The integration submits the exact actor, action, scope, and relevant typed facts.

Authorization

ORBIT returns Allowed, Held, or Blocked under the current rule and proof gates.

Execution report

The external system separately reports attempted, completed, failed, or unknown.

Verification

A proof check validates its stated artifact boundary; it does not invent execution.