Overview
Direct answer
Syndicate Code is a governed engineering execution environment for operators who need AI-assisted coding workflows to remain attributable, policy-constrained, interruptible, and evidentiary. The runtime proposes, the control plane decides, and the audit chain records the result.
This page is the authority hub for the public site. Use it to understand what is verified, what is qualified by scope, what is product intent, and what is intentionally unsupported.
Product statement
Syndicate Code is a governed engineering execution environment for operators who need AI-assisted coding workflows with strict control-plane enforcement. It is provider-agnostic, language-agnostic, and TUI-first, and it is not an unrestricted autonomy platform.
v1 deployment note This page describes the v1 local-embedded deployment. Team and enterprise deployments use
syndicate-serverand differ in control-plane topology, authentication, and remote endpoint operations.
Why governance matters
Most coding tools optimize for speed, but they do not expose a durable control-plane decision path for approvals, permits, checkpoints, and evidence. That gap makes incident response, audit review, and execution reconstruction difficult.
Syndicate Code closes that gap with governed execution: proposals are canonicalized, evaluated by policy, checkpointed when required, bound to permits, and recorded in an append-only audit chain. This framing comes from product_system_definition.md §6 and governed_execution_spec.md §4.
The TUI is an operator surface, not an enforcement layer. The control plane remains authoritative, and runtime behavior is non-authoritative (product_system_definition.md §5; operator_interface_spec.md authority model).
Public statement classes
| Class | Meaning | Example |
|---|---|---|
| Verified | Backed by current claim and proof records, with a current verification timestamp. | Policy evaluation occurs before execution in traced paths. |
| Qualified | True only within a named scope, usually with explicit exclusions or topology limits. | Approval binding is verified for the local embedded v1 path, not for every possible bypass path. |
| Product intent | Design direction, not a public guarantee. | Additional topology or surface area. |
| Unsupported | Intentionally not claimed because the evidence, scope, or maintenance cost does not support it. | Universal security, kernel-level isolation, perfect secret detection. |
The six-stage governed execution pipeline
- Proposal intake
- Canonicalization
- Policy evaluation
- Checkpoint (if required)
- Permit issuance
- Execution and evidence recording
Normative basis: governed_execution_spec.md §5 and syndicatecode-docs-site-spec.md §4.1.
Governance Guarantees
- G1 Governed execution: Side-effecting operations inside traced governed paths require control-plane authorization.
- G2 Binding: Approvals bind to canonicalized requests and cannot be reused outside scope.
- G3 Inspectability: Model context and prompts are reconstructable and inspectable.
- G4 Auditability: Decisions, authorizations, and executions are recorded as append-only events.
- G5 Provider abstraction: Provider selection is control-plane governed and not hardcoded in workflows.
- G6 Bounded autonomy with checkpoints: workflows remain bounded, attributable, interruptible, and checkpointed.
Normative basis: product_system_definition.md §6.
Non-Guarantees
Syndicate Code does not guarantee:
- correctness of model outputs
- absence of hallucinations
- prevention of all data exfiltration risks
- equivalence of audit fidelity across providers
Non-guarantee callout Governance controls authorization and evidence. They do not make model outputs inherently correct.
Normative basis: product_system_definition.md §7.
Competitive reference
| Axis | Cursor | Claude Code | Aider | Syndicate Code |
|---|---|---|---|---|
| Multi-file editing | Yes | Yes | Yes | Yes + governed execution |
| Any language | Yes | Yes | Yes | Yes + registry-driven |
| Any provider | No | No | Yes | Yes + models catalog |
| Streaming output | Yes | Yes | Yes | Yes + evidence stream |
| LSP integration | Yes | No | No | Yes |
| Audit trail | No | No | No | Yes (hash-chained HMAC evidence) |
| Checkpoint governance | No | No | No | Yes |
| Local inference | No | No | Yes | Yes |
| TUI-first | No | Yes | Yes | Yes (five-pane governed surface) |
| CI/headless mode | No | Yes | Yes | Yes |
| Team/enterprise deployment | No | No | No | Yes (syndicate-server) |
Source: syndicate_master_spec_and_plan.md Part I, Competitive Bar.
Quick navigation
| Section | Use this when |
|---|---|
| Getting Started | You want installation and first governed run guidance. |
| Using Syndicate Code | You need day-to-day workflow operation references. |
| Policy | You define trust tiers, capability rules, and checkpoint policy. |
| Audit | You verify chain integrity and evidence completeness. |