Security
Design principles
Product invariants.
Product invariants. A change that threatens one is escalated rather than worked around.
| Principle | In practice |
|---|---|
| Transport, not judgment | The engine automates routing and mechanics, never a gate decision. No feature may auto-accept, auto-merge, or skip a gate. |
| Capture, not invent | The engine proposes rules for your standards; a human approves every promotion, and provenance is preserved on each rule. |
| Secrets never propagate | No subsystem stores or transmits a secret value. Names, paths and references only — enforced in the type system where ordinary logging could otherwise leak it. |
| Git is the system of record for code | The engine observes commits, branches and pull requests. It never pushes, merges, or mutates remote git state; the internal git interface is a read-only allowlist enforced identically in production and under test. |
| Advisor advises, human decides, record shows both | Suggestion and decision are distinct recorded events, and an override is itself recorded. |
| Sanction binds change classes, never time | Delegated acceptance runs only under a named, pinned, human-owned policy scoped to explicit change classes. No timeout anywhere grants an approval: silence is never consent. |
| Deterministic first | No model call where ordinary code suffices — a cost principle and a security one, since code that never calls a model cannot be talked into anything. |
What the risk actually is
If you have run continuous integration, you know most of the shape: a control plane sends work to machines, and those machines run code.
Identity and PKI
The accepted algorithm set is closed, and the algorithm name is part of the signed material — so a signature produced under one algorithm cannot be reinterpreted under another.