The proposal is only the beginning.

Illustrative scenario: a fictional composite written to make the point concrete. It does not describe a real organisation, and its figures are not reported outcomes.

A fresh procurement scenario

A facilities team needs replacement environmental sensors for an office monitoring system. Its existing purchasing application holds supplier approval, available budget and order state. An agent could assemble a draft requisition from permitted catalogue information. It has no right to place an order merely because it can call a tool.

This scenario is original to this review and does not reproduce the book’s governed-procurement lab. No purchase, supplier contact, payment or customer integration is executed by the site.

1. 1 / Frame the requestProcess owner defines the equipment need, specification, permitted suppliers and success measure. Uncertain details remain questions.
2. 2 / Form the proposalThe assistant drafts exact items, quantity, supplier, integer amount in minor currency units and destination from permitted sources.
3. 3 / Authenticate and evaluateThe gateway obtains verified identity, delegation and policy inputs. OPA or Cedar can evaluate a defined contract; the model cannot declare its own checks successful.
4. 4 / Bind human approvalWhere required, an authorised reviewer approves the exact action version and digest, tenant, scope and expiry. A changed action returns for evaluation and approval.
5. 5 / Recheck at commitmentThe purchasing backend checks current supplier and budget state and atomically reserves or commits within its transaction model. A prior state hash alone does not prevent a race.
6. 6 / Record the resultLink pre-action evidence to the downstream receipt and actual state. A denied action has no transaction receipt. A timeout may leave the result unknown pending reconciliation.
7. 7 / Verify evidenceOptionally sign and anchor approved non-sensitive metadata through a separately designed transparency service. Verify trust material and proofs, not just HTTP success.
8. 8 / Operate and learnOwners review exceptions, quality, cost and recovery. A purchase order is not proof that the equipment need was met.

OPA and Cedar evaluate policy, not business transactions

OPA evaluates structured input with Rego. Cedar expresses permission rules over principals, actions, resources and context. Their integration contracts differ. Cedar’s authorisation semantics include default denial and forbid precedence; application states such as escalation and revised proposals sit outside that permission decision.

A separate local review package contains illustrative Rego and Cedar rules and test cases. Those engines are not installed or executed by this release; the rules are not presented as a working integration. OPA’s test framework is the appropriate place to execute Rego cases when implementing the adapter.

MAEB must reflect what is known at each point

The Minimum Action-Evidence Bundle (MAEB) is a proposed CAE design construct, not an industry standard. At a high level, retain who proposed an action, the evidence and policy behind its decision, what was permitted and what the authoritative system actually did. Keep immutable pre-action evidence separate from a later execution receipt and link them explicitly.

The supplied candidate schema needs review: a transaction ID cannot be required before a transaction exists, and a signature cannot include itself in its signed payload. Exact serialisation and signing mode must be specified. RFC 8785 JCS defines a constrained canonical JSON representation; sorting keys alone is insufficient. A state digest aids integrity checks but cannot guarantee reconstruction or safe re-execution. The full candidate schema remains outside public content, consistent with the existing editorial boundaries.

Rekor adds transparency evidence under a separate trust model

Sigstore Rekor records signed metadata and supports checks on log inclusion and consistency. Select supported entry types and verify trusted keys or certificate policy, checkpoints and retained verification material. See the bundle format and signature verification documentation.

Keep confidential evidence in an access-controlled store. Do not send customer bundles or sensitive metadata to a public log. Even digests may expose information through guessing or correlation. A private deployment needs a separate operational assessment.

Log inclusion alone does not prove recording preceded a business effect. If pre-commit anchoring is mandatory, the gateway must enforce that verified prerequisite and preserve sequencing evidence. The log and purchasing database are separate systems, so crashes and outages still need handling. Revalidate mutable state at commitment. For post-commit anchoring, retain a durable pending record and reconcile it; failed log publication must not erase a successful transaction.

No OPA, Cedar, Sigstore, signing key, HSM or transaction gateway is integrated or tested by this informational release. These are designs for further implementation and review, not verified procurement automation.