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

Product status

What runs today

The sealing architecture — an append-only sealed record with schema-enforced maker/checker separation — runs today with 123 passing proofs behind it; the AI judgment layer that will run inside it does not yet exist: no loan file is under review, and there are no customer deployments.

Running

Not running

123 passing proofs hold everything above, across four suites: 47 seam proofs, 24 reviewer witness/manifest proofs, 40 headless-loop proofs, 12 migration-runner proofs — restated in full in the proof suites. This section restates the wetink repository's own operating contract and gap register, without softening. When this section and any other page disagree, this section wins.

Architectural doctrine 01

The kernel treats the model as an untrusted client.

The model may propose work. It cannot grant authority to its own work.

The enforcement model

The model 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.

In practice: the same person — or agent — cannot both make and approve a decision, and that is a property of the database, not a policy anyone has to remember to follow.

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 refuses UPDATE 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.

In practice: you can reconstruct what happened after the file closes, and when policy changes, a historical decision is still explainable under the rule that existed when it was made.

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.

Enforcement properties

1. 2.1 — Actor identity

   Invariant
   An identity asserted in a request payload is never trusted.
   Enforcement
   Every mutation runs through a SECURITY DEFINER function that reads session_user — the login identity the connection actually authenticated with — never a payload field.
   Refusal
   ACTOR_IDENTITY_MISMATCH — a connection asserting an identity it does not hold.

2. 2.2 — Separation of duties

   Invariant
   The actor who does the work and the actor who approves it are never the same actor.
   Enforcement
   Four login roles exist with no membership between them — owner, maker, checker, and a second tenant's maker kept solely for isolation proofs.
   Refusal
   RESOLVER_NOT_DISTINCT — the maker's own seal attempt is refused; the maker's own check does not count toward the gate.

3. 2.3 — Evidence anchoring

   Invariant
   An extraction cannot claim authority it cannot source.
   Enforcement
   record_evidence requires a document-and-page anchor and a model inference behind every claim.
   Refusal
   EXTRACTION_UNANCHORED — no document/page anchor; EXTRACTION_UNATTRIBUTED — no inference behind the evidence.

4. 2.4 — Rule versioning

   Invariant
   A judgment stays explainable under the rule that existed when it was made, even after the rule changes.
   Enforcement
   A rule can retire but never change; every seal captures exactly which rule versions were live at seal time.
   Refusal
   record_check_result refuses a verdict citing a rule version that does not exist.

5. 2.5 — Chain integrity

   Invariant
   History cannot be silently altered, including by the database owner.
   Enforcement
   Every governed event appends to a per-tenant hash chain carrying its content hash and the prior entry's hash forward; verify_chain recomputes the chain and catches an edited row at its exact position.
   Refusal
   A trigger refuses UPDATE and DELETE on the chain, even from the owner.

6. 2.6 — Seal authority

   Invariant
   Authority to write the accepted record belongs only to a distinct, eligible checker — never the maker alone.
   Enforcement
   seal_action requires a distinct resolver and all seal conditions satisfied before the record is written.
   Refusal
   The database refuses seal_action from the maker (RESOLVER_NOT_DISTINCT); a subject with zero required checks does not pass either.

The lifecycle, with what the schema refuses at each step

1. 01 — Claim

   Purpose
   The conclusion being asserted about a subject bound under a lease.
   Requires
   A resolvable actor identity and structured claim context. claim_action binds a subject to a named actor. The subject is polymorphic from the first migration: a loan file today — first-mortgage purchase, refinance, HELOC, or home equity loan alike — a title commitment or settlement package the same way, and any attested judgment tomorrow.
   Persists
   Claim identity, actor, time, declared conclusion.
   Refuses
   An actor identity the connection cannot authenticate for — a connection cannot assert its way across a boundary it cannot authenticate for.

2. 02 — Evidence

   Purpose
   Anchor the claim to inspectable source material. An action cannot borrow provenance from another action.
   Requires
   A document identity and source/page anchor, and a model inference behind the extraction.
   Persists
   Document, page, extraction/source reference.
   Refuses
   EXTRACTION_UNANCHORED — no document-and-page anchor; EXTRACTION_UNATTRIBUTED — no inference behind the evidence.

3. 03 — Checks

   Purpose
   Test the claim against a defined, versioned rule.
   Requires
   An applicable versioned rule and its inputs. The maker may record its own check.
   Persists
   Rule version, predicate result, supporting context.
   Refuses
   record_check_result refuses a verdict citing a nonexistent rule version, and refuses a connection asserting an identity it does not hold (ACTOR_IDENTITY_MISMATCH). The maker's own check does not count toward the gate.

4. 04 — Gate

   Purpose
   Determine whether authority may be granted to seal.
   Requires
   The required checks, satisfied by a distinct eligible checker.
   Persists
   Resolver identity and gate outcome.
   Refuses
   The maker's own pass does not satisfy unambiguous_pass, and a subject with zero required checks does not pass either: absence of a blocker is not evidence of a pass.

5. 05 — Seal

   Purpose
   Write the authoritative, accepted record.
   Requires
   All seal conditions satisfied, including a distinct resolver.
   Persists
   The final record plus chain/provenance state — exactly which rule versions were live.
   Refuses
   The database refuses seal_action from the maker (RESOLVER_NOT_DISTINCT). The chain then holds a valid seal, append-only.

Exact numbers

The proof suites

123 / 123 PASS

The counts above come from the suites' own stated counts in the wetink 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

Currently proven to here

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.

Category boundary

Boundaries and non-goals

A new category gets misread through the nearest familiar one, and every misreading costs a conversation. Stated plainly, wetink is not:

The commercial boundary — what a founding-partner engagement is, and is not — is stated on the founding partner page.

What comes next, stated as a roadmap

In order of intent, not a dated promise. 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.