A map without a legend
Open any developer feed right now and you will trip over the same headline in five different fonts: someone cut their coding-agent token usage 70x with a code-graph tool. Someone else swears it was 120x. The open-source project underneath the claims has piled up close to 78,000 GitHub stars on the strength of exactly this promise. The multiplier is conditional and the honest number is smaller, but the tool is real and the idea is sound. It is worth understanding precisely what it does, because it validates a layer Deckwright is built on, and it draws the exact line the rest of this page is about.
Where the savings come from: the forward direction
Ask a coding agent a narrow question - "what does this function do" - and it answers cheaply. Ask it to trace how a request travels from the controller down to the database, and the behavior changes completely. It stops reasoning and starts exploring: it opens the controller, follows an import, opens the service, greps for a symbol, opens the repository, opens the database adapter. Twenty, fifty, sometimes two hundred file reads, every one of them billed, almost none of them thinking. The model is not answering the question yet. It is still trying to find where the answer lives.
That exploration is the fat these tools trim. They parse the repository ahead of time and hand the agent a pre-built map, so instead of reading two hundred files to reconstruct a call chain, the agent asks the map one question and gets the answer back. The tokens saved are orientation tokens - the cost of finding relevant code, not understanding it.
This is real, and Deckwright felt the same cost, so the Mission Graph carries a structural layer that answers the forward question in one query - the officer asks the map instead of exploring like a bare agent. Worth being precise about what that layer is, though: it is a deterministic parser. No model, no reasoning, nothing an agent runs. That is why 78,000 people could adopt one in a season, and why it is a commodity - the easy half. Anyone can add it; it regenerates from source any time. We did, because an officer should not pay to re-derive the map on every task. But it is table stakes, not the moat.
The question a parser cannot answer: the backward direction
Now ask the harder question. Not where the request goes, but why the adapter is shaped the way it is. Why this contract, this boundary, this constraint. A parser cannot answer that, because the answer is not in the code. The source tells you what the code does; it says nothing about what it was meant to do, or what was decided, or what proves it correct.
On a Deckwright deck, that answer is on the graph too. The same file node that carries its import edges also traces back to the Mission Card that built it, to the frozen specification that set its contract, to the passing test written before a line of it existed, to the moment a human approved it at the gate. Structure is derivable from source. That chain is not. It is the record of the decision - and it is precisely what gets thrown away when you keep the code and discard the context.
Where does the request go?
controller → service → repository → database adapter
Derivable from source by a parser. A commodity. The half the gold rush is about.
Why is the adapter shaped this way?
adapter → card → spec → passing test → decision
Not in the source at all. Cannot be parsed back out. The half only a system that captured the decision can hold.
Two directions, one graph, on the same nodes - and the Mission Graph carries both. Forward answers where. Backward answers why. The tools everyone is starring give you the forward arrow, brilliantly. The backward arrow is the one that cannot be reconstructed after the fact from code that has already been written - and it is the one only Deckwright keeps.
Why this is the Asset Test, exactly
This is the whole Deckwright thesis in one concrete case. Code is regenerable from context; context is not regenerable from code. The forward layer is the regenerable half - parse the repo again and you have it back. The backward layer is the asset - the accumulated record of what every change was for, which no re-parse can recover once the reasoning that produced it is gone. A tool that treats the code as the asset optimizes the forward direction and calls it done. Deckwright treats the context as the asset, so the backward direction was always the point of its code graph - the forward layer rides along, useful and commodity both. The gold rush is busy commoditizing the half we consider throughput. The half we consider the product cannot be commoditized, because it cannot be parsed.
Status, stated plainly
The Mission Graph records both directions today, and both update automatically as work completes; the graph is in daily use on Deckwright's own deck. The backward direction - provenance: the card, spec, test, and decision behind each file - is the part no parser can produce, and it is the reason the graph exists. The forward direction - the import and call structure that answers "what calls what" - is a deterministic parser, the same technique the token-saving tools use, and it needs none of the governance the rest of the system does, because parsed structure asserts nothing: it only reports what the source already says.
We tell you which half is which on purpose. The discipline that makes this document worth reading is the same one that makes the product worth trusting - see the technical diligence brief for the status vocabulary every claim on this site carries.