PRAXIS · rincol-praxis, read 2026-08-18

How PRAXIS catches its own mistakes, and where that might not hold.

PRAXIS is a platform for AI assisted professional work: a request comes in, a pipeline drafts a document, and every draft is checked before it goes out. The whole design bets on one mechanism working. These three diagrams show what that mechanism actually is, not just what it's called.

01 · SHAPE

A thin core, a pack that can't touch storage.

The platform is one core plus a “pack” per profession. The rule that makes this real, not just a folder convention, is what a pack is structurally prevented from reaching.

Channel adapter Routing Tenant resolution Orchestrator Memory & retrieval services Storage Vertical pack (legal, today) registry not permitted not permitted
allowed path
structurally blocked, enforced by CI import check
What this shows: the pack talks to the orchestrator through one registry and nothing else. It cannot open a store, and a channel adapter cannot reach retrieval directly. These two cuts are checked in CI, not just in review, because a plausible-looking import is exactly what passes a human read of generated code.
02 · PIPELINE

The reviewer never sees why the draft was written.

This is the load bearing mechanism. Production hands the review stage the finished artefact and nothing else, and review runs its own, separate search for prior work rather than reusing production's.

request Analysis strategy + retrieval plan Production writes the candidate artefact Review judges the artefact against criteria strategy + docs artefact retrieved docs, strategy, reasoning denied Memory & retrieval analysis's query review's own query reject, objections capped at 3 passes approved unresolved after 3rd reject write back, approved only
passed forward
explicitly denied to review
rejection path
approved path
What this shows: review gets the artefact and nothing about how it was made. Its search for prior work is a separate round trip to the same memory store, under a query it builds itself. The design test they apply to any change here: name one cause that would make both stages wrong. If the answer is the same retrieved document, the change is rejected.

Where this can still fail: the test as written catches the same document reaching both stages. It does not obviously catch the same pattern reaching both stages through two different documents, if the firm's own approved history has the same mistake sitting in many records rather than one. Independent queries into a corpus that is itself biased will independently agree.
03 · TENANCY

No shared table for a forgotten filter to leak from.

A cross tenant disclosure here is a business ending event, so the chosen isolation removes the failure mode by construction rather than by review discipline.

REJECTED · shared store, filter by tenant_id Tenant A Tenant B Tenant C one store all tenants' rows WHERE tenant=A WHERE tenant=B query, filter omitted returns tenant B's data CHOSEN · per tenant store resolution Tenant A Tenant B Tenant C resolve(id) the only path in A's store file B's store file C's store file no shared object exists for a missing filter to leak from
the failure mode being removed
the property that removes it
What this shows: on the left, isolation depends on every query remembering a predicate, forever. On the right, isolation is a property of which file handle is open, so a query that forgets to filter still cannot reach another tenant's file.

What isn't shown here, and isn't in the record either: what stops two concurrent requests for the same tenant from opening two writer handles to that tenant's own file at once. The diagram is honest about removing cross tenant risk; within tenant write safety is asserted, not drawn.
04 · OPEN

What doesn't add up yet.

Four things worth sending back before agreeing the record is settled.

!

Two accepted ADRs cite a document that doesn't exist

ADR-004 and ADR-005 both treat ADR-007 as settled, memory write back provenance, corpus corruption. It isn't written. SDD chapter 07 calls it “pending” twice. The exact risk it's meant to cover, approval rate rising while quality drifts, is the same mechanism that could break the reviewer decorrelation argument.

!

Review builds its own query from a possibly contaminated artefact

Review is denied production's reasoning, but it reads the candidate artefact to build its own retrieval query. If production framed the request wrong, that framing is already baked into the artefact's wording, and review's “independent” query can inherit it without ever touching production's context directly.

!

Nothing decorrelates the model itself

The denial list covers context. If production and review run the same model or model family, a shared capability blind spot survives completely independent context. It isn't in the frozen spot or hotspot register either.

!

Row level security was argued against thinly

ADR-003 argues hard against filtering alone, then treats full physical separation as the only fix. A database enforced policy would remove the same “forgot to filter” failure without the per tenant file overhead. The stronger case for physical separation, zero shared attack surface for a regulated practice, is implied but never stated.

Bottom line: the architecture is more disciplined than most first drafts get, the frozen spot register and the CI enforced import checks are real guardrails, not aspirations. The one thing I would not let slide before the first vertical touches real client work is the ADR-007 gap, because it sits directly under the claim the whole review stage is supposed to make good on.