Skip to main content
SCSyndicate Code
Get Started

Core Concepts

Actors

Syndicate Code operation spans these actors:

  1. Operator — the human working through TUI or CLI.
  2. Control plane — authoritative enforcement for policy, approvals, permits, context manifest generation, provider routing, and audit emission.
  3. Runtime/orchestrator — executes model interaction and specialist orchestration; non-authoritative.
  4. Specialist — bounded work unit with declared capability scope.
  5. Tool executor — performs side effects (filesystem, shell, network, secret access, delegation).
  6. Provider — inference endpoint selected through policy-governed routing.

Normative basis: product_system_definition.md §5 and governed_execution_spec.md §3.

v1 deployment note This page describes the v1 local-embedded deployment. Team and enterprise deployments use syndicate-server; authority boundaries remain the same while topology and remote endpoint operations differ.

Authoritative vs non-authoritative

Authoritative state includes control-plane policy decisions, approval records, permits, and audit chain state. Non-authoritative state includes runtime behavior, model output text, UI view state, and caches.

No non-authoritative component may grant execution permission.

Normative basis: product_system_definition.md §5.

Governed execution lifecycle

  1. Proposal intake
  2. Canonicalization
  3. Policy evaluation
  4. Checkpoint (if required)
  5. Permit issuance
  6. Execution and evidence recording

Normative basis: syndicatecode-docs-site-spec.md §4.1 and governed_execution_spec.md §5.

Sessions, turns, and steps

  • A session is a bounded interaction context for one operator and one workspace.
  • A turn is one complete loop from intent through terminal response or checkpoint.
  • A step is one tool invocation and is the smallest auditable execution unit.

Normative basis: session_and_turn_model.md ST-001, ST-002, ST-002a.

Trust model

Trust is tracked per boundary (tool × path scope × specialist × provider × workflow class). Trust increases only through policy-defined evidence. The first violation resets the affected boundary to untrusted immediately.

There is no concept of globally trusted execution.

Normative basis: governed_execution_spec.md GP-005 and §7.2.

Permit model

Syndicate Code uses a Zero-Trust Cryptographic Permit Model. A permit is not a simple token; it is a cryptographically bound, time-scoped capability lease issued by the control plane. It is bound to an approved canonical form or execution envelope.

Tools act as Policy Enforcement Points (PEPs). Approval alone is insufficient. Execution involves a Two-Phase Validation at the tool layer (pre-execution check of intent, and an execution boundary check of actual side effects) to ensure deterministic scope normalization.

If required audit evidence cannot be durably written, execution hard-blocks; there is no degraded mode.

Normative basis: governed_execution_spec.md GP-002, GP-004, §8, and §9.

Design doctrine

  1. Fast by default, inspectable on demand
  2. Bounded autonomy is attributable
  3. Control plane is authoritative
  4. Provider choice is abstracted and policy-driven
  5. Evidence supports post-hoc reconstruction

Normative basis: product_system_definition.md §10.

Non-guarantee callout These concepts define governance and evidence guarantees, not model-output correctness guarantees.