About
Governance for AI code execution.
Constrained execution model
Syndicate Code operates under a deliberately constrained delivery model. This is not a resource limitation—it is a design decision.
Work is accepted based on governance fit, not capacity availability. Every deployment involves documented policy boundaries and evidence requirements. The system enforces what can and cannot be executed, independent of operator intent. Decisions are recorded as structured events, not chat logs.
The operating model ensures every deployment can answer: which policy version authorized this action? Who approved the exact execution context? What evidence chain confirms execution?
What the product guarantees
Syndicate Code is a control plane that sits between AI coding tools and code execution. It requires human approval for actions and maintains an attributable event record.
The system makes explicit claims with defined boundaries. Each claim has:
- What it guarantees
- What it applies to (scope)
- What it does not cover (exclusions)
- How it can fail (failure mode)
- Where to find the proof
Where this model fits
Strong fit
- High-risk, high-accountability environments requiring audit trails
- Regulated industries where evidence must survive procurement review
- Systems requiring explicit approval boundaries and attributable execution
- Incident response scenarios where reconstruction from logs is mandatory
NOT a fit
- Large-scale parallelized delivery requiring multiple simultaneous execution paths
- Commodity implementation work without governance requirements
- 24/7 unmanaged support expectations
- Environments that prioritize velocity over attribution
Capacity and scaling policy
Capacity is intentionally constrained to maintain execution quality and evidence integrity. This is risk control, not resource constraint.
Acceptance criteria
- New engagements require governance architecture alignment
- Work that cannot be bound to policy and evidence is declined
- Expansion beyond current capacity triggers formal review, not default acceptance
The constraint ensures every deployment can be supported with appropriate evidence and audit capability.
Continuity and risk management
Documentation standards
All operational procedures are documented with explicit failure modes, known limitations, and recovery procedures. The product repository contains runbooks, deployment procedures, and rollback protocols.
Reproducibility guarantees
Every release is built from tagged commits with reproducible build commands, signed with GPG, and accompanied by SBOM (CycloneDX). Customers can verify builds independently. No reliance on proprietary build infrastructure.
Client access to systems and artifacts
Clients deploying Syndicate Code receive full access to source code and build artifacts, local control of audit data (not stored in vendor systems), and ability to export evidence in standard formats. No dependency on vendor-operated SaaS for core functionality.
Handover conditions
In the event of service termination: source code is available under defined licensing, database schemas and migration paths are documented, export procedures allow complete data extraction, and operational runbooks transfer to client control. The product runs locally, under client control.
Accountability model
The operating model has no delegation ambiguity. All architectural decisions are documented in ADRs (Architecture Decision Records). All product claims are registry-tracked with source references. All evidence is verifiable against the implementation.
The absence of multiple decision layers means: no "the team decided" deflection, no unclear ownership of policy exceptions, no ambiguous authorization chains. Every approval event in the audit chain is attributable to a specific identity, policy version, and execution context.
Security and data handling
What data is used
Execution context, policy rules, approval records, evidence chain
What data is NOT used
Model inputs/outputs beyond execution context required for attribution
Retention
Client controls retention; vendor has no data ownership claims
Training reuse
No model training on client execution data
Enforcement mechanisms
- Evidence chain is append-only; no post-hoc modification possible
- Audit verification can prove chain integrity
- Customer controls encryption keys (enterprise tier)