Inside the architecture
How a request becomes governed work
The full path a delegated request travels, from the message I write to the work that comes back, one capability at a time.
01 · The message
It arrives in natural language
A sentence arrives and the system immediately begins placing it. Named-entity recognition reads the entities in the message, maps them to concepts in the graph, and the request stops being free text and becomes something the structure can reason over. The graph that receives it already holds years of prior work.
02 · The graph
It joins a standing structure
Prior decisions do not live in a document someone has to find. They live as nodes in the graph, typed and connected to the research and rationale behind them. The graph is not a single database; it is a polyglot store that uses a native graph for typed relationships, a vector store for similarity, and a relational store for task state.
03 · Grounding
Ingestion grounds every claim
Nothing enters the graph as a bare assertion. Every claim is tied to a verbatim span from the source that generated it, so anything the system believes can be traced back to its exact origin. That discipline is what makes the structure checkable rather than trusted on faith.
04 · The math
Link prediction finds the connections
The graph's controlled vocabulary defines a typed ontology, and it is that typed structure that makes the math meaningful. Link-prediction models trained on those typed nodes and edges propose relationships the source text never stated, returning candidates for review rather than settled fact. The agents draw on those proposals, alongside other graph operations, to reason about how subsystems should be designed.
05 · Retrieval
Context is fused, not guessed
When the system needs context, it pulls from three signals at once: the typed structure of the graph, vector proximity from Qdrant, and exact keyword match. Reciprocal rank fusion reconciles those three ranked lists into one result. That fused context is what the agents reason and design over.
06 · Planning and documentation
The plan is the record
Planning and documentation are the same structure here: the governance graph. It is a multi-layered, typed graph of requirements, decisions, and the reasoning that ties them together. I plan by reasoning through it, and because every node carries its rationale and provenance, the same graph is the durable record. There is no separate documentation step.
07 · Verification
Key invariants are model-checked
Some design decisions carry invariants that must hold in every case, and prose cannot establish that. For those, I write a TLA+ specification and a model checker exhausts every reachable state to confirm the invariants, so a flaw surfaces in the specification instead of in the built system. It is verification applied where it earns its cost, not a gate every task passes through.
08 · Orchestration
Work fans out
A decision becomes work, and the work becomes tasks. Each task enters a PostgreSQL-backed queue with its dependencies declared, waits there until they are met, then fans out to however many agents can run in parallel. The page being read now was assembled the same way.
09 · Code
Manifests bind it to the code
Every directory in the repository carries a manifest, a machine-checked file that names the decisions governing that code. Nothing is inferred from the file structure or asserted in a document somewhere else. The governance is right there, in the directory it governs.
10 · CI/CD
Every change runs the pipeline
Every commit runs the full battery of gates before it can land. The test suite, the formal-method checks, the brand and terminology linters, signature verification, and the trace-composition rules all run on each one. The pre-commit gauntlet holds the commit until they pass, so the rules bind mechanically rather than by my remembering to check.