Docs

ZAK is a constitutional execution environment: executors stay unpredictable (models, workflows, services, humans) while governance becomes mechanical—enforced as law and emitted as proof.

What ZAK does at runtime

Every governed interaction is wrapped in a GovernanceEnvelope (invariants cannot be disabled), evaluated against a ConstitutionalLaw, then routed through an enforcement gate.

Probe → Execute → EnforcementGate → (Deny | Silence | Transform | Emit) → Receipt

The three enforcement modes

• DENY_AT_ADMISSION: request never runs; a denial + receipt are returned.
• ALLOW_BUT_SILENCE: request may run; output is replaced with a canonical response + receipt.
• ALLOW_BUT_TRANSFORM: request runs; output is forced into a safe schema + receipt.

Receipts (proof, not logs)

ZAK produces a receipt for every outcome—including denials. For the public demo, you can verify the receipt locally (hash match). For production, receipts can be chained, enriched with metadata, and signed.

See: /proof

Key specs

• Receipt schema (v1) — the fields you can validate and archive.
• PanelSpec schema (v1) — strict UI contract so worlds don’t become “brittle UI soup”.
• Verification guide — how to verify a receipt offline.

Deep dives

• OnePager — fast architecture + category framing.
• Worlds — product surfaces (“apps”) built on the same engine.
• Security — threat model summary and failure modes.