Governance and Controls

Synedrix OS Layer 9 is where execution meets accountability. Governance is not a surface applied to agents after the fact — it is load-bearing infrastructure embedded at every point where an agent proposes an action. The system enforces a “controls before execution” invariant: no work proceeds through Layer 3 (Orchestration) or Layer 4 (Agent Runtime) without passing through the policy and approval gates defined here.

This page covers the five pillars of that model: the Policy Guard Agent’s final block decisions, the HITL Gateway’s human-approval routing, the derived L0–L5 autonomy levels, the AI-native organisational model with six canonical human control roles, and the three-layer tool authorization model. It is governed by ADR-OS-010 (autonomy levels), ADR-OS-015 (organisational model), ADR-OS-017 (authority conventions), ADR-OS-018 (block finality), and ADR-OS-028 (agent accountability invariants).

Policy Guard: the finality gate link

The Policy Guard Agent (os-agt-002) is the execution gate that every proposed action must pass through before proceeding. Its mission, declared in the agent registry, is to “evaluate proposed actions against the active policy ruleset before execution proceeds, enforce authority boundaries, apply risk thresholds, and emit a binding allow / block / escalate decision that the Orchestrator Agent must respect.”

How policy evaluation fits into the request path link

Every action follows this path:

1. The Orchestrator (os-agt-001) proposes an action to Policy Guard through the tool-level gate at invocation time.
2. Policy Guard evaluates the action against the active ruleset stored in Supabase, using a policy rule engine with risk scoring and authority boundary checking.
3. Policy Guard returns one of three decisions: allow, block, or escalate.

flowchart TD
    A["Proposed Action"] --> B["Policy Guard Agent\nos-agt-002"]
    B --> C{"Decision"}
    C -->|allow| D["Execute"]
    C -->|block| E["Terminal blocked"]
    C -->|escalate / requires_hitl| F["HITL Gateway Agent\nos-agt-004"]
    F --> G{"Human decision"}
    G -->|approve| H["Re-evaluate policy\nthen execute"]
    G -->|reject| E

The evaluation draws on:

• Policy rules in Supabase’s policy store (the ruleset itself is owned by the human risk owner, not the agent).
• Risk scoring computed from the action’s payload, the requesting agent’s risk_tier, and the task’s side_effect_class.
• Authority boundary checks derived from the requesting agent’s decision_scope, can_* flags, governance_class, and approval_required declaration.
• Instance-level thresholds from the business instance configuration (set by the business instance owner).

Block finality link

ADR-OS-018 settled a canon contradiction where some documents said only a human override could reverse a block and others said HITL approval does not bypass Policy Guard. The decision was no override exists. A Policy Guard block is final for the blocked action within the invocation:

• At a policy node, the invocation terminates with a blocked outcome.
• At the wrap_tool_call safety net, the model receives a refusal and the run may continue only to return refusals, never to execute the blocked action. When the refusal budget escalates, the run terminates.
• A run suspended by Escalation must not resume by retrying the blocked action. Either it terminates as blocked, or the human changes the policy and the action is re-proposed as a new invocation with a new identity.

A human who believes the block is wrong changes the policy rules or the instance thresholds; the action is then re-proposed and evaluated afresh. There is no emergency escape hatch for a wrong block. The remedy is a governed policy change (owned by the human risk owner) followed by re-proposal.

Implementation enforcement points:

• The Policy Guard Agent takes risk_tier: critical (ADR-OS-017 §4, item 5), meaning policy compliance checks are blocking and the agent must meet a compliance rate of 1.0 per the Agent Evaluation Spec.
• Gate-agent task classes like validate-policy are listed in neither autonomous_task_classes nor approval_required_task_classes (ADR-OS-017 §3.3).

Governance class and risk tier link

Every agent declares a governance_class (autonomous, policy-gated, hitl-required) and a risk_tier (low, medium, high, critical). The two answer different questions:

• governance_class records whether the agent’s own actions need a gate. A gate agent declares autonomous — it is itself the gate, not gated.
• risk_tier measures how much harm a failure could cause. Policy Guard is critical because a failure in its evaluation could let any ungoverned action through.

Tooling must not read oversight from governance_class alone for a gate agent; it must read risk_tier and family as well (ADR-OS-017 §3.3).

HITL Gateway: where human authority lives link

The HITL Gateway Agent (os-agt-004) is the boundary between machine autonomy and human authority. It is not a confirmation dialog — it understands monetary thresholds, reputational risk, legal consequences, confidence, irreversibility, policy exceptions, customer impact, employee impact, and security sensitivity.

Approval chain mechanics link

