Layer 9 of 12·Slice: Governance and observability·Platform: No dedicated platform

Scope of this page. Reference material for the Governance & Controls layer: what it owns, what it must not own, and how Synedrix OS implements it today. It is descriptive, not normative — where this page and the Layer Taxonomy Table disagree, the taxonomy table wins.

What this layer is

Governance & Controls enforces policy, permissions, approvals, and compliance. It is the layer that decides whether a proposed action is allowed to happen — not whether an agent or workflow is capable of doing it, which is a Layer 5 (Agent Registry) and Layer 6 (Tool Abstraction) question, and not what the action itself accomplishes, which is domain logic that this layer must never absorb.

This layer is deliberately not one platform. It is realized as a policy schema — the tool_authorization_policy, mcp_tool_policy, and a2a_tool_policy structures defined in the Agent Runtime Policy Spec — enforced at runtime by a small set of Control-family OS agents that hold decision_scope: approve: they validate or block a proposal, but none of them executes the action itself. That split matters because Synedrix OS’s authority model draws a hard line between deciding and doing. recommend agents propose, approve agents gate, and only execute-scoped agents may trigger a side effect — and every execute-scoped agent still passes through this layer’s checks first. The invariant that “no agent writes to production systems without policy-aware orchestration visibility” is enforced here, not aspirational elsewhere.

flowchart LR
  n1([Governance Controls]):::term
  subgraph What it owns
    n2[The approval engine]:::agent
    n3[Policy rules]:::agent
    n4[Authority checks]:::agent
    n5[Risk thresholds]:::agent
    n6[Audit controls]:::agent
  end
  n1 --> n2
  subgraph What it must not own
    n7[Domain-specific execution logic and entities]:::warn
    n8[Domain Pack Layer]:::term
    n7 --> n8
    n9[Workflow sequencing retries and routing]:::warn
    n10[Orchestration Layer]:::term
    n9 --> n10
    n11[Normalized adapters to external systems]:::warn
    n12[Tool Abstraction Layer]:::term
    n11 --> n12
    n13[Memory record content]:::warn
    n14[Memory Data Layer]:::term
    n13 --> n14
  end
  n1 --> n7
  subgraph Interfaces with
    n15[Human interfaces]:::check
    n16[Orchestration]:::check
    n17[Registry]:::check
    n18[Tools]:::check
  end
  n1 --> n15

What it owns

Per the Layer Taxonomy Table, Governance & Controls owns the following:

  • The approval engine — human-in-the-loop routing, structured decision capture, and review-timeout enforcement.
  • Policy rules — the ruleset a proposed action is evaluated against before execution proceeds.
  • Authority checks — enforcement of decision_scope (recommend / approve / execute) and the three-layer tool authorization model: capability ceiling (agent spec) → runtime restriction (runtime policy) → instance override (business instance), where each layer can only restrict what the layer above it granted, never expand it.
  • Risk thresholds — risk-score gating on individual actions and the promotion-blocking risk_alignment_score check that keeps a medium, high, or critical risk-tier agent out of active status while a blocking evaluation suite is failing.
  • Audit controls — the write-side mechanism that produces the policy-decision and approval records other layers later read; this is distinct from audit retrieval, which belongs to the read-only Audit & Lineage Agent at Layer 10.

What it must not own

This layer decides whether an action may proceed; it must never become the layer that performs the action, sequences the surrounding work, or holds the state the action touches.

ConcernCorrect owner
Domain-specific execution logic and entitiesDomain Pack Layer
Workflow sequencing, retries, and routingOrchestration Layer
Normalized adapters to external systemsTool Abstraction Layer
Memory record content — the Memory Access Broker resolves recall/write scope but never reads the memory content itselfMemory & Data Layer
Making execution measurable, explainable, and reviewable after the factObservability

Interfaces with

Governance & Controls sits between the surfaces that raise a decision and the layers whose actions that decision gates.

  • Human interfaces — every approval request the HITL Gateway Agent routes terminates in a human reviewer through a Layer 1 surface, and every timeout or contested decision escalates back up through that same surface.
  • Orchestration — the pre-execution policy gate is inserted directly into the orchestrator’s task graph: a domain agent’s proposed high-impact action does not proceed to execution until Policy Guard returns allow, and a block decision halts the workflow rather than being silently retried.
  • Registry — the capability ceiling this layer’s runtime authorization can only restrict is declared in the Layer 5 agent registry entry (tool_permissions); Governance & Controls narrows that declared set, it never widens it.
  • Tools — MCP- and A2A-backed tool calls are submitted to Policy Guard at tool-call time, not at authorization-resolution time, whenever mcp_tool_policy.require_mcp_approval or a2a_tool_policy.require_a2a_approval is set, which keeps this layer on the critical path of every governed tool invocation rather than a one-time check at startup.

