Governed actions
A governed action expresses an intended change so it can be examined, authorized, approved and recorded before reaching an external system. This is a conceptual explanation of the behavior illustrated by the public technical demo, not private implementation topology.
What object should change, and what precisely is being proposed? A suggestion alone does not execute a write.
Is this action permitted in the application's scope and under the operator's confirmed configuration?
Is approval bound to this intended action? The technical demo illustrates an approval binding as a structural prerequisite, with requester and approver separated.
The technical refund demo records the attempt before the external call. A lost response is classified honestly; approval does not guarantee that an external action succeeds.
Retain the decision path and observations so an operator can inspect what was decided and what remains uncertain.
The whole system audit database is not claimed to be one tamper-evident chain. Retained records and chain verification answer different questions. In the technical refund demo, the reconciliation verdict is derived from the recorded command and observations, not stored as a verdict, and never rewrites command truth.
Deterministic synthetic data and scripted AI assistance demonstrate business behavior and governance boundaries. No live ERP/MES is contacted; no commercial Framework execution is proven. Approval is simulated.
Follow the business story →Synthetic data and simulated approval; only the transport is substituted. Execution behavior above that transport belongs to the separately licensed Framework. Re-running requires that private Framework.
Read the technical scenario →These concerns are design goals and demonstrated behaviors, not security, legal, regulatory or compliance certification. No universal exactly-once guarantee is implied.
Read the public governed-actions document →