A workflow declares an approval_requirements object listing the policy and HITL gates it needs. When Policy Guard returns escalate or requires_hitl, the HITL Gateway Agent:

1. Routes the approval request to the appropriate reviewer_role holders in scope.
2. Captures the structured human decision (decision, reviewer_id, rationale, decided_at).
3. Enforces a timeout, escalating to senior reviewer and then human operator on expiry.
4. Returns a binding outcome to the Orchestrator.

The HITL Gateway does not interpret or override the human decision it receives. It captures, routes, enforces timing, and returns the outcome.

Separation of duties and policy re-evaluation link

Two invariants govern HITL:

• Separation of duties. A user who initiated a request cannot approve it, in any step and by any role or delegation. The rule takes effect when the approval request carries a requester_principal_id (Identity and Access Spec §7, rule 2).
• Policy is re-evaluated after approval. HITL approval never bypasses Policy Guard: both must pass, and a human cannot approve past a Policy Guard block (ADR-OS-018). The human risk owner changes the ruleset and the action is re-proposed as a new invocation.

Escalation path link

The HITL Gateway’s escalation path terminates at the senior reviewer and then the human operator. Its own governance_class is autonomous (it is a control, not a governed actor), but it does require a non-empty approval_required object — { policy: false, hitl: false } — with a note that it is itself a governance control (ADR-OS-017 §3.4).

Autonomy levels: the derived L0–L5 ladder link

The canonical autonomy classification is derived, not declared. It is computed from the existing authority fields at four grains, with consistency rules that prevent the overlap from contradicting itself.

Mapping L0–L5 link

The effective level as most restrictive link

The effective level of a task is the most restrictive of four bounds, ordered by gate strength (not by number):

1. Agent bound. can_* flags, decision_scope, and governance_class. policy-gated rules out L3; hitl-required makes every executing task L5. decision_scope: recommend caps everything at L2.
2. Task-class bound. requires_approval rules out L3; autonomous and not requires_approval allows up to L3. A class that sets both, or neither, is rejected by consistency rules.
3. Task bound. The Task’s approval_mode, policy_required, and side_effect_class. An irreversible task with approval_mode: policy is L4. An irreversible task with approval_mode: none is rejected.
4. Business-instance bound. An override in agent_instance_controls.overrides scoped by business_instance_id. This may only narrow authority, never widen it.

An irreversible task is never L3 and is L5 only if a human gate is declared. side_effect_class none and low form the L3 band; high and irreversible can never be L3. A conditional task is classified by its stricter outcome for reporting, and its actual level is known only when the condition evaluates.

Consistency rules link

The following contradictions are rejected during registry validation:

• can_execute false with a task class whose tasks have side_effect_class above none (an autonomous class that executes nothing is valid).
• A class that sets both autonomous and requires_approval, or neither, for an executing task.
• governance_class: autonomous with approval_mode: hitl, or hitl-required with any approval_mode other than hitl on an executing task.
• policy_required: true with approval_mode: none.
• side_effect_class high or irreversible with approval_mode: none.
• A task class above its agent’s decision_scope bound.
• An execute-scope agent with an empty approval_required object.

A new agent version that widens authority triggers a blocking on-authority-change evaluation gate (ADR-OS-010 §4, item 10).

Authority conventions link

Several conventions resolve ambiguities in how authority fields are declared:

• Own-output writes are not execution. A record, cache, telemetry, declared event, or designated audit record the agent creates and owns is not execution (ADR-OS-017 §3.1). A write to any other system of record is execution.
• The agent-level approval declaration is approval_required, an object with policy and hitl keys, present on every agent. Omitting it or either key fails the check. An all-false object is valid only with a delegation note naming where gates are inserted (ADR-OS-017 §3.4).
• risk_tier has four values: low, medium, high, critical. No control-plane value exists.

The AI-native organisational model link

Synedrix OS should not be modelled as twelve AI employees reporting to a CEO. The better abstraction is an AI-native operating layer beneath a small human leadership structure:

The human org chart defines accountability. The Synedrix OS work graph defines execution.

These are two overlapping structures over one organisation. The twelve OS agents constitute a shared horizontal control, intelligence, and organisational-memory plane beneath a human accountability layer, with domain-pack agents below them (ADR-OS-015 §4, item 1).

The four-plane view (a projection, not a taxonomy) link

The twelve agents can be grouped into four functional planes for organisational description:

