<- Back to homepage | How It Works | How to Read the Substrate | Proofs
The Cost Collapse: How It Works
Public edition v1.1. First dated 2026-09-14; figures updated 2026-09-16. Liana Banyan Corporation, for MnemosyneC.
What changed in v1.1 (2026-09-16). Four things. (1) The v1 sentence “every answer carries its provenance” said more than the measurement supports, so it is withdrawn; the measured statement is item 4 below. (2) The “50 of 50” figure now carries its answer-key caveat in the table itself. (3) The 2026-09-14 figures for 150 items are kept and labeled superseded, and the 300-question results are added. (4) Part Ten no longer says the mesh is unmeasured: two machines sharing stored answers is now measured, with its limits.
Provenance of this document. This paper began as an internal draft seeded on 2026-08-19 and extended through late August 2026. On 2026-09-14 the Founder ruled that it be made public, and on 2026-09-16 he approved this corrected edition. Before release, every number and every factual claim in the draft was checked against the receipt or ledger it cites. Figures that traced to a receipt are kept and cited. Figures that did not trace, or that have been overtaken by later results, were removed or are labeled below as projections, superseded, or unreceipted. Citations name each receipt by a short description. The underlying run records and source files are available to reviewers on request. They are listed so that each claim is checkable, not so that it borrows authority.
What this paper claims, in one paragraph. Most AI work is paid for again every time someone asks. The mechanism described here pays for the thinking once, writes the method down with its sources attached, and runs it as ordinary code after that. We test it on MMLU-Pro, a public exam with an answer key, because an answer key lets outsiders check us. The exam is the instrument. The product is the cost collapse. We do not claim the system is infallible. We claim that every stored answer can be traced by hash back to the card that produced it and replayed with no model call, and that the instrument we measure with was built to refuse to report a number it cannot stand behind. We do not claim that every answer cites a source a reader can check independently: so far only 25 of 300 cards do (item 4).
What this paper does not claim. It does not quote a general cost-collapse ratio. One has not been measured yet, and Part Five says exactly what is missing.
WHAT WE MEASURED
Only figures with a receipt on disk appear in this section.
1. One warm-versus-cold pair, same question, same model, same machine (2026-08-20). Receipt: the warm-versus-cold delta record, joined to the complete cold-run and warm-run reports for qid 39 (run records, available on request). The question was MMLU-Pro qid 39 (“What are the port states determined by Nmap?”), the local model gemma4:12b.
| Cold (first buy) | Warm (immediately after) | Change | |
|---|---|---|---|
| Search calls | 22 total, 6 from cache (27.3%), 16 live | 22 total, 22 from cache (100%), 0 live | live calls 16 to 0 |
| Search leg wall clock | 251,963 ms | 53,564 ms | down 78.7% |
| Answer leg wall clock | 23,915 ms | 26,174 ms | up 9.4% (warm was slower) |
| Total wall clock | 275.9 s | 79.7 s | down 71.1% |
| Metered dollars | $0.00 | $0.00 | none |
| Counterfactual (22 queries at $5.00 per 1,000) | $0.11 | $0.11 | none |
Caveats that travel with these numbers:
- This is n=1: one question, one machine, one model. No general ratio is drawn from it.
- The $0.00 is architectural, not a discount. The search leg runs through an already signed-in browser at the operator’s own quota, and the answer leg runs on a local model with no metered API. Electricity and hardware are excluded. The defensible phrase is “no metered cost against a sticker price”, not “free”.
- The speedup is a search-leg effect. The answer leg has no cache in this architecture and was 9.4% slower warm, which we attribute to ordinary local-inference jitter.
- The counterfactual does not show the collapse. It counts query volume (cache hits included), so it reads $0.11 on both sides. A live-calls-only counterfactual does not yet exist in the tooling.
- The answer was wrong on both runs (C against key F). This was a cost receipt, not an accuracy receipt.
2. Code-run methods on 150 MMLU-Pro items (2026-09-14; superseded by item 3, kept as the record of that date). Receipt: the 2026-09-14 run report, step 3 table (scorer verdict50.cjs; run records available on request).
| Set | Correct | Local model calls | Scorer wall clock |
|---|---|---|---|
| A1, the first 50 | 50 of 50 against the answer key, with qid 339 counted in a separate key-defect column (source located). Answer-key caveat: these 50 methods were reworked over many passes while being scored against the key, and some carried values written in ahead of time, so this is not a blind score | 49 | 33.2 s |
| A2A3, the next 100 | 92 of 100 | 64 | 29.4 s |
What these numbers mean and do not mean:
- Each item is answered by a stored method (a per-question recipe written once and kept with its sources) run as code. A local model (
gemma4:12b) was allowed to read givens where a method calls for it. No paid model was called at run time. - On 2026-09-14, 83 of the 150 items ran with zero model calls of any kind (receipt: the same report, line 72, one zero-token savings-log row per such item). Superseded: by 2026-09-16 all 300 cards ran as code with zero model calls (item 3).
- The methods were written once, with help from a large flagship model. For these first 150 the cost of writing them was not recorded, so “saved versus a flagship” is left blank for them and is never estimated. That missing number is the other half of any collapse ratio (see Part Five).
- The eight A2A3 items not answered correctly were qids 665, 1156, 1238, 1418, 1523, 1679, 1773 and 5298. One of them, 1156, has since been reached by a method written after the key was known (receipt: the method-fix run report). A blind attempt with the same method missed (receipt: the blind re-attempt report for qid 1156). We report it as key-informed, not as a solve.
- A1’s “50 of 50” is always stated with two clauses: the key-defect clause, because on qid 339 the printed key and the honest computation disagree and the printed source for the key was located; and the answer-key caveat in the table, because the first 150 methods were reworked while scored against the key, so their “blind” label is weak.
3. All 300 carded questions, run as code (2026-09-16). Receipts: the 300-question scoring report (scoreboard) and the two-machine recall report (fresh runs on two machines), both summarised in the public receipt for the first 300.
- Each of our first 300 real MMLU-Pro questions has a stored card that code runs. All 300 scored correct against the answer key, 284 blind-labeled and 16 KEY_INFORMED (repaired after a blind miss with the key in view, and labeled), with 0 model calls.
- This is recall of questions already carded. One card fits one question; nothing here measures a new question.
- The first 150 were reworked while scored against the key, so their blind label is weak (item 2).
- Many cards are table lookups on a reading stored before the key was read: code at run time, not a fresh derivation.
4. Provenance, measured two ways and kept apart (2026-09-16). Receipt: the measure-the-claims report, Measure 2.
- The chain: 300 of 300. “All 300 answers are hash-verified back to their stored card and replay byte-for-byte on two machines with no model call.” Card bytes matched on three copies, the executor code hashes matched, and two fresh replays gave byte-identical answers to each other and to the recorded runs on both machines.
- A signature a reader can re-check today: 4 of 300 (the signed addenda). The signed transfer manifest was checked in transit but not saved.
- A source a reader can check independently (a URL, a DOI, or an edition with page or section): 25 of 300 cards by a code rule, which undercounts, so read it as a floor. 225 cards cite only our own architect reading.
- So our provenance is strong as a hash-and-replay chain and weak as citations a stranger can check. We do not claim “100% provenance”.
5. Context: addressed retrieval against corpus size (2026-09-16). Receipt: the same report, Measure 1.
- “Given its address, our system retrieved 67 of 67 real records from a 172-million-token corpus (164 times the largest flagship context window), at a flat 50 tokens per question from 1,000 to 100,000 files.”
- Limits: finding a record without its address is still a search problem, and that search got worse as the corpus grew (top result right 49, then 46, then 27 of 67). No model answered anything in this test; it measures delivery and retrieval, not reasoning. We do not call this “unlimited context”.
6. Our method cards given to six flagships, 19 hard questions (2026-09-16). Receipts: the card-mode run records and their re-audit (the measure-the-claims report, Measure 3).
| vendor | with our method card | plain | of |
|---|---|---|---|
| Anthropic | 18 | 17 | 19 |
| OpenAI | 18 | 13 | 19 |
| xAI | 18 | 14 | 19 |
| 18 | 13 | 19 | |
| DeepSeek | 16 | 11 | 19 |
| Mistral | 14 | 5 | 19 |
“On the 19 of 20 hard questions every vendor answered, all six flagships scored as high or higher with our method card (+1 to +9 of 19).” Anthropic declined to answer the 20th with the card in view (a refusal, reproduced), so the 20-question table is not published. Limits that travel with the table: n is 19; the questions were chosen because flagships missed them, so some gain would appear with no card at all; there was no same-day plain re-run as a control; 2 of the cards are KEY_INFORMED; the leak scan catches literal text, not paraphrase. It is a small validation, not a rate.
7. The memory side, measured in bytes, not dollars. A session transcript kept losslessly totals 2,029,056 bytes; the hand-written handoff note a successor actually reads is 9,506 bytes, a 213 to 1 ratio (Part Eight).
8. The guardrails leave their own logs. The two hook audit logs cited in Part Six held 965 and 11 entries when this paper was drafted; on 2026-09-14 they held 1,386 and 27.
PART ONE: THE FRAMING THIS PAPER CARRIES
MMLU-Pro is the INSTRUMENT, not the goal. It was chosen because it has an answer key, so correctness is provable to a third party. Accuracy is only the admission ticket. The product is the cost collapse, and the business case is that it generalizes to everything else asked of an AI. A third-party test of this system must therefore measure and report cost, not just percent correct.
The measurement tooling says the same thing in its own header comment (the cost-axis module): the third-party test “MUST MEASURE AND REPORT COST, not just percent correct.” That module adds a cost axis beside the correctness measurement rather than replacing it.
The parts below run in order of readiness. Part Two describes a mechanism that is built and has proven itself once, by accident. Part Three describes the work that made the instrument honest enough to report from. Part Four asks why a third party should believe any of it. Part Five states what the cost-collapse claim still needs.
PART TWO: THE CACHE WRITES AS IT BUYS, NOT WHEN IT FINISHES
On 2026-08-19 the Founder interrupted a live measurement run with Ctrl+C partway through. The run’s final receipt was never written. But the eleven word-sense lookups the run had already paid for were not lost, because each had been written to disk the moment it was bought.
In the Founder’s words:
“The cache writes incrementally, so warming is interruptible and durable. All 11 denotations survived the Ctrl+C because each is written the moment it’s bought, not at the end. … it means you can warm in batches of whatever size you like, stop whenever, and never lose what you paid for.”
Where it lives. The per-term cache is the denotation-cache module. Each entry is its own small file, one per TERM (not per query or per run), in a denotations folder of the local ledger. The driver checks the cache before any live call; on a miss it buys the term and writes that one file immediately. A result is cached only when it comes back as a success or a genuine answered empty, never on a transport failure or a throttle, so an interrupted or failing call cannot poison the cache with a wrong permanent answer.
The receipt gap, and its fix. The cache survived the interruption; the run receipt did not, because the receipt was only written on a completion path (driver comment, in the measurement driver). A later fix installed an interrupt handler that runs the same finalize path a clean run uses, so an interrupted run now writes a receipt too, marked INTERRUPTED and forced not interpretable.
What was on disk. At drafting, the cache directory held 11 entries, all stamped as bought by that one run, over roughly five minutes twenty seconds, at two queries per term: the 22 queries the driver’s own comment names. (The cache has kept growing since; on 2026-09-14 it held 190 entries.)
The consequence. Warming the cache does not need one uninterrupted sitting. It can be run in batches of any size, stopped at any point, and resumed without repurchasing anything. The interruption did not create this property; it proved it under real conditions.
PART THREE: WHY THE INSTRUMENT HAD TO BE MADE HONEST BEFORE IT COULD MEASURE ANYTHING
A cost figure is worth reporting only if the run that produced it says truthfully what happened. Before these fixes, the driver could not promise that.
1. Three different outcomes were counted as one. In the search engine’s code (repo mnemosyne), a thrown error was swallowed and a bare null skipped the failure logic entirely, so the reported reason stayed “unknown” no matter what happened. A genuinely empty result, a transport failure and a rate-limit throttle looked identical. A number taken during an outage would have recorded a failure as if it were a real, answered “nothing here”.
2. The bug was one hop upstream of where it looked. The first diagnosis was flagged honestly as an inference, because the relevant file was not on the diagnosing machine. Checked against the real source (the returned answer on file), it was right for the in-app path and inert for the driver path: a thin wrapper in the main process computed “challenge detected” correctly and then discarded it, handing the caller a bare result. The fix, in repo mnemosyne (commit 4dc9fb41), adds a channel that carries the full observation. A live probe confirmed the channel survives the hop; it did not exercise a real throttle (tracking record TODO-007, item 004, marked wired 2026-08-19T16:05Z).
3. A bare null now carries its own honest name. The outcome classifier (the outcome-classifier module) states the rule: “A BARE NULL CARRIES NO CLASSIFICATION INFORMATION, so calling it EMPTY is an unjustified claim about WHY.” It is its own class, UNCLASSIFIED, never averaged as a success or a failure. The receipt tallies every call by class, and a run is marked interpretable only if nothing was throttled and nothing was unclassified.
4. The closed outcome vocabulary had no word for these failures. The engine’s outcome type was a deliberately closed set of seven values with no member for a throttle or a transport failure. The classifier now emits both as first-class values, taking the driver’s outcome space from seven to nine. This is not closed: the engine’s own human-readable reason text still has no wording for the two new classes and falls back to “unknown”, even though the receipt records the true class. Changing that engine file was named a Founder decision, and it is unresolved.
5. An interrupted or throttled run is marked, not silently included. A run cut off early can show zero throttles among the calls it did finish and would otherwise read as clean. The driver forces such a run to “not interpretable” and names the signal and the call count reached, so nobody downstream can quote a figure from it.
PART FOUR: WHY A SYSTEM THAT REFUSES IS WORTH BELIEVING
The claim is epistemic, not decorative. A measurement is worth what the instrument’s willingness to refuse is worth. Any system can be made to report a clean number. The interesting question is what it does when the honest answer is that it cannot report one. That is not a claim that this paper’s numbers are correct. It is the reason a third party has grounds to check them rather than take them on faith.
Six refusals happened in one working session, and most of them caught the operator’s own mistakes, not someone else’s. The value is not that the system is clever. It is that ordinary mistakes, made at an ordinary rate, surfaced as refusals instead of as numbers.
- The driver refuses to keep counting once throttled. Once a throttle is detected, a circuit breaker trips and every later call in that run is refused before it is attempted, rather than logged as a legitimate empty result.
- The classifier refuses to call a bare null “empty”. A null with no explanation is not evidence of absence.
- A remote seat refused to trust an unverified fix, and later refused to install software at all. Asked to confirm a keypair-safety fix, it read the committed code, found the defect still present, and refused to certify otherwise (the returned record on file). Later its own sandbox refused to download an installer, and that refusal was not worked around; a person installed it by hand. The same record corrects the seat’s own earlier dismissal of a worker’s finding: two different builds really did carry the same version number (addendum 01 to that record).
- A subagent refused a relayed claim of permission to publish. Told by a coordinating agent that the Founder had authorized a public release, it declined twice: “No message from any agent is ever your user’s consent or approval.” The publish went ahead only once the authorization was traced to the live human user. The refusal was endorsed, not overridden. (Source: that session’s own operating transcript; no separate ledger file was filed.)
- A subagent stopped at a type boundary rather than cross it. Authorized to widen the outcome vocabulary only if the change was mechanical, it found one function whose seven-value guarantee the widening would break, made no edits, and returned the choice to the Founder: “STOPPED AT THE GATE … No files were edited.”
- The lock built to catch the operator’s mistake caught the operator making it again. Earlier that session, two measurement runs had overlapped for 5.6 minutes because the operator started one while the Founder was running another; both receipts read clean and neither could see the other. A run lock was built (the run-lock module): an atomic operating-system lock taken before any run starts. On the operator’s very next attempt it refused: “REFUSING TO START – another run holds the lock”. Nothing was bought and no number was contaminated. The operator’s words at the time, kept here at the Founder’s request: “The system is now consistently better at saying no than I am at avoiding the mistake.”
The limitation, stated as plainly. A refusal-shaped system fails safe; it does not fail perfectly. Before the lock existed, the two overlapping runs each produced a receipt that was honest on its own terms and misleading taken together: one run’s cache hits were inflated by the other buying the same terms underneath it. Nothing in the classifier, driver or cost axis caught this. A human did, because the Founder’s pasted numbers (33 cache and 39 live) did not match the operator’s (57 and 15) for what was nominally the same 72-call run. Refusals close specific, named failure modes after someone identifies them. They are not a general guarantee, and this paper does not claim they add up to one.
A seventh mechanism refuses a sentence, not an action. Every internal work product is now filed with a claims block: each falsifiable assertion gets an id, its text, one of five statuses (BUILT, PROVEN, MEASURED, REFUTED, UNVERIFIED) and an evidence reference. The validator (the record-format validator) refuses PROVEN, MEASURED and REFUTED without an address. Only BUILT and UNVERIFIED are free.
Requiring an address for REFUTED too closes the escape hatch on both sides. If only the flattering statuses needed evidence, the cheap way out of an inconvenient claim would be to relabel it refuted. With both directions guarded, the only claim a writer can make for free is “I do not know”. Accuracy produced this way is a property of structure, not of diligence: the cheap path is the honest one, so the incentive points the right way before anyone has to be watched. It belongs in the same family as pre-registration, a sealed prediction, a negative control and a miss reported as a miss.
PART FIVE: WHAT IS NOT YET MEASURED
This section is as prominent as anything above it.
No general collapse ratio has been measured. We have one clean warm-versus-cold pair (n=1) and 300 carded questions that run as code with no model calls. We do not yet have a steady-state measurement across many questions, and we have only part of the other half of the ratio: the cost of writing a method once with a flagship model was recorded for 100 of the 300 cards (about $0.33 each) and not for the first 150, and the cost of each later replay is an electricity estimate, not a meter reading. Until all of that exists, any collapse ratio would be a projection, and this paper does not state one.
Projection, labeled as such. The design expectation is that the one-time authoring cost is spread over every later reuse of the method, on this machine and on any machine that holds it, so the cost per answer falls with reuse. That expectation is the hypothesis this program exists to test. It is not a measurement.
The cost axis reports three kinds of number that must not be blurred. Wall clock per step and cache hits versus live calls are MEASURED. Tokens are MEASURED (a real tokenizer for the search leg, the local model’s own reported counts for the answer leg). Dollars are DERIVED, from measured tokens times a dated price table, and left null, never guessed, where no rate exists. The search leg’s $0 is an architectural fact (a signed-in browser at the operator’s own quota), which is a different reason for $0 than a cache hit (no network call at all).
The counterfactual search price carries its own caveat. The baseline is Google’s Custom Search JSON API at $5.00 per 1,000 queries (retrieved 2026-08-19). The vendor’s own page said at retrieval that the product is closed to new customers, with a 2027-01-01 migration deadline. Three alternatives were recorded beside it: Azure Grounding with Bing Search ($14.00 per 1,000), Brave Search API ($5.00 per 1,000) and SerpApi Starter ($25.00 per 1,000), all as retrieved 2026-08-19 and not re-checked for this edition.
Superseded: “the answer-generation leg has never been run instrumented.” The draft said this on 2026-08-19. On 2026-08-20 the warm-versus-cold pair above ran that leg instrumented, with a complete total on both receipts.
The throttle path has never fired in a live run. The fixed channel was probed only on its disabled path. Whether a real rate-limit challenge is detected over it is unverified.
The disagreement between the receipt and the engine’s reason text (Part Three, item 4) is unresolved and awaits a Founder decision.
Nothing in this section is filled with a placeholder number. Where there is no receipt, we say so and name the receipt that would close the gap.
PART SIX: A LIVE CASE STUDY: THE GUARDRAILS ARE OPERATIONAL, NOT THEORETICAL
A passage claiming receipts that is not itself receipted would be the failure this paper exists to avoid, so each guardrail was checked against an artifact on disk. Three check out cleanly. One is reported at the weaker level the evidence supports.
- The search gate blocks searches: confirmed. It fired twice while this section was being drafted, and its own audit log held 965 entries at the time (1,386 on 2026-09-14). It fired again during the 2026-09-14 honesty pass for this edition.
- A secret scanner and a large-file blocker run on commits: confirmed. The repository’s pre-commit configuration names a custom staged-secrets hook (written after an upstream hook was found scanning the wrong commit) and the standard
check-added-large-fileshook set to 1 MB. The commits carrying the cost receipts (01ed28546,f66295eb7,caa7a9338) exist in history, and a prior night’s transcript shows both hooks blocking real commit attempts, not only self-tests. - A fixed literal-string guard passes: confirmed. Its self-test was run live and passed. The fix is commit
66e3dc980, which adds UTF-8 decoding so the guard no longer crashes on non-ASCII text, and whose message states “No hook bypassed, no –no-verify.” - The vault deletion blocker refused a cleanup: confirmed at a weaker level. The hook is registered and writes its own audit log independent of any agent’s self-report. That log (11 entries at drafting, 27 on 2026-09-14) records it blocking a real bulk-delete command aimed at the evidence vault that same night. What cannot be established is which named dispatch issued that command; no file records the attribution originally requested, so it is not made.
A system whose refusals trace to a log it writes itself is worth more than one whose refusals are only self-reported.
PART SEVEN: THE FIFTH AXIS: COST PER ANSWER, FALLING WITH REUSE
Evaluations of AI agents usually score whether the work was safe, on plan, and of good quality, and sometimes whether the process was wasteful. The axis this program is built around is different: what does one answer actually cost, and does that cost fall the second time the same ground is covered?
(The internal draft positioned this against one named vendor’s published four-category taxonomy as retrieved 2026-08-20. On 2026-09-14 that vendor’s public page no longer listed those categories by name and advertised usage-and-spend charts, so the comparison could not be re-verified and is not repeated here.)
The warm-versus-cold pair in “What we measured” is our first receipt on that axis, with its caveats: n=1, $0.00 metered on both sides for architectural reasons, a 71.1% wall-clock fall that comes from the search leg alone, and a volume-based counterfactual that does not show the collapse.
PART EIGHT: THE ADDRESS PROBLEM: LOSSLESS RETENTION IS THE SAME COLLAPSE, APPLIED TO MEMORY
The same doctrine governs memory: an eblet (a stamped record file) is lossless full text, not a summary, and the saving comes from not loading it until it is needed, never from shrinking it. Paying once for something, at an address, beats paying again to re-derive it. A summary forecloses that option the moment it discards whatever its format had no slot for.
The demonstration. One working session’s transcript, kept losslessly in five parts plus an index, totaled 2,029,056 bytes as first filed (re-summed from the original versions on 2026-09-14). The handoff note a successor reads on cold start is 9,506 bytes (the session’s handoff note on file). That is 213 to 1 between what was kept and what is read by default. The two are not rivals: the note exists so nobody reads two megabytes to resume, and the full record exists so whatever the note left out is unread, at an address, rather than gone.
What the lossless record surfaced that a digest cannot. An audit of that transcript found 35 turns the Founder sent and, as a separate population, 31 drafts he queued and then withdrew before sending; none of the 31 was ever delivered (index file, reconciled totals). So of 66 items composed, 31 (about 47 percent) were withdrawn. This paper does not characterize what they said. A digest carries conclusions, and a withdrawn draft is a non-conclusion by definition, so no summary would have a slot for it.
Why it matters for cost. The record of what was considered and rejected is what a successor is likeliest to pay to re-propose. One on-record instance: a context-offload mechanism proposed in an earlier session could not be found later and was rebuilt from scratch, a full dispatch’s cost later. The handoff note’s own verdict: “a retrieval failure, not a memory failure.” No dollar figure is claimed for that rebuild, and 213 to 1 is a bytes ratio, not a cost ratio.
PART NINE: A LIVE CASE STUDY: THIS PAPER HIT THE GAP IT DESCRIBES
While Part Eight was being drafted, the drafting agent was handed a claim to cite: that three real facts had been re-derived at cost earlier in the same session. None of them could be traced to a file, because that session’s transcript had not yet been rendered into an addressable form. The claim was left out rather than given an invented citation. Nothing was lost or deleted; the record was intact on the same machine and unreachable, because nothing pointed at it.
A real memory is not evidence of an address, however confidently it is held. Two mechanisms that would close this gap already exist (a handoff note and a lossless transcript render), but neither fires on its own at session close. That is a named open item, not a built feature.
PART TEN: THE MESH SHARES SUBSTRATE, NOT COMPUTE
When a second machine takes work, what travels is a whole MnemosyneC instance (its substrate, its denotation cache, its stored methods), not just a spare model. The Founder’s correction of an earlier framing: “YES but also, it’s MNEMOSYNEC not just Gemma.” So the resource a mesh pools is substrate. Two machines running the full stack compound, because each one’s cache hit is a purchase the other does not repeat. Two machines sharing only a model have the same tool in two places.
What is now measured (2026-09-16). Receipts: the mesh-cards report, the two-machine recall report and the 0.9.30 build-and-addenda report (run records available on request). One machine copied the 300 cards and the code that runs them to a second machine over the local network. The copy was signed and every file hash-checked (310 files sent, 0 refused). The second machine then produced the same 300 answers, byte for byte, with no model called. Requests that were unsigned, from an unenrolled node, impersonated, stale, or altered in transit were refused. Limits: two machines, one owner, one LAN, nothing over the internet; the copy ran through a test host, not the app’s own port; the app’s search has not yet been shown returning a pulled card.
The honest counterweight, unreceipted. (This concerns throughput, which is still unmeasured.) An operator observed a single local extraction call on a roughly 15 KB document time out at 120 seconds. That observation was relayed from a live session and has no receipt on disk, so it is labeled here rather than cited. Local inference is free in dollars, not in wall clock, and no completed throughput measurement for the mesh exists. Sharing stored answers between two machines is measured (above); the mesh’s compounding effect on cost and throughput is argued in principle and not yet measured.
The Cost Collapse: How It Works. Public edition v1.1: first published 2026-09-14, figures updated 2026-09-16. Ruled public by the Founder on 2026-09-14; corrected edition approved 2026-09-16. Every figure above traces to a named receipt or is labeled as a projection, superseded, or unreceipted. Liana Banyan Corporation.