Core Principles
Overview
Synedrix OS is a multi-agent operating system: the governed operating layer for agentic business systems. It provides orchestration, governance, shared context, and observability so that specialised agents can coordinate to run business domains under explicit human and policy control.
This document defines the 12 core principles that guide the design and implementation of Synedrix OS across all domain packs, business instances, and deployment modes. They are the canonical reference for every governance argument in the platform and in the public content series. Later material cites them by name and number, for example “Principle 4 (Governance before execution).”
Humans move up the stack to strategy, policy, and exception management. Agents absorb the repetitive coordination and execution work inside those boundaries.
Positioning
Synedrix OS is the governed operating layer for agentic business systems. It coordinates specialised agents across workflows, tools, and data while preserving human control, policy enforcement, and operational trust. It is open source and self-hostable: it can run entirely within a customer’s own infrastructure, including with local model inference, with no dependency on external APIs or cloud services.
Principle clusters
The 12 principles group into five concerns. Numbering is canonical and fixed. Clusters are defined by meaning, so a cluster may span non-contiguous numbers. The north star is Principle 10 (Trust is the real product); the other eleven principles serve it.
| Cluster | Principles | Concern |
|---|---|---|
| Safety | 1, 4, 5 | Keeping an agent inside its lane |
| Architecture | 2, 3, 12 | Keeping the system maintainable as it grows |
| Human control | 6, 8 | Where human authority sits and how the system stays responsive |
| Accountability | 7 | How the system explains itself |
| Platform | 9, 10, 11 | The substrate everything runs on, and the point of it |
1. Bounded autonomy
Every agent operates within an explicit authority envelope: what it may recommend, what it may execute, which systems it may access, and when it must escalate. These boundaries are machine-readable and enforced by the platform, not implicit in prompt text. Low-risk reversible actions can be automated; high-impact or irreversible actions must pass through policy checks and, where configured, human approval.
2. Orchestration is the center of gravity
Coordination quality, not model power, is the durable value. The orchestrator decomposes goals into tasks, selects workflows, routes work to specialised agents, manages retries and sequencing, and coordinates approvals. Models, tools, and agents may change over time; stable coordination patterns are what persist.
3. Specialised agents over mega-agents
Narrow, testable, governable roles beat one “do everything” agent. Each agent has a clear mission, input and output contracts, allowed tools and systems, memory scope, execution scope, approval requirements, and an escalation path. Specialisation improves modularity, fault isolation, and the ability to evolve the system independently.
4. Governance before execution
Governance is load-bearing infrastructure, not a wrapper bolted on after deployment. Policies, permissions, approval thresholds, and audit controls are enforced centrally, so agents can propose actions without being allowed to bypass trust, compliance, or safety requirements.
5. Shared context with scoped access
Agents are connected to a shared context fabric of systems of record, operational memory, event histories, and telemetry. Access is always bounded by role, policy, and mission. Least privilege is the default.
6. Humans stay above the automation layer
Humans define goals, constraints, policies, escalation thresholds, and exception-handling rules. Both human-in-the-loop and human-on-the-loop patterns are supported based on risk and reversibility. The principle is human oversight, not human exclusion.
7. Explainability and audit by design
The system must always be able to answer three questions about any action: what happened, why it happened, and under whose authority it happened. Logs, traces, decision evidence, and policy lineage are core features, not optional compliance add-ons.
8. Event-driven execution
Signals, approvals, product changes, failures, anomalies, and callbacks trigger workflows the moment they happen. Agent coordination reflects the actual movement of the business rather than waiting for humans to poll systems manually or for jobs to fire on a schedule.
9. One substrate, many domains
The OS is domain-agnostic at its core. Trading, commerce, support, operations, finance, and future verticals inherit the same orchestration, governance, memory, and observability foundations, while each contributes its own domain pack carrying the entities, tools, agents, and policies particular to it.
10. Trust is the real product
Performance and efficiency matter, but they are meaningful only when the system is reliable, governable, observable, and aligned with human accountability. Trust is the ultimate output of the platform and the north star the other eleven principles serve. A serious business delegates meaningful work to agents only when autonomy stays within bounds, decisions can be explained, and human control remains intact where it matters most.
11. Open by default, sovereign by design
Synedrix OS is open source and self-hostable. Every component of the platform, from orchestration to memory stores to model inference to observability, can run entirely within a customer’s own infrastructure, with one recorded exception: the inbound Hookdeck Event Gateway (Layer 8) is a proprietary managed cloud service with no self-hosted option. ADR-OS-013 considered replacing it with an open self-hosted receiver and rejected that; the exception is accepted and stands. No business data, no agent decisions, and no operational logic are required to leave the customer’s environment, but inbound event payloads transit Hookdeck’s cloud before reaching it. Where a data plane is operated by Synedrix on a customer’s behalf (the managed variant in ADR-OS-008, available in Modes 1 and 2 only), “within a customer’s own infrastructure” is read as infrastructure dedicated to that tenant and operated for it, never pooled across tenants, with every capability also available self-operated so the tenant can move between variants. See the Deployment Model Spec §1.1.
Three canonical deployment modes are governed by this principle (see the Deployment Model Spec for the authoritative specification):
Mode 1 — cloud-connected. All platform components run self-hosted (the inbound Hookdeck Event Gateway excepted, as in every mode). Model inference uses external APIs. Data flows to model providers for inference only; no business data is stored externally. Suitable for organisations comfortable with standard cloud data processing agreements.
Mode 2 — self-hosted-hybrid. All platform components run self-hosted (the inbound Hookdeck Event Gateway excepted). Some agents use external model APIs, others use local models via Ollama or vLLM. The mix is declared per agent in the runtime policy. Suitable for organisations that want local inference for sensitive workflows and external models for lower-sensitivity tasks.
Mode 3 — air-gapped (fully local). All platform components run self-hosted except the inbound Hookdeck Event Gateway, which is Mode 3’s single declared external dependency. All model inference uses local models, with no outbound connection or external API call of any kind, and no business data leaves the customer’s infrastructure. Inbound event payloads are held in transit by Hookdeck before delivery. Suitable for regulated industries, government, defence, and any environment where data sovereignty is non-negotiable.
The deployment mode of a business instance is a first-class configuration field. It constrains the model routing available to all agents in that instance. An air-gapped business instance cannot declare cloud model URIs in any agent runtime policy; this is a validation invariant enforced by the OS. Open source is also a trust property: an organisation should be able to inspect, audit, and operate every component without depending on proprietary black boxes — save the one accepted Hookdeck exception above.
12. Deterministic idempotency, explicit state
Every side-effecting step carries an idempotency key, so where the target system honours it a retry, a redelivered event or a replay produces the same outcome and never duplicates the effect. A step whose tool cannot honour a key is declared non-idempotent in its tool contract. The platform never retries or replays such a step automatically: after a failure its outcome is treated as unknown, and it resolves only through reconciliation against the target system’s own record or through human escalation. All state an agent or workflow depends on is declared, versioned and recoverable. Nothing lives only in ambient prompt context, an in-flight process or a hidden cache. A run can be resumed, replayed or audited from its recorded state alone.
The determinism claimed here is of effects and state, not of model reasoning. A model may phrase or choose differently on each call. The platform guarantees that a repeated step lands on the same outcome where the target honours the key, that a step whose outcome is unknown is never repeated blindly, and that what the system knew when it acted can be read back. This is what lets Principle 8’s event-driven execution and Principle 2’s retries and sequencing be trusted at scale, and what lets Principle 7’s audit be reconstructed rather than inferred.
Intended use and scope
These principles govern all platform design, agent configuration, domain pack authoring, and published content. Deployment sovereignty (Principle 11) and its three modes are in scope for every business instance. The principles are domain-agnostic; domain packs inherit them without modification and add domain-specific entities, tools, agents, and policies on top.
Versioning
Version: 0.8
Supersedes: v0.7
Canonical principle count: 12
Status: OS-level canonical — single source of truth for Synedrix OS principles
Related Documents
- Synedrix OS — Vocabulary — Canonical glossary; the Governance register maps to these principle names; the deployment sovereignty addendum defines the terms in Principle 11.
- Synedrix OS - Deployment Model Spec — The authoritative specification for the three deployment modes; the enforcement companion to Principle 11.
- Synedrix OS - Agentic Enterprise Manifesto Outline — Vision and strategic rationale; the beliefs stated there are formalised as these principles.
- Synedrix OS - Taxonomy & Platform Spec — Canonical taxonomy (pre-voice lineage).
- Synedrix OS - Layer Taxonomy Table — Authoritative 12-layer definitions (pre-voice lineage).
- Synedrix OS - Consolidated Canonical Reference — Consolidated synthesis; §2 mirrors these principles.
Synedrix OS · Core Principles v0.8 · governed operating layer for agentic business systems