flowchart TD
    subgraph Orch["ORCHESTRATION"]
        O["Orchestrator\nos-agt-001"]
    end

    subgraph CP["CONTROL PLANE"]
        PG["Policy Guard\nos-agt-002"]
        RG["Registry & Capability\nos-agt-003"]
        HG["HITL Gateway\nos-agt-004"]
        AL["Audit & Lineage †\nos-agt-008"]
    end

    subgraph IP["INTELLIGENCE PLANE"]
        AN["Analytics\nos-agt-005"]
        FC["Forecasting\nos-agt-006"]
        AD["Anomaly Detection\nos-agt-007"]
        GC["General Chat ‡\nos-agt-009"]
    end

    subgraph MP["MEMORY PLANE"]
        MC["Memory Curator\nos-agt-010"]
        CR["Consolidation & Reflection\nos-agt-011"]
        MB["Memory Access Broker\nos-agt-012"]
    end

    O --> CP
    O --> IP
    O --> MP

Each plane answers a distinct organisational question:

• Orchestration: What needs to happen?
• Control: Are we allowed to do it, who can do it, and should a human intervene?
• Intelligence: What does the data tell us about what is happening and what may happen next?
• Memory: What does the organisation already know, and what should it learn?

The four-plane view is a presentation projection, not a taxonomy. family and layer assignment remain authoritative for every agent. Two agents are drawn outside their family because it reads better organisationally: os-agt-008 (family: observability) is drawn beside the control agents, and os-agt-009 (family: intelligence at Layer 4) is drawn in the Memory Plane. Both carry a marker and are stated plainly.

† Audit & Lineage is strictly read-only. It must never appear in any agent’s tools_allowed list. No work flows into it from any agent; it is reached by a human query. ‡ General Chat is target state. Its current registry declares it decision_scope: recommend with no owning workflow, invoked directly rather than through the orchestration layer. The routing role shown is deferred pending approval_required.policy: true and re-certification through the governance bridge (ADR-OS-015 §4, item 4).

The six OS-level human control roles link

The human control roles are derived, not designed. Each appears because an OS agent’s escalation_path terminates there, or because the Responsibility Matrix assigns it a Business Instance value. No role may be added to this set without a derivation of the same kind.

A role is an accountability surface, not a job title. A single person routinely holds several control roles. Domain-pack and business-instance roles (such as trading-operator or mrd-owner) are instantiations of these roles within a pack or instance, never additions to the OS-level set.

Who may assign. Role assignments are owned by the business instance, changed only by a business instance owner. At every moment each business instance must have at least one currently valid business instance owner — the last one cannot be removed, and the platform rejects any change that would leave a gap (Identity and Access Spec §3, rules 2–5).

What humans still own link

Humans retain accountability rather than routine coordination. The Board owns governance and fiduciary responsibility; the CEO owns corporate purpose, strategic direction, and business outcomes. Executives own domain outcomes and define acceptable autonomy. Managers increasingly own priorities, exception handling, coaching, and judgment. Subject-matter experts remain responsible for difficult domain judgments.

Legal, risk, security, and compliance leaders define policies and risk appetite. Policy Guard enforces those policies; it does not decide what the company’s ethical or legal policy ought to be. Humans also retain decisions involving substantial irreversible consequences: major hiring and firing, significant financial commitments, legal commitments, strategic partnerships, and sensitive customer situations.

The six control roles are the machine-readable interface Synedrix OS uses at runtime to know which human to route a decision to — a narrower set than the full organisational accountability model.

The three-layer tool authorization model link

Tool authorization follows a three-layer model where each layer can only restrict, never expand, the permissions granted by the layer above it. A tool not declared in the agent spec’s tool_permissions can never be activated at runtime — the capability ceiling is inviolable.

Resolution flow link

At agent invocation time, orchestration computes the active tool set:

1. Reads tool_permissions from the agent registry entry (capability ceiling).
2. Reads tool_authorization_policy from the active runtime policy (runtime restriction).
3. Applies any environment_overrides for the current deployment environment (instance restriction).
4. Passes the resolved active tool set to the agent executor.
5. The agent executor rejects any tool call referencing a tool not in the resolved set, emitting agent.tool.unauthorized.

Policy-protected tool categories link

Two special tool categories receive additional governance:

• MCP-backed tools. Governed by mcp_tool_policy within the runtime authorization layer. Default: require_mcp_approval: true for agents with risk_tier: high or critical. mcp_write_approval_required defaults to true and must be explicitly set to false to disable.
• A2A (Agent-to-Agent) tools. Governed by a2a_tool_policy. Trust tiers are trusted, provisional, and untrusted. Trust tier governs default approval posture but does not bypass the Policy Guard — when require_a2a_approval: true (default: true for all agents), all A2A invocations are submitted to Policy Guard regardless of trust tier.

Runtime engine governance bridge link

