C.1 Agent mandate template
| Field | Complete before release | Synthetic filled example |
|---|---|---|
| Purpose and owner | Authorized business task and one accountable process owner. | Invoice reconciliation; finance operations owner. |
| Excluded uses | Actions outside the mandate, including downstream influence. | No beneficiary changes, credit decisions, or unreviewed external advice. |
| Action classes and autonomy | Separate read, prepare, send, modify, transact, and privilege actions. | A0 scoped reads; A1 drafts; A2 exact approved payments. |
| Data and sources | Tenant, classification, purpose, freshness, and rights. | Approved invoices and purchase orders for the assigned tenant. |
| Tools and effects | Tool schemas, destinations, resource ownership, and alternate routes. | Query invoices; stage reconciliation; gateway-mediated payment. |
| Limits and delegation | Time, cost, exposure, depth, concurrency, and shared budget. | No independent child payment grant; budget persists across retries. |
| Approval | Reviewer authority, evidence, exact scope, permitted variation, and expiry. | Review invoice match and bind beneficiary, amount, currency, and account. |
| Outcome verification | Business postcondition and independent oracle. | Exactly one expected payment confirmed from resource state. |
| Failure and halt | Dependency response, operator, revocation, descendants, and pending effects. | Hold on policy or receipt uncertainty; resource owner reconciles. |
| Release and change | Configuration identity, tests, challenge, exceptions, and expiry triggers. | Approved manifest; permission/schema/model changes reopen affected evidence. |
C.2 Deployment manifest template
Record mandate ID and version; business and platform owner; model/provider/serving version or visibility limit; harness and instruction digest; tool schemas and adapters; credentials and grant policy; source and retrieval versions; memory transformations and retention; monitor/trigger/feedback versions; fallback; topology and global budgets; policy and event schema versions; approved evaluation and release record.
Protect the manifest from agent edits. A digest establishes an integrity join to the recorded object; it does not establish that every hidden vendor component is known. Record unresolved upstream versions and their effect on the assurance claim.
C.3 Risk and threat record template
| Field | Required content |
|---|---|
| Scenario and consequence | Specific failure mechanism, affected resource or person, and possible effect. |
| Entry point and conditions | Data, identity, access, tool, state, workload, and dependency assumptions. |
| Trust boundary | Where information or authority changes its permitted interpretation. |
| Prevention and detection | Component, owner, effect route, timing, and failure response. |
| Test and oracle | Normal case, induced failure, attack budget if relevant, and external observation. |
| Residual gap | Observed failure, untested route, uncertain version, or data limitation. |
| Decision | Permitted authority, exception, compensating control, expiry, and restart condition. |
C.4 Approval record template
Record workflow and initiating principal; reviewer identity and authority; proposed effect and normalized action digest; resources and subjects affected; allowed batch variation; data scope; relevant evidence; decision and reason; issuance and expiry; policy and configuration version; execution comparison; receipt and postcondition.
An approval form should show the difference between the request, proposed effect, and verified outcome. A generic instruction to proceed should not be interpreted as approval for an unspecified payment, disclosure, or changed destination.
C.5 Evaluation and release record template
Record the decision being supported, configuration, mandate and proposed autonomy; prohibited effects; eligible tasks and strata; case provenance; labeling/adjudication; oracle validation; attack model and budget; deterministic invariants; threshold errors and timing; paired utility; customer outcomes; recovery; failures; exclusions; uncertainty; holdout separation; independent challenge; bounded authorization and expiry triggers.
Report tests that failed, were inconclusive, or could not run. A status of proposed specification is different from an observed pass. The test catalog in Appendix D is a starting set; it does not cover every business task or effect route.
C.6 Incident and corrective-action record template
Record first signal; confirmed and unknown effects; severity and affected people; configuration; authority and approvals; containment action and effective time; descendants, queues, callbacks, and credentials; independent state reconciliation; custody; legal reporting determination; customer remedy and lookback; root mechanism; repair; retained failure cases; new evaluation; accountable restart or retirement.
C.7 Included example files
The supplementary files include an example mandate, control event, and proposed JSON event schema. They are synthetic implementation aids. Example digest strings illustrate field relationships and are not computed signatures. The schema validates event structure; it does not prove semantic authorization, completeness, integrity, or deployed enforcement. Appendix E explains the event semantics.