Policy

Policy governs every execution decision in Syndicate Code. It is the authoritative source for what actions are permitted, under what conditions, and with what approval requirements.

Five principles

• PC-001 — Policy is authoritative. Policy evaluation results are not hints. Permit issuance is blocked until policy is satisfied.
• PC-002 — Capabilities are explicit. No capability is available unless declared and evaluated. There is no implicit permission.
• PC-003 — Least privilege by default. The default execution envelope is the most restrictive viable envelope.
• PC-004 — Separation of concerns. Policy and operator config are separate namespaces. Config cannot act as a policy authority surface.
• PC-005 — Policy must be explainable. Every permit and denial must be traceable to a specific policy rule and version.

Policy vs. config

Policy is control-plane-governed, versioned, and audited. Changes to policy affect permit issuance, approval behavior, checkpoint behavior, and trust-tier mapping.

Config is local operator preference — output formatting, TUI preferences, and other local defaults. Config changes do not affect governance behavior.

Policy lifecycle

Policy is deployed as a bundle — a unit containing all governed rules for a version. Bundles must be validated before activation. Activation is atomic; no partial policy state is observable.

syndicate policy validate ./policy-bundle.toml
syndicate policy apply ./policy-bundle.toml
syndicate policy rollback <version>

In this section

• Authoring — bundle format, apply, rollback, version identity
• Trust Tiers — tier definitions, tier assignment, accumulation
• Capability Model — capability classes, declaration, evaluation
• Versioning — version format, upgrade rules, policy invariants