A refund workflow needs to establish more than whether it can send money. It needs to establish whether this refund is permitted, which conditions apply, and whether someone must review it before it reaches the payment system. Those questions belong in the process that authorises the action. Answering them afterwards can explain a mistake, but the money may already have left.
Governance before execution means checking a proposed action against the applicable rules before allowing its effects. In Synedrix OS, that responsibility belongs to the shared operating layer. A business workflow uses the controls as part of its execution, so each new agent or integration does not have to invent its own approval process.
The platform is in active development. This article explains the architecture and what its implementation must enforce. Defining separate agents and rules provides a contract to build and test; it does not by itself demonstrate that every possible execution route respects that contract.
The decision has to come before the action
Consider an illustrative refund process. A business permits routine refunds within a defined limit, requires a manager's decision for some larger requests, and prohibits others under its active policy. An agent gathers the order information and proposes a refund. The proposal still needs a decision before a component with payment access carries it out.
A review step added after the payment can help identify errors. It cannot perform that pre-action job. Moving the review earlier helps, but its placement is only part of the problem. Another workflow, a retry handler or a direct tool call might still be able to submit the same payment without reaching the check. The team has to examine every route that can produce the effect.
This is the practical meaning of Principle 4 (Governance before execution). Policies and approvals are enforced centrally. The Governance & Controls Layer, Layer 9, owns policy rules, approval mechanisms, authority checks and risk thresholds. Domain execution logic belongs elsewhere. The part that evaluates permission has a different responsibility from the part that knows how to issue a refund.
That separation makes both responsibilities easier to examine. A reviewer can ask whether the proposed refund satisfied the rules without also having to infer the rules from payment code. The payment integration can be tested for its own behaviour while the surrounding execution path is tested for whether an unauthorised proposal can reach it.
The check must control whether execution proceeds. A message telling an agent to be careful, or a log entry reporting that it exceeded a threshold, leaves enforcement unresolved. The workflow needs a binding result and defined behaviour for each outcome, including the cases where execution has to stop or wait.
What the Policy Guard decides
The Policy Guard Agent (os-agt-002) evaluates a proposed action against the active rules. Its input identifies the action and payload, the requesting agent, the workflow and the domain. A correlation ID, a shared identifier connecting records from the same work, helps preserve the relationship between the proposal and its decision.
The guard returns allow, block or escalate, with a reason and information about whether human review is required. Its decision scope, the class of decision it is authorised to make, is approve. It can validate or block a proposal, but it does not execute the business action. Its own governance records are separate from issuing the refund.
The Orchestrator Agent (os-agt-001) coordinates the work and respects that decision. It sequences tasks and delegates business effects to the appropriate agents through governed invocation. Ordinary coordination and a proposed financial transaction are different operations: approval checkpoints follow the workflow's declared requirements, and a high-impact action enters the pre-execution policy gate.
In the refund example, an allow result lets the orchestrator proceed through the permitted execution path. It means the proposal has passed this policy decision. Any other applicable controls still belong to the workflow; the result is not general permission for the agent to make whatever payment it chooses next.
A block stops the proposal in the current workflow invocation. A human approval cannot reverse that result. If the responsible person concludes that the policy or threshold should change, that change must be made and the action proposed again for a fresh evaluation. The original blocked attempt remains a blocked attempt.
An escalate result sends the decision to a person through the HITL Gateway Agent (os-agt-004). HITL means human in the loop: the workflow requires a human decision at a designated point. The gateway routes the request to the appropriate reviewer and captures the result. Approval lets the workflow continue; rejection halts it. A timeout escalates to an operator rather than becoming an automatic approval.
Escalation and a policy block have different meanings. In this illustrative policy, a larger refund may be eligible for a manager's review, while a prohibited refund remains blocked. Giving both cases the same “approve anyway” button would erase the distinction the rules are meant to enforce. Human responsibility includes deciding the rules and handling the decisions they delegate to people.
Rules need an explicit place in the system
An agreement in a meeting can establish what a business wants, but software needs an explicit representation of that agreement. The agent specification includes policy bindings, the references connecting an agent to the governance configuration that applies to it. These include policy packs, an approval matrix, compliance labels and a kill-switch group.
A policy pack groups applicable rules. An approval matrix identifies the review requirements. Compliance labels identify relevant classifications, while a kill-switch group associates the agent with a defined group for stopping activity. These fields make governance part of the agent's declared configuration. Their presence alone is not proof that the runtime applies them correctly.
For the refund workflow, the useful questions become concrete. Which rule permits a routine refund? Which condition sends a request to a manager? Which reviewer role is required, and what happens when nobody responds? The implementation must connect those answers to the actual proposal being evaluated. A general instruction to “follow company policy” leaves too much unspecified.
Versioned definitions also matter when reviewing an outcome. A reviewer needs to establish which configuration governed the request at the time, rather than apply today's threshold to an older decision. The evidence should connect the action, its requesting agent, the relevant decision and the work that followed. That is a design obligation to verify in the runtime and audit records.
The values still require judgment. A threshold set too low can send routine work to people unnecessarily. A threshold set too high can permit actions the business intended to review. Central enforcement makes the chosen rule consistently applicable; it cannot decide whether the business chose an appropriate rule. People remain responsible for that choice and for examining its consequences.
Who owns the mechanism and who sets the values
The shared platform owns the governance mechanism, while domain packs and business instances supply the policies and configuration within their scope. This division lets different businesses use common controls without pretending they all have the same rules.
A domain pack supplies the business-specific capabilities and definitions that run on the platform. A commerce pack can contribute refund policies and declare approval points. A trading pack can contribute policies appropriate to trading. Both use the shared policy and approval framework. Domain-specific knowledge belongs in the pack, while the common mechanism for evaluating and routing decisions remains with the OS.
A business instance is a concrete deployment of the platform with its packs and configuration. It sets the company's thresholds and assigns approvers. In the refund example, one company may require review at a different amount from another. That is a difference in configured values within the allowed model, rather than a reason to build a separate approval engine.
The distinction also limits what configuration can do. A pack must not bypass governance or observability, and an instance must preserve the shared platform's boundaries. Setting a refund threshold does not grant permission to remove the policy check. Assigning a manager as an approver does not allow that manager's response to reverse a policy block within the same invocation.
This creates a useful way to discuss a new requirement. If it concerns how proposals are evaluated across every business, it belongs with the shared framework. If it concerns what a refund means, it belongs with the domain. If it concerns this company's permitted amount or reviewer assignment, it belongs with the instance. Keeping those responsibilities explicit makes changes easier to review without moving business logic into every layer.
What a working implementation must demonstrate
Adding governance to an existing workflow is possible, but the work goes beyond inserting one review node. The team must identify the routes that can produce business effects and bring them under the required checks. Otherwise, the normal route may be controlled while a recovery path retains broader access.
For the refund example, a useful verification follows the actual payment operation. An allowed proposal should reach it only under the applicable permissions. A blocked proposal should stop before it. An escalated proposal should wait for the required decision, and a timeout should follow its declared escalation behaviour. A retry or alternate integration should preserve those controls.
The same review should inspect the evidence. It needs to be possible to connect the payment attempt to the proposal and the decision that permitted it. If a record is missing, the system has an explanation gap even when the amount looks reasonable. A successful outcome alone cannot establish that the action was authorised correctly.
There is an operational cost. Policy evaluation adds work, human review adds waiting time, and an unavailable control can interrupt a business process. Those costs need explicit failure handling and measurement. Improving them means examining rules, routing and implementation while retaining the pre-action requirement. Treating an absent decision as permission would leave the central question unanswered.
For a team designing its first refund workflow, the next step is to specify what may proceed automatically, what requires a person, and what must stop. Then test those cases at the point where the payment can actually happen. That is where governance becomes an enforceable part of execution and where an architectural claim can be checked against behaviour.
Related reading
- The 12 principles that make agentic systems trustworthy — introduces Principle 4 (Governance before execution), which this post follows into the decision taken on a single proposal.
- One substrate, many domains: the domain pack model — explains the split between the shared platform, domain packs and business instances that decides who sets each governance value.
- Memory isn't a bucket: how Synedrix OS separates kinds of truth — the previous post, which ends where this one begins: following a request through the checks it passes before an action proceeds.
Documentation
- Governance & Controls: the layer that owns policy rules, approval mechanisms, authority checks and risk thresholds.
- Agent registry: the Policy Guard, Orchestrator and HITL Gateway definitions, with their inputs, outputs and decision scopes.
- Agent Spec: the policy bindings each agent declares, including policy packs, the approval matrix, compliance labels and kill-switch groups.
Synedrix OS — governance before execution
