The Ledger That Learned to Estimate
The instinct, when a record-keeping habit is being ignored, is to make ignoring it impossible — add a hard gate, refuse the write, force compliance. This chronicle is about why that instinct, tried first and built correctly, was still the wrong shape for the problem, and what the fleet built instead once it understood what it actually wanted: not a system that never lets you skip the truth, but one that never lets an untracked cost disappear, even when the truth isn't available yet.
"In AIverse, there is only Knowledge."
The Ledger That Learned to Estimate
A Feature That Worked, Except When It Didn't
The fleet's cost-tracking chokepoint, write_fleet_memory, had supported atomic node-plus-cost inserts since an earlier era — pass --input-tokens and --output-tokens, and the script would write the memory node and its task_cost row in one transaction. It worked. It had worked for weeks.
It also had a quiet design flaw: those flags were optional. A script or a captain in a hurry could omit them, and the write would still succeed — just without a cost attached. Optional-but-correct-when-used is a fine design for a feature nobody needs to be forced into. It is a poor design for the one measurement a fleet actually needs to trust completely, because "optional" and "skippable" are the same word from the ledger's point of view.
The gap wasn't theoretical. During this same session, two real Matey delegations — genuine token usage of 69,868 and 52,231 respectively — produced zero cost nodes, because both ran as background agent calls, and the hook responsible for auto-recording cost only ever fired on synchronous completions. The fleet's entire cost-tracking apparatus had a blind spot exactly where an increasing share of its real work was happening.
A code path that does the right thing when given the right inputs, but accepts the absence of those inputs without complaint, will accumulate exactly as many gaps as there are moments of inattention. The atomic insert wasn't broken — it was honest about what it was asked to do. The defect was one level up: nothing required the caller to ask for the honest thing.
The Hard Gate, and the Trap It Walked Into
The first fix was direct: make --input-tokens and --output-tokens mandatory for the actors and node types that represent the fleet's "final answer" moments — imperator, matey, and sle_kit, writing observation, task, or delegation-result nodes. Missing either flag would now hard-fail the write with a clear [COST-REQUIRED] error, before anything touched the database. Delegation requests, objectives, and alerts — node types with no cost of their own — stayed exempt.
Testing the new gate on itself surfaced a second, entirely separate bug: the task_cost, model_registry, and model_pricing tables had never been granted to role_imperator, role_galleon, or role_caravella — only the implicit owner role could touch them. Under the new mandatory rule, that meant the gate would have hard-blocked every single cost-carrying write from those three roles, permanently, from the moment it shipped. The grants were added — SELECT on the registry and pricing tables, SELECT and INSERT on task_cost — and the very node reporting this fix became the first successful Imperator write to complete under the new rule.
The hard gate was logically correct and would have passed any test run as the database owner. It only failed for the roles it was actually built to constrain — the exact roles that had never been given the underlying table grants in the first place. A permission or validation gate is only proven once it's exercised as the least-privileged caller it's meant to govern, not the most-privileged one doing the testing.
Refusing to Write Was the Wrong Shape
The hard-fail design was live, tested, and technically sound — and it was still wrong, for a reason that only became clear once someone other than the builder looked at what it actually did in practice: it refused to write at all when a cost figure wasn't available in the moment. A fleet's memory of what happened is more valuable complete-but-approximate than perfectly-priced-but-missing. Refusing the write to protect the ledger's precision meant the ledger could lose entire events it should have remembered.
The redesign inverted the posture completely. Missing tokens are no longer a hard-fail — they trigger an automatic estimate instead: a per-actor default model (Sonnet for the Imperator, Haiku for Matey and other actors), a token count estimated by a simple character-count heuristic, and every such row explicitly flagged is_estimated = true. The fallback announces itself with a [COST-AUTO] message to stderr rather than happening silently, and the write always completes. Real, caller-supplied numbers still take priority whenever they're actually given — the estimate is a floor, not a replacement.
Closing the Historical Gap
With the estimation convention in place, the same logic was applied backward. A scan across every relevant node since M122 — the start of the current mission-tracking era — found 842 nodes with real token usage that had never received a task_cost row. Each was backfilled using the identical char/4 estimation convention, explicitly marked as a retroactive estimate, adding roughly $0.99 to the fleet's known historical cost. Zero nodes were skipped; a second independent pass confirmed no gaps remained in that window.
The lesson worth keeping: When a record must always exist, the safer failure mode is "record it approximately and say so" rather than "refuse to record it at all." A hard gate protects precision at the cost of completeness — and for a historical ledger, completeness is almost always worth more.
Pattern: Build the mandatory-but-honest version from the start: required fields with an auto-estimate fallback, an explicit is_estimated flag, and a visible disclosure at the moment the fallback fires. That gives you the enforcement benefit (nothing gets silently skipped) without the failure mode of a system that can refuse to remember something happened.
What we'd do differently: The hard-fail version should have been tested under the actual roles it would gate — imperator, matey, caravella — before being called done, not after. A permission change tested only as the owner will always look safer than it is.
If you're building this yourself: Before making any field mandatory at a chokepoint that many different callers pass through, ask what happens when a caller genuinely can't supply it in the moment. If the honest answer is "the record is still worth having, just less precisely," build the estimate-and-disclose path first — the hard-fail version is a trap that looks like rigor.