A security review gates on proof. Caisson already ships every artifact it asks for — OSCAL conformance, a license and provenance gate, tested controls, real WORM verification, and adversarial threat registers — the failure was surfacing them. Here they are. Hand this page to your security reviewer.
Every card is a control that runs in CI or a record that ships with the source — described from the workflow or package that produces it. Nothing here is a promise; it is the pipeline.
The evidence-pack generator exports assessment results, plans of action & milestones, and per-framework assessment plans (SOC 2, HIPAA, EU AI Act) as OSCAL v1.2.2. A CI job installs the NIST oscal-cli and runs a JSON → XML → schema-validate round-trip against the models on every push and pull request — real schema validation, not a self-asserted badge.
oscal-cli 3.2.0 · OSCAL 1.2.2 · JSON → XML → validateOne gate is the sole registry ingress and license authority. It enforces that every code-shipping module declares Apache-2.0 in its SPDX license field and carries a manifest, and that the catalog the CLI reads matches the workspace's package.json versions exactly. A finding exits non-zero.
SPDX license present · catalog == workspace versionsThe module catalog the generator validates against is never hand-edited. Every CLI build derives it from the packages in the repository: each published package at its package.json version, with its manifest's description and dependencies. A test fails the build if the catalog misses a package or carries a version its package.json doesn't.
catalog == workspace package.json versionsEvery package ships its own suite — unit tests, Postgres integration tests on an in-process PGlite database, and golden-file regression compared with drift failing the build. The whole workspace runs green on every push; a single failing test reddens the run. Cross-tenant isolation is one of those tests, not a convention.
unit · PGlite integration · golden-file — green on every pushA live-verification harness runs against a real S3 Object-Lock bucket and asserts the guarantee end to end: a write succeeds and reads back a real retention date, a duplicate write is refused with a real HTTP 412 (write-once), a retention extension lands a later date, and an attempt to shorten it is refused while the lock still holds. It runs against real cloud storage — not a mock.
S3 Object-Lock · write-once 412 · extend · never-shortenEach workstream ships a SECURITY.md threat register produced by an adversarial review lane: every threat is enumerated and marked held or refuted, with the resolution. The shared-substrate register alone covers per-tenant key derivation, nonce reuse, the KMS envelope, and the RLS boundary. These are the working security records behind the code, in the public repository.
per-workstream SECURITY.md · each threat held or refutedThis is the shipped ChainViewer over a genuine kernel-built hash chain — each append links to the last by SHA-256, and verifyChain stamps the verdict. Scroll it into existence; the hashes are real either way.
verifyChain(entries) → { valid: true, brokenAt: null }
These artifacts aren't a hosted dashboard you rent access to. They live in the codebase you can read and run — the generator that writes the OSCAL pack, the gate that enforces the license floor, the suites that prove the controls. Read them, run them, and put your own reviewer's name on the result.
The shipped controls, this site's own posture, and the CSP — stated precisely, residuals included.
The evidence-pack generator, the OSCAL v1.2.2 export, and the technical-versus-administrative boundary.
How every package works and the contract it upholds — the manual your engineers read before they wire it in.