Praxis doesn't stop at a spec. It ships the whole thing: the reasoning, the
design, the plan, and dozens of diagrams that make it legible, in one dense document you can put on the table and
defend.
A dossier. One dense document holding the specification, the technical
design, the infrastructure, the low-level design, the delivery plan and dozens of diagrams. Every claim ties
back to a requirement. Every requirement ties back to a sentence in the ask. It is built to be handed to a
client and defended in the room, not skimmed.
Every page of it can be questioned.
dense on purpose
A thin answer doesn't survive scrutiny.
A one-page summary reads well and falls apart the moment someone technical asks
why. The dossier is built the other way around: every decision written down, every requirement accounted for,
every claim drawn out where a reviewer can follow it. Dense, because that's what holds up in the room.
narrative
tables
diagrams
what's inside
Eight parts, one argument.
The dossier is built in sections, each one carrying its own weight, and each one
answering to the same spec. Read top to bottom, they walk from the shape of the problem to the proof underneath.
Executive summary
The problem, the proposed solution, and why it holds, on the opening pages. A decision-maker gets the whole shape before the detail.
Technical design narrative
The architecture and the reasoning behind every call. What was chosen, what was ruled out, and why each decision was made.
Infrastructure
What runs where, how it scales, and what holds when a part fails. Sizing, placement, and topology, not left to assumption.
Delivery approach
How the work gets done: the method, the gate each phase has to clear, and how the whole thing is governed.
Team resourcing
Who does the work, how the roles cover the scope, and how continuity holds if a person moves on.
Low-level design
The system drawn down to the component: how a request moves, how state changes, and where data goes.
Project plan
The schedule, the milestones, and the critical path, with the concentration risks named up front instead of discovered late.
Technical appendix traceable
The proof underneath: requirements traced to source, decisions justified, assumptions logged, risks and compliance accounted for.
the diagrams
It draws the system, not just describes it.
Where words get heavy, Praxis draws. The count scales with the work, from a
handful on a small brief to dozens on a full build, and every diagram ties back to a requirement in the spec.
architecture
The whole system on one page, drawn twice: a technical view for the engineer and a proposal view for the buyer. Usually two or three, so both read the same design.
low-level design
The detail, drawn. Sequence flows, state lifecycles, and component blocks, often a dozen or more, down to how a single request moves through the system.
data flows
Where information moves and who touches it, typically one map per subsystem, so nothing is left to the reader's imagination.
infrastructure
Network topology, high-availability failover, and compute placement. A handful of diagrams that put what happens on a bad day on the page.
compliance
Every requirement mapped, covered or flagged. A traceability matrix, a risk register, and a compliance checklist, drawn so a reviewer can audit coverage at a glance.
why it holds
Dense, and every line accountable.
traceable
Every diagram and every claim ties back to a requirement, and every requirement ties back to the ask. You can follow the thread end to end.
honest
Nothing invented. Where the source is silent, the gap is drawn in as an open question, not smoothed over.
defensible
Built to be read closely by someone looking for the weak spot. The reasoning is on the page, so the answer to "why" is already there.
portable
The same document, whichever model wrote it. What it has to prove is fixed, so the choice of model changes the cost and the speed and not the standard. See everywhere it runs →
guarded
The same three checks guard it. The maker checks its own work, a pilot re-checks it, and a watcher checks the pilot. See the three checks →
✓→source ¶4
✓→source ¶7
⚑→open question
✓→source ¶9
where it starts
It begins as a spec.
The dossier is what the spec grows into. First the ask becomes a spec you can
audit, then Praxis takes it the rest of the way, into the document you hand over. Same thread the whole way
through.
The live check runs in your browser and returns a verdict in seconds. When you
want it on the real thing, send one piece of work. A person reads it, runs it with you, and shows you the pass.