The architecture: what runs today, and what does not yet

The enforcement model

The kernel treats the model as an untrusted client. It holds SELECT and nothing else. Nothing an agent believes changes what the database accepts. For a mortgage operation, this is AI governance expressed as schema rather than policy — the safeguard is a property of the system of record, not a paragraph in a binder.

Identity

Every mutation goes through a SECURITY DEFINER function — a function that runs with its owner's authority rather than the caller's — which decides what the caller may do by reading session_user, the login identity the connection actually authenticated with. It never trusts an identity supplied in the payload. The kernel derives the tenant from the login itself: a connection cannot assert its way across a boundary it cannot authenticate for. Four login roles exist with no membership between them — owner, maker, checker, and a second tenant's maker kept solely for isolation proofs.

The mutation path

There is exactly one write path: definer functions the kernel owns. The database refuses a direct insert to the event chain with permission denied — proven, not asserted. Row-level security scopes every tenant-owned table (13 of them, per the repository's gap register) to the tenant the login resolves to.

maker/checker— the separation between the actor who performs work and the distinct actor who approves it; reperformance— independently redoing work to verify it, the strongest class of audit evidence;tamper-evident— the chain makes alterations to history detectable at the exact position they occurred (the honest term; this is not "tamper-proof").

The chain

Every governed event appends to a hash chain: each entry carries its content hash and the prior entry's hash forward. verify_chain recomputes the chain and catches an edited row at its exact position. A trigger keeps the chain append-only — it refusesUPDATE and DELETE even from the owner, because the owner is exactly the person an auditor distrusts. This is a per-tenant hash chain in Postgres — nothing more exotic, and we say so.

finding recorded      reviewer A    insufficient evidence
superseding pass      reviewer A    not accepted — same actor as the original finding
superseding pass      reviewer A    not accepted — same actor as the original finding
seal                                blocked until a distinct reviewer resolves the finding

The readout shows anti-self-reversal: the actor who recorded a finding cannot also clear it. In the incident above, an AI reviewer attempted to record superseding passes over its own finding; the gate's same-actor exclusion kept the finding unresolved each time. The readout shows the system refusing — that is the point.

The lifecycle, with what the schema refuses at each step

Exact numbers

The proof suites

The counts above come from the suites' own stated counts in the Wet Ink repository, quoted as stated. The suites re-run against the same database — a proof that only passes against a freshly seeded database checks a coincidence, not an invariant, and construction found and strengthened two such assertions. The repository's gap register documents that standard.

The trust ladder — what is built, what is not

The legal frame is the business-records reliability standard — a reliable, checkable process. We designed the record to exceed the bar lenders already clear with mutable logs: it makes reliability checkable by machine instead of by testimony. Cryptography does not replace that legal standard, and this site will never claim it does.

What comes next, stated as a roadmap

In order of intent, not a dated promise: the provider adapter (a real model call inside the enforcement boundary); the document lifecycle (cited bytes behind every anchor); the evaluation engine (predicates actually evaluated — the judgment layer itself); trust rungs 2 through 4. Roadmap items are build items. No page on this site claims any of them as running today, and this page is the reference for that boundary.