# AI Execute signed approval and recovery

Public documentation revision 3 · October 7, 2026
Applies to RC15.3 candidate / Managed API 0.1.0rc3. SDK bytes are unchanged.

The trusted customer backend, not an agent, owns the source order record. It
signs this exact schema using an issuer-specific secret of at least 32 bytes:

```json
{
  "record": {
    "schema": "haltseal.source-approval.v1",
    "tenant": "merchant", "issuer": "orders",
    "source_order_id": "order-42", "customer_id": "alpha",
    "approved_budget_micro": "20000000", "revision": 1,
    "expires_at": 1791331200, "status": "APPROVED"
  },
  "signature": "64 lowercase hex characters"
}
```

The timestamp above is illustrative; use a current expiry no more than 30 days
away. Signature = HMAC-SHA256(secret, canonical JSON(record)): sorted keys,
compact separators, ASCII escapes, no NaN. The order system and gateway share the
secret; agents and browser code never receive it. Treat signing ability as budget
approval authority. HMAC does not provide third-party non-repudiation.

`POST /v1/businesses` requires an active admin key and a valid signature/audience.
Use the returned `business_id` as an opaque identifier for every attempt.
Customer ownership is immutable. Amounts are cumulative totals, never
incremental credits: importing the same approval cannot double the budget.
Higher revisions must not lower the total; changed same-revision content and
stale revisions are refused. A signed REVOKED record retains the cumulative
total and blocks new dispatch. To renew, sign a higher APPROVED revision.

Issuer/key rotation requires a separately reviewed continuity migration.
Do not assume changed credentials transfer existing authority or exposure.
A new issuer namespace must not be used to rename an existing source order.
A trusted source that signs duplicate semantic orders or incorrect budgets can
violate the upstream business premise; this candidate cannot discover that fact.

Operator-issued keys can bind `customer_id`. Live key access is rechecked for
create, dispatch, resume, get, lookup, scope, business, receipt, cancel and recover.
A delegated key cannot read or spend another customer's business or an unrelated
funded scope. Read keys cannot dispatch; they may trigger read-only provider
recovery and deterministic settlement of existing authorized exposure.

Use the returned business ID and retain one `attempt_key` for each intended
job. An identical request reads the existing execution; changed content under
the same key conflicts. Registered aliases and changed access keys do not add
budget or transfer customer ownership. A different attempt still draws on the
same remaining approved total. `max_cost_micro` cannot reduce the reservation
required by the provider contract.

## Original recovery and deployment limits

Persist the business ID, attempt key and exact request before execution. After
a lost gateway reply, look up that same identity. If it is not yet visible,
retain it and repeat only the identical gateway request. Do not resend a
provider POST directly or change providers to escape an uncertain outcome.
Recover the existing execution; recovery does not dispatch a successor.
Incomplete or conflicting evidence retains exposure. Verified final-cost
evidence settles once; a held successor needs explicit resume and fresh checks.
Cancellation alone does not refund exposed work.

This is one-host local evaluation. Backup restoration, joint-history rollback,
host migration and automatic history migration are not qualified. Existing
RC2 databases are refused. Preserve historical consumption and unresolved work
through any separately reviewed cutover. Do not reset history to restore budget.
Operator procedures accompany the evaluator under agreed technical-review scope.
Native AI provider calls, customer paths and independent operators remain zero.
Production is NO_GO; no paid hosted endpoint or availability SLA is offered.