Technical review

The document a security reviewer actually asks for.

Not a deck. A written review of how the kernel is built, what it cannot do by construction, where each guard lives in the code, what we attacked and what broke, and where the design stops scaling. Shared under NDA with design partners.

Request the review Read the public security page

What it contains

Six sections, each with pointers into the tree.

Every claim in the review names the file and the test that pins it. If you have the repository, you can check each one in a few minutes.

Architecture

The package map and one data-flow walk from ingest to a learned fire: the resolution ladder, the transactional outbox, staged actions, and the single SQLite file per tenant.

Invariants and the tests that pin them

Confirm is execution. Money and legal fields need a person. One promotion path. Stale authority cannot fire. Each one with the predicate that enforces it and the test that fails if it is removed.

Threat model

Assets, trust boundaries, the controls that exist today with pointers, and the residual risks written as residual risks rather than omitted.

Red-team history

Every adversarial class tried, whether it held or broke, its severity, and the fixing commit, kept as a failing-then-fixed test. The independent, third-party audit that follows it has not yet been done.

Performance wall

What a single-tenant SQLite deployment is built to handle, the caches that keep authority checks honest under load, the measured indexes, and where this design stops and a different one begins.

Benchmark methodology

How GovBench generates, drifts, and scores; why the latent policy is oracle-only; and the assertions a result must pass before it is published with a commit hash.

Reading it

Written to be read in an afternoon, with the tree open beside it.

The review is a document. It is pinned to a commit hash so the pointers stay true, and it is reissued when the hash moves. Questions are answered by the person who wrote the code.

Pinned to a commit

The version you receive names the commit it describes. File and line references resolve against that tree even after later commits ship.

Red-team findings are not summarised away

Where an attack succeeded before the fix, the review says so, with the severity we assigned and the commit that closed it.

Roadmap is labelled roadmap

Hosted sign-up, hosted Observe, and hosted instances for Solo and Starter are in the launch plan. The review keeps them in a separate section from what is enforced today.

razoo · technical review · contentspinned to a commit

0
Scope and commit hash
what this version describes
1
Architecture
package map · ingest to learned fire · outbox · SQLite per tenant
2
Invariants
predicate · file · pinning test, one row each
Pinned
3
Threat model
assets · boundaries · controls · residual risk
4
Red-team history
class · verdict · severity · fixing commit
Pinned
5
Performance wall
measured limits · authority caches · where it stops
6
Benchmark methodology
GovBench generation, drift, scoring, publication gate
Seeded
A
Launch plan
hosted sign-up · hosted Observe · hosted instances · independent audit
Roadmap

Every section names its files and tests.illustrative contents

Who it is for

Two readers, two different questions.

Security reviewers

You need to know what cannot happen, where that is enforced, how it was attacked, and what is left. The invariants, threat model, and red-team sections are written for you, in the order a questionnaire asks.

Platform leads

You need to know whether this sits under your frameworks without taking over your stack, what it costs to run, and where it stops scaling. The architecture, performance wall, and benchmark sections are for you.

If you are filling in a procurement checklist rather than reviewing the design, start with the security page. It answers the standard questions without an NDA.

How it is shared

Under NDA, to design partners.

The repository is private. The review is how a team reads the design before it commits an engineer and real traffic.

A mutual NDA

Yours or ours. What the NDA protects is the pointers into a private tree.

Before you install anything

Design partners receive the review at the start of the program, ahead of the kernel, so the security conversation happens before the integration work.

With the engineering team on the call

One session to walk the document, then written answers to whatever the walk raised. Nothing is delegated to a sales engineer, because there is not one.

What it is not

It is not a certification, an audit opinion, or a penetration-test report. None of those exist yet. The plan for them is on the security page, stated plainly.

Without an NDA

Most of the mechanism is already public.

Security

The invariants and the tests that pin them, data handling, transport guards, and what is on the launch plan.

Security →

GovBench

The harness, the adapter interface, the five scores, and the publication policy.

GovBench →

Glossary

Rung, envelope, proof state, VAA, and the rest of the vocabulary the review uses.

Glossary →

Documentation

Install, quickstart, the SDK and CLI references, and appliance deployment.

Overview →

Request the technical review.

One email with your name, your organisation, and what you are evaluating it for. We reply within two business days with the NDA and a time.

Request by email The design partner program