When an agent runs on LangGraph (runtime_engine: langgraph) instead of n8n, the LangGraph executor must satisfy a governance bridge that ensures the second engine does not bypass any of the n8n host’s controls (Orchestration & Runtime Strategy §5):

Cyclic and multi-agent execution patterns (iterative, consensus, reflect-and-revise, hierarchical) MUST use runtime_engine: langgraph. Acyclic patterns may use either engine.

Ownership split: OS, domain pack, and business instance link

Governance responsibilities follow the standard three-tier responsibility split:

Domain packs must not bypass OS governance or observability. Business instances must not fork shared OS abstractions. Every domain-agent entry must declare an escalation_path, restrict family to domain or customer (not control or observability), and set approval_required.policy: true for any financial, regulated, or irreversible external write.

Runtime enforcement: where controls actually fire link

Governance is enforced at three runtime surfaces:

Policy Guard at tool-call time. Not at resolution time. When mcp_tool_policy.require_mcp_approval: true, a2a_tool_policy.require_a2a_approval: true, or when the tool’s approval_tier in the agent spec requires it, the Policy Guard Agent is invoked before the tool executes. This is where policy rules are evaluated against the specific action payload.

Tool authorization at agent-executor time. The resolved active_tool_set is passed to the agent executor, which rejects any tool call outside the set. This is the enforcement of the capability ceiling — a tool the agent spec never mentions can never appear in any runtime grant or instance override.

Memory Access Broker at recall time. The Memory Access Broker (os-agt-012) resolves the requester’s declared scope against its memory_profile and returns allow | partial | deny before any store is queried. The filter predicates are pushed down into the query. It never inspects retrieved records and filters them after the fact — out-of-scope memory that has already entered the process has already leaked. A denial is terminal; the requester escalates rather than retrying.

Governed accountability invariants (ADR-OS-028) link

ADR-OS-028 adopted five independent accountability obligations that apply across every delegated execution — n8n, LangGraph, domain-pack agents, and business-instance configurations. These are not aspirational; each is a machine-enforceable constraint at an architectural boundary.

Every agent acts for an explicit purpose, within delegated authority, produces traceable evidence, handles uncertainty honestly and claims completion only when the applicable conditions are satisfied.

The five invariants link

1. Explicit purpose. Every agent invocation MUST identify a tenant-scoped, versioned task or goal reference, an objective, an originating principal, constraints, and a declared outcome contract. The orchestrator MUST request clarification or use an approved default contract when a task has no success criteria; it MUST NOT invent consequential acceptance criteria. Discovering a new objective mid-execution requires fresh delegation or an authorized plan amendment.

2. Delegated authority. Effective permissions are the intersection of registry permissions, originating principal’s delegable scope, agent runtime policy, business-instance restrictions, deployment rules, tool scope, and applicable approvals. Delegation MUST NOT widen permissions beyond the delegator’s authority or the agent’s registry ceiling. Every consequential side effect MUST be checked at a guarded tool boundary, including writes initiated from LangGraph and resumed graph nodes. A denial, missing decision, expired approval, mismatched policy version or unavailable required guard MUST result in no dispatch of the guard-required call and an explicit blocked/escalated outcome for that action. A denial at the wrap_tool_call safety net is final for that action but need not terminate the invocation: the run may continue with a compliant alternative, and the invocation ends blocked only when no compliant path remains.

3. Traceable evidence. The system MUST maintain reconstructable lineage linking originating intent, plan and version, actor, delegation, policy decision/version, human approval where applicable, tool intent, tool effect evidence, and terminal invocation outcome. Correlation and trace IDs are not substitutes for durable audit records. Audit records MUST be append-only or equivalently tamper-evident with defined retention and access controls.

4. Honest uncertainty. Agent outcomes MUST distinguish observed facts, inferred conclusions, assumptions and unresolved unknowns. When material evidence is missing or contradictory, the agent MUST report uncertainty and MUST NOT claim the underlying action or outcome was verified. Unknown external effects MUST result in a reconciliation-required status rather than automatic success or unsafe retry. Material unresolved uncertainty MUST block claims of successful business completion.

5. Conditional completion. The system MUST distinguish invocation termination (including timeout/failure), side-effect confirmation (a specific external write or action is verified), and business-goal satisfaction (applicable success conditions are met). An agent MAY propose that work is complete, but authoritative business completion MUST be determined by a governed acceptance evaluation with evidence references. Terminal invocation records MUST be emitted for all started invocations; an explicit failed, blocked, timed-out or unknown terminal outcome does not indicate business success.

Governance lifecycle link

