Skip to content
CONSTABLE
ProblemDefinitionsMechanismFor teamsScopeLexiconImplementation
SDSResearch, diagnosis, and architectural work.ZTGThe open specification defining structural governance requirements.ConstableThe commercial reference implementation and control kernel.

SDS maintains the open ZTG specification and builds Constable as a reference implementation. ZTG can be implemented without Constable.

SHADOW DYNAMIC SYSTEMS

Constable is a product of Shadow Dynamic Systems LLC. Built for institutions that treat authority as infrastructure.

Contact

Jason Crittenden
Founder & Research Lead

jason@shadowdynamicsystems.com

Start here

Related

Zero Trust GovernanceZTG source on GitHubShadow Dynamic Systems
General Constable marketing material. No third-party certification, endorsement, regulatory approval, customer result, or insurance validation is claimed. Constable is a control kernel; it does not by itself make AI risk-free, guarantee compliance, or govern surfaces where it is not integrated.
© 2026 Shadow Dynamic Systems LLCAuthority defines admission.
← Implementation

The Authorization Model

Implementation commentary for §3 — The Authorization Model ↗ on Zero Trust Governance (v0.7). Constable implements concepts derived from ZTG; this page is commentary, not a conformance claim. Written against snapshot 0.8-draft-2026-09-21 · spec/3-authorization-model.md ↗.

Implementation commentary · seed

Constable implements the authorization model as the decision function of its execution gate: a reference monitor between the agent runtime and the effect surface that every proposed action must traverse and that emits exactly one verdict per request.

The request and the gate. Constable assembles each authorization request from the agent's proposed action and validated parameters (post-Airlock), the asserted authorizing identity, the candidate surface route, and the pinned decision-time snapshot. The gate evaluates the request as a whole with OPA/Rego and returns one of authorize, refuse, or escalate, bound to the action, policy version, identity, and decision-time, and recorded under ZTG-0a ↗ on Zero Trust Governance (AUTHORIZATION_REQUESTED, BOUNDARY_EVALUATED, and the matching verdict event).

Admissibility as policy. The seven admissibility conditions are evaluated against the pinned governance bundle: identity validity (ZTG-0d ↗ on Zero Trust Governance), temporal coherence (ZTG-0c ↗ on Zero Trust Governance), bundle consistency (ZTG-0e ↗ on Zero Trust Governance), policy permission, surface routing (ZTG-3 ↗ on Zero Trust Governance), ceiling and gate (ZTG-5 ↗ on Zero Trust Governance), and recordability. A request that fails any condition refuses; a request whose determination is indeterminate, or which policy reserves, escalates through HumanSeal.

Provenance retention. Each grant records the authority it was made under — the attesting principal, or the ratified policy and the principal who ratified it — so the authority of any authorized effect traces to a human author. Constable holds no path by which a grant can be issued under authority that does not resolve to attested human responsibility.

Escalation through HumanSeal. Escalated requests are surfaced to the authority policy designates, with the consequence context (harm class, ceiling, composite assessment) presented, and the human's engagement recorded as the act that resolves the escalation.

Convergence and conformance. Constable's replay harness (ZTG-0b ↗ on Zero Trust Governance) regenerates a recorded determination from its substrate; the convergence test builds on this to check that independent assessment converges. The full conformance protocol is documented in the conformance verification specification referenced in §22.

PreviousTemporal Integrity