Tip: select any text on this page to bring up the Ask tooltip and question the Synedrix OS assistant about it.
What Governance & Controls is
Governance & Controls enforces policy, permissions, approvals, and compliance. It decides whether a proposed action is allowed to happen, not whether an agent is capable of doing it, and not what the action itself accomplishes, which this layer must never absorb.
This layer is deliberately not one platform: it's a policy schema enforced by Control-family OS agents that hold decision_scope: approve. 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.
What it owns, and what it does not
Every layer in the architecture has a non-overlapping responsibility. The boundary is as much a part of the design as the capability.
Owns
- The approval engine: human-in-the-loop routing, structured decision capture, review-timeout enforcement
- Policy rules: the ruleset a proposed action is evaluated against
- Authority checks: decision_scope enforcement and the three-layer tool authorization model
- Risk thresholds: risk-score gating and the promotion-blocking evaluation check
- Audit controls: the write-side mechanism that produces the records other layers later read
Does not own
- Domain-specific execution logic and entities
- → Domain Pack Layer
- Workflow sequencing, retries, and routing
- → Orchestration Layer
- Normalised adapters to external systems
- → Tool Abstraction Layer
- Memory record content
- → Memory & Data Layer
- Making execution measurable and reviewable after the fact
- → Observability Layer
Interfaces with
The other layers this one exchanges work, state, or decisions with, and why.
Human interfaces
every approval request the HITL Gateway routes terminates in a human reviewer through a Layer 1 surface.
Orchestration
the pre-execution policy gate is inserted directly into the orchestrator's task graph: a block halts the workflow rather than being silently retried.
Registry
the capability ceiling this layer's runtime authorization can only restrict is declared at Layer 5; it narrows that set, never widens it.
Tools
MCP- and A2A-backed calls are submitted to Policy Guard at call time, keeping this layer on the critical path of every governed tool invocation.
How Synedrix OS implements it
The Responsibility Matrix splits this layer's concerns three ways: Synedrix OS owns the policy engine and HITL approval framework as shared primitives, domain packs contribute domain-specific policies and declare their own approval points, and business instances own the values: approvers, thresholds, risk tolerance.
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 runtime policy, then any environment overrides, and the executor rejects any call outside that set. MCP write calls default to requiring approval; A2A delegation carries its own trust-tier vocabulary. The same governance model extends to LangGraph as a second execution engine, so it can't become a shadow runtime that quietly skips this layer.
OS agents at this layer
Policy Guard Agent
control · os-agt-002Evaluates proposed actions against policy rules; emits allow, block, or escalate.
HITL Gateway Agent
control · os-agt-004Routes approval requests to human reviewers, captures decisions, enforces timeouts.
Memory Access Broker Agent
control · os-agt-012Resolves recall scope against each agent's memory profile before any store is queried. Never sees memory content.
Layer principles that apply
- Controls before execution, this layer's defining principle: a proposal cannot reach a side effect without first clearing it.
- Shared before specific: the policy engine and HITL framework are reusable across every domain pack.
- Memory is shared, access is scoped: the Memory Access Broker's every-recall mediation is this principle enforced at runtime.
Governance & Controls questions, answered
Short, citable answers drawn from this page.
What is the Governance & Controls layer in Synedrix OS?
Governance & Controls is layer 9 of the twelve-layer Synedrix OS architecture, in the "Governance and observability" group. Decides whether, never performs. Every execution path passes through it first.
What does the Governance & Controls layer own?
The Governance & Controls layer owns: The approval engine: human-in-the-loop routing, structured decision capture, review-timeout enforcement; Policy rules: the ruleset a proposed action is evaluated against; Authority checks: decision_scope enforcement and the three-layer tool authorization model; Risk thresholds: risk-score gating and the promotion-blocking evaluation check; Audit controls: the write-side mechanism that produces the records other layers later read.
What does the Governance & Controls layer not own?
The Governance & Controls layer does not own: Domain-specific execution logic and entities (owned by Domain Pack Layer); Workflow sequencing, retries, and routing (owned by Orchestration Layer); Normalised adapters to external systems (owned by Tool Abstraction Layer); Memory record content (owned by Memory & Data Layer); Making execution measurable and reviewable after the fact (owned by Observability Layer).
The full reference page, with every canonical specification this layer touches, lives in the documentation repository, which is private while the platform is being built.