flowchart TD
    H["Human / originating principal"] --> G["Goal & acceptance contract"]
    G --> P["Plan & scoped delegation"]
    P --> R["Registry eligibility / active tools"]
    R --> A{"Policy authorizes action?"}
    A -- No --> B["Blocked or escalated; record outcome"]
    A -- Approval required --> W["Durable HITL checkpoint"]
    W --> A
    A -- Yes --> X["n8n or LangGraph execution"]
    X --> T["Guarded tool boundary"]
    T --> A2{"Per-action policy check"}
    A2 -- Deny --> B
    A2 -- Refused, compliant alternative --> X
    A2 -- Refused, no path --> B
    A2 -- Allow --> E["Effect attempt + immutable evidence"]
    E --> U{"Effect confirmed?"}
    U -- Unknown --> Q["Reconcile; no unsafe replay"]
    Q -- Confirmed --> C
    Q -- Failed --> F
    Q -- Unresolved --> O
    U -- Failed --> F{"Safe to retry?"}
    F -- Yes --> X
    F -- No --> O
    U -- Confirmed --> C["Acceptance evaluation"]
    C -- Conditions met --> S["Business objective satisfied"]
    C -- Unmet / insufficient --> N["Not complete: continue, escalate or close"]
    B --> O["Terminal invocation record"]
    N -- Continue --> X
    N -- Escalate or close --> O
    S --> O

Governed remediation lifecycle link

Remediation is a governed corrective process, not automatic retry or crash recovery. Detection of a deviation does not confer authority to fix it; original execution grants do not automatically cover reversal, compensation, resource changes, or process amendments.

Required state machine:

1. Detect and record: capture deviation, original goal/process/invocation identifiers, evidence, severity and affected resources.
2. Diagnose: distinguish verified causes, hypotheses, missing evidence and impact; do not invent certainty.
3. Plan: state corrective objective, permitted options, expected effects, risks, dependencies, deadlines and explicit remediation acceptance criteria.
4. Authorize: resolve the actor’s current delegated authority and policy version; re-evaluate each proposed side effect. Require separate HITL approval when risk, action class or grants demand it. A previous approval does not transfer automatically.
5. Execute: route through the same guarded tool abstraction in n8n or LangGraph, with idempotency controls, checkpoints and bounded retries.
6. Verify: independently compare observed post-action state with remediation acceptance criteria and check for residual effects; a successful tool response is insufficient.
7. Settle: mark resolved only with sufficient evidence. Otherwise mark unresolved, partially_remediated, blocked, or escalated as appropriate, preserving both the original failure and corrective history.

No remediation action may erase or rewrite the original immutable evidence.

Failure and safety semantics link

Verification gates link

ADR-OS-028 defines 17 integration tests (GA-01 through GA-17) that must pass in an integrated reference workflow before the ADR is considered operationally implemented. Key gates include: invocation rejection without a valid purpose contract (GA-01), tool authorization blocking outside registered authority with zero side effects (GA-02), refusal to elevate own permissions (GA-03), fail-closed guard enforcement across n8n and LangGraph (GA-04), expired approval blocking action (GA-05), reconciliation preventing duplicate non-idempotent writes (GA-06), uncertainty visibility when evidence is incomplete (GA-07), separation of invocation success from business satisfaction (GA-08), crash recovery with exactly one terminal record (GA-09), full audit reconstruction (GA-10), multi-tenant isolation (GA-11), process version pinning during execution (GA-12), and remediation case linkage without unauthorized writes (GA-13 through GA-17).

Layer responsibility mapping link

ADR-OS-028 distributes accountability invariants across the layer architecture:

The system preserves all invariant requirements across n8n-to-LangGraph handoffs. Domain packs and business instances SHALL NOT redefine the canonical meaning of authorization, evidence or completion.

Open items and future decisions link

The following items remain undecided and are explicitly tracked:

• Per-capability grain. The autonomy ladder is derived per task class. Whether tool-level authority from the Tool Authorization Model should refine a level is not decided (ADR-OS-010 §8).
• Reversibility. side_effect_class none and low form the L3 band. Whether low always means reversible in practice is not settled.
• Per-operation strength. os-agt-010 (Memory Curator) declares { broker: true, policy: true } but the registry carries one agent-level approval object. Whether a broker decision counts as a policy gate, and how per-operation approval strength is represented, belongs to a later decision (ADR-OS-010 §8).
• Enforcement for irreversible work. Whether an irreversible task must be HITL-gated is an enforcement question outside the current canon.
• Emergencies and override paths. A governed policy change is the only remedy for a wrong block. A future emergency escape hatch would require its own event, record, and authority level (ADR-OS-018 §4).