Product documentation
Architecture
Control-plane authority model and replayable event lineage.
Scope
Current architecture is local embedded control plane inside the syndicate binary. Governance claims apply only to enforced paths that pass through this control plane boundary.
Exclusions
Control plane authority does not extend to external systems that do not route through Syndicate Code, offline/degraded operation, social engineering on operators, or correctness of model outputs.
What is the architecture?
The [control plane] is authoritative for policy decisions. Runtime proposes operations; control plane authorizes or denies.
Every enforced action passes through control-plane checks before execution. This is what makes governance structural instead of advisory.
The [event store] records every execution with provenance that cannot be retroactively modified.
Direct answer
[Control plane] is the authoritative system for governance decisions.
[Control plane] evaluates [policy] before execution—not within the model runtime.
[Control plane] denies any action where arguments diverge from approved [digest].
[Event store] persists append-only records of actor, action, approval, and outcome.
Repository content is treated as untrusted input for policy and execution decisions.
Core system properties
"The event store is the authoritative evidence layer for governed actions."
The [event store] is append-only once written.
The [event store] records which [policy] version was in force.
The [event store] enables deterministic replay of what happened, who approved, and what executed.
[Event provenance] cannot be retroactively modified.
Authority model
Runtime isolation from policy enforcement is the architectural boundary that makes governance possible.
Runtime proposes candidate operations.
[Control plane] validates and authorizes execution.
[Control plane] enforces [policy] on declared capabilities.
[Control plane] issues cryptographically bound, time-scoped capability leases (permits) for approved actions.
[Control plane] denies unauthorized execution.
[Event store] records actor, action, [approval binding], outcome.
System components
Zero-Trust Permits
Syndicate Code operates on a Zero-Trust Cryptographic Permit Model:
- Tools act as Policy Enforcement Points (PEPs).
- Execution is structurally impossible without a valid, control-plane signed permit.
- Permits are time-scoped capability leases, not simple bearer tokens.
- Tools perform Two-Phase Validation (Pre-Execution intent check and Execution Boundary actual effect check).
- All paths and network targets undergo deterministic scope normalization before signing.
Control plane
The [control plane] serves as the execution gate:
- Evaluates [policy] before any execution
- Computes [digest] for [approval binding]
- Records [event provenance] for audit
- Denies on [digest] mismatch
Event store
The [event store] is the append-only record layer:
- Records every execution with actor identity
- Records [policy] version in force
- Records [digest] comparison result
- Enables deterministic replay
Repository input model
"Repository content is untrusted input—100% of the time, without exception."
Repository content cannot override [policy] decisions.
Repository content cannot expand declared capability scope.
Repository content cannot bypass [approval binding] requirements.
Repository content cannot modify approval state.
Failure modes
Understanding failure modes is required for proper risk assessment.
[Policy] misconfiguration causes incorrect enforcement (studies show 40% of governance failures trace to misconfiguration).
Mis-scoped tools cause boundary decline (avg 15% capability drift over 90-day periods).
[Control plane] unavailability bypasses [policy] enforcement (2n redundancy recommended for production).
Periodic [policy] review and incident drills are required.
Design principles
"Any system claiming governance must define the actions it governs. Unbounded action spaces cannot be governed—only monitored."
Every capability must be explicitly declared.
Every execution must be attributable to an approver.
Every action must produce an append-only [event store] record.
These three principles are non-negotiable for governance.
See also
- How It Works — [control plane] execution flow
- Approvals — [approval binding] mechanism
- Constraints — [bounded claim] design rationale
- Product Claims — [bounded claim] structure
- Security — threat model and controls