As development records grow, an old document can read like a convincing description of the present. Northstar retains records of an embedded CLI, model and automatic-repair path. Describing the current product required first identifying the time and architecture each document actually concerned.
A removed capability can still have useful history
Removing an internal model path from the product did not require erasing its reasons and failures. Those records explain why the structure was tried and where cost and responsibility accumulated. Erasing the past would make the present architectural choice harder to explain.
The problem was confusing retention with activation. Source kept in an archive differs from code reachable in the installed application. A successful historical test does not establish that the path remains wired into the product. I retained history while separately checking any claim of current availability.
One architecture page cannot establish the present
An early diagram includes ModelGateway and an Agent Worker. Versioned changes follow elsewhere on the same page. Extracting one paragraph could suggest that the browser still calls its own model and repairs procedures internally.
The current external-control contract explicitly records removal of embedded CLI gateways, model connections, repair runtime and entry points at version 0.1.148. I compare diagrams with the current contract and installation scope. A document titled architecture does not make every sentence a description of the same present moment.
After finding code, check whether it is wired in
Retired code can rank prominently in a source search. Treating a function name as proof of an available feature can reintroduce a removed path into the public description. The next questions concern its caller, inclusion in the current build and whether it exists only for testing.
The external MCP stdio server and current tool contract describe a live entry point. Older model tests can remain as offline regression material. Both being files does not give them the same status. I distinguish a route a current user can call from evidence explaining an earlier decision.
Attach historical conditions to historical numbers
Automatic-reuse tests from the embedded-CLI period recorded tokens and calls. Applying those numbers to every current external conversation changes the measurement boundary. Zero model calls inside a saved program also differs from zero calls across an entire conversation.
I therefore attach version, input, execution route and included costs to numerical results. Historical receipts lacking cache decomposition cannot support an invented current cache-saving percentage. Age does not make evidence useless; a precise interpretation boundary makes it reusable.
A paused plan is different from a completed capability
An external-PC Jupyter connection once considered must not be described as a currently supported capability. The existing internal NotebookBrowser SDK and an external notebook connection have different scopes. The presence of one cannot establish completed compatibility for the other.
Separate states for planning, implementation, testing, installation and real workflow completion reduce this confusion. Inspecting selected files also differs from reading the complete source semantically. As the maker journal grows, managing evidence status becomes more important than simply accumulating more prose.
Keep history so the present can be described accurately
Readers do not need a flawless story of linear success. They need to understand what changed, what runs now and which limits remain. I want to retain failures and revisions while separately connecting evidence for the current product description.
This article compares documentation and the current contract; it is not a fresh operational test. Future changes should retain an old article's historical meaning while rechecking current capability guidance. Preventing an earlier design from becoming an accidental present-day promise is a basic responsibility of continued publication.