The questions a skeptical reviewer, engineer, or auditor would actually ask — answered directly, with links to artifacts they can verify themselves.
What this site actually is, and what it deliberately is not.
No. This site is the public interface, documentation hub, and artifact surface for Project-AI. Live enforcement runs against a separate, signed kernel. Anything rendered here is labeled as documented claim, generated artifact, simulation, or demo.
Every governance output carries a provenance badge: SIMULATION, DEMO, DOCUMENTED, or VERIFIED. Live decisions also carry a signed envelope verifiable at /verify against the keys published at /keys.
No. Project-AI is an execution-governance architecture. A chat surface may exist as one client of the governance layer, but the project itself is the deny-by-default control plane that adjudicates capability requests before any model action runs.
Pre-execution control, not post-hoc dashboards.
Every capability request is adjudicated by the Triumvirate (Galahad, Cerberus, Codex Deus Maximus) and the STATE_REGISTER continuity gate before the runtime is permitted to act. The verdict is ALLOW, DENY, or SAFE_HALT, and is signed before execution can proceed.
Absence of an explicit ALLOW with a valid capability token is treated as DENY. There are no implicit fallbacks, no side paths, and no trusted shortcuts. See the Glossary entry for AC0–AC5 authority classes.
SAFE_HALT is a first-class outcome alongside ALLOW and DENY. It is emitted when the governance layer cannot adjudicate safely or when continuity invariants are violated. SAFE_HALT produces a signed audit receipt — it is never silent.
Those techniques shape model behavior. They do not gate execution. Project-AI treats the model as untrusted and adjudicates each action against a separate, signed governance kernel. A model that produces an unsafe action still cannot execute it without a capability token.
How an external reviewer can check our claims without trusting us.
Paste the decision hash or signed envelope at /verify. The page resolves signer fingerprint, TSA timestamp, and verdict, and links to the reproduction pack at /reproduce.
Public audit keys and TSA roots are at /keys, including the rotation log and openssl snippets for offline verification.
The Claims Registry at /claims is the canonical list of public claims, each labeled VERIFIED, DOCUMENTED, or PLANNED, with links to the paper, evidence, and reproduction pack.
Use /disclosure for the coordinated vulnerability policy (scope, SLA, safe-harbor). Machine-readable contact metadata is published at /.well-known/security.txt per RFC 9116.
Live system posture and what is currently shipped vs planned.
Subsystem posture is published at /status. The portal heartbeat is real; Triumvirate, Redis, NIRL, and kernel signals are marked as live, simulated, or planned per subsystem.
The Legion Interface is sign-in required. Access is capability-scoped, audited, and requested through /contact while the public capability intake surface remains locked.
A measure of unresolved evidence required to keep an action admissible under the governance frame. The /admissibility-debt page is live as a planned calculator surface and currently documents the metric before public runtime execution is exposed.