How Synedrix OS implements it

The Responsibility Matrix splits this layer’s concerns three ways. Synedrix OS owns the policy engine framework and the HITL approval framework as shared primitives every domain depends on. Domain packs contribute domain-specific policies and declare their own approval points — where in a workflow a human must be asked. Business instances own the values: which approvers are assigned, what thresholds trigger a gate, and what risk tolerance is configured for a given tenant. The same split repeats for tool authorization — the OS owns the tool_permissions schema and the ceiling rule that a tool absent from it can never be activated by any runtime policy or instance override; domain packs declare each agent’s capability set and any domain-default restrictions; business instances may only narrow the active tool set further per environment, never widen it.

The Agent Runtime Policy Spec is the concrete enforcement model. At invocation time, orchestration computes the resolved active tool set by applying the ceiling, then the runtime policy’s tool_authorization_policy (all / declared / restricted), then any environment_overrides, and the agent executor rejects any tool call outside that resolved set, emitting agent.tool.unauthorized. MCP-backed tools carry an additional policy layer: mcp_write_approval_required defaults to true for every write-capable MCP call, and require_mcp_approval defaults to true for risk_tier: high or critical agents, meaning every such call is submitted to Policy Guard before execution — this is the concrete mechanism behind the invariant that no MCP or A2A interaction bypasses governance. A2A delegation carries its own trust-tier vocabulary (trusted / provisional / untrusted); trust tier sets the default approval posture, but it never substitutes for the Policy Guard check when require_a2a_approval is set. The spec also extends this same governance model to the second execution engine: when an agent’s runtime_engine is langgraph rather than n8n-aiagent, it must satisfy a governance bridge — Policy Guard reachable from inside LangGraph nodes, HITL Gateway reachable via a durable graph interrupt, and the same resolved active_tool_set enforced identically — so that a second execution engine cannot become a shadow runtime that quietly skips this layer.

Runtime policy also treats several canonical Layer 10 metrics as inputs rather than as data it may redefine: cost_drift_flag, tool_success_rate, hallucination_probability, semantic_validity_flag, and risk_alignment_score can trigger a model downgrade, a tool suspension, an escalation, or a promotion block, but the metric definitions themselves remain owned by the Observability Metrics Spec — Governance & Controls consumes them, it does not mint them.

Platform mapping

The Layer Taxonomy Table’s platform mapping has no row for Layer 9: there is no single product that realizes it. Governance & Controls is implemented through the policy schema described above and the three Control-family agents below, running as governed steps inside whichever engine (n8n or LangGraph) hosts the invocation — not as a separate platform in the twelve-platform stack.

OS agents at this layer

Three OS-owned agents are registered at this layer, all family: Control and all decision_scope: approve — each validates or blocks a proposal; none of them executes the underlying action.

Agent IDNameDecision scopeWhat it does
os-agt-002Policy Guard AgentapproveEvaluates a proposed action against the active policy ruleset and returns a binding allow / block / escalate decision that the Orchestrator Agent must respect. A block is final within the current workflow invocation and no human decision, including a HITL approval, reverses it; a human changes the policy and the action is re-proposed (ADR-OS-018).
os-agt-004HITL Gateway AgentapproveManages the human-in-the-loop approval surface for every workflow that requires human review: routes approval requests to the correct reviewer, captures structured decisions, enforces review timeouts, and returns a binding approved / rejected / timeout outcome. It relays the human’s decision; it does not interpret or override it.
os-agt-012Memory Access Broker AgentapproveMediates every memory recall and write proposal, resolving the requester’s declared scope against its memory_profile before any store is queried, and returns an allow / partial / deny decision. It never reads memory content itself — it resolves scope and pushes filter predicates down into the query, because out-of-scope content that has already entered a process has already leaked. A denial is terminal; the requester escalates rather than retrying automatically.

Layer principles that apply

  • Layer Principle 2 — Controls before execution. This is this layer’s defining principle: execution paths must pass through governance and observability instead of bypassing them for convenience. The three-layer tool authorization model and the pre-execution policy gate are that principle made concrete — a proposal cannot reach a side effect without first clearing this layer.
  • Layer Principle 1 — Shared before specific. The policy engine framework and the HITL approval framework are reusable across every domain pack, which is why they live here rather than being reimplemented per pack.
  • Layer Principle 4 — Memory is shared, access is scoped. The Memory Access Broker’s every-recall mediation is this principle enforced at runtime: agents need shared context, but access to it must remain selective and policy-aware.

Synedrix OS · Layer reference · Governance & Controls