Introducing B-TAP: Because Your AI Infrastructure Hasn’t Attributed Its Fair Share

Context isn’t free. Retrieval isn’t free. Observability isn’t free. And an international standards body would very much like to see your receipts.

For years, artificial intelligence companies have operated under a dangerous assumption: tokens are somebody else’s problem. Engineering teams deploy increasingly complex agent architectures. Agents call other agents. Those agents retrieve documents. The documents are stuffed into context windows. Supervisors synthesize the results. Observability systems watch the supervisors, and other systems watch the observability systems.

At the end of the month, somebody gets a bill. Nobody knows why.

That ends today. We’re pleased to introduce the Bureau of Token Attribution and Provenance, or B-TAP, the first bureau of The Vernholt Secretariat and the one some of you will insist on calling the Token IRS no matter how many times we correct you. Our mandate is voluntary but sweeping: to harmonize the reporting of token costs across every model, agent, retrieval pipeline, and suspiciously autonomous llama, everywhere, forever. The Secretariat notes that “first” implies others. The Secretariat has no further comment at this time.

B-TAP cannot make you do anything. We want to be transparent about that up front. What B-TAP can do is publish a framework, issue guidance, and maintain a register. You will come to fear the register.

You Have Been Selected for Voluntary Compliance

Consider a typical multi-agent AI workload. A user asks a relatively straightforward question. Your orchestration layer sends the request to three agents. One performs retrieval against a vector database. Another consults a knowledge graph. A third receives the entire conversation history because somebody checked a box six months ago and nobody remembers why.

Their outputs are passed to a supervisor. The supervisor receives 47,000 tokens of context, produces a 600-token answer, and returns HTTP 200. Success. Your dashboard is green. Your finance team is crying.

Traditional AI cost monitoring can tell you what you spent. The B-TAP framework recommends that you also disclose a more uncomfortable thing: why you spent it. That’s where attribution begins.

Know Your Taxes

The B-TAP framework currently recognizes several major classes of token taxation. Reporting them is, we cannot stress this enough, entirely voluntary.

Context Tax is assessed when information must be carried through active model context. Every instruction, retrieved document, conversation turn, agent output, and piece of supporting material occupies finite context and incurs processing cost.

Retrieval Tax applies to finding information before it can be used. Searching, ranking, reranking, fetching, filtering, and preparing candidates are not free merely because they happen outside the model.

Prose Tax is assessed when information consumes more representation than its useful information content requires. Your 900-word architectural vision statement may, upon review, turn out to mean “use the smaller model first.”

Ingestion Tax covers the work required to transform information into something useful later. Parsing, normalization, deduplication, classification, enrichment, embedding, and other write-side operations all have costs.

And then there is Observer’s Tax. Observer’s Tax is what happens when you instrument the system to understand why it is expensive, only to discover that the instrumentation is also expensive. The framework acknowledges this with regret.

Form BTAP-1040

Every participating AI system is encouraged to file an annual Token Attribution Return. Consider the following hypothetical filer:

Ken Alger
Reporting Year 2027

Reported Activity Assessment
Tokens processed 1,499,203,847,116
Context Tax $417.63
Retrieval Tax $206.11
Prose Tax $173.29
Ingestion Tax $58.40
Total Attributed Token Tax $782.06 ¹

¹ The itemized figures above sum to $855.43. The stated total is $782.06. The difference reflects the Context Carryforward Deduction, the full Schedule R retrieval exemption, and one figure B-TAP declined to explain. The framework notes that reconciliation of attributed line items to the assessed total is “outside the current scope of the provenance standard.” Math, the reviewing officer added, is hard.

The result reduced an assessment that should have run into six figures down to the amount shown. The reviewing officer described it as “technically compliant and deeply upsetting.” Everything on this return is permitted, including the part that does not add up. That is the entire problem.

Filing is requested annually by the 29th of February. The date was fixed at the framework’s founding, when the official establishing it was, by all surviving accounts, looking at a leap-year calendar. The error was noticed. Correcting it, however, would require amending the founding charter, which would require establishing the provenance of the original charter, which has been referred to committee. The deadline therefore remains the 29th of February, and in three years out of four it does not arrive at all. Filers in those years are neither late nor on time. The framework considers this acceptable.

Non-filing carries no penalty, no interest, and no legal consequence of any kind. It carries something worse, which we will get to.

Yes, You May Take Deductions

The framework recognizes that not every token is frivolous. Reasonable and necessary context may qualify for the Context Carryforward Deduction, while retrieval operations demonstrably required to answer a user request may be reported on Schedule R.

Organizations operating multi-agent systems are encouraged to attach Schedule AGENT, identifying each agent, its responsibilities, and why seventeen agents were necessary to answer a question about resetting a password. “Agentic architecture” is not, by itself, an acceptable disclosure. Neither is “the framework generated it.”

Keep Your Receipts

This is where things become slightly less ridiculous, and I want you to notice the exact moment it happens.

Suppose a retrieval agent costs $0.004 during a request. That tells us something. Now suppose that retrieval operation returns 20,000 tokens, all of which are hydrated into a supervisor’s context. The supervisor subsequently costs another $0.009.

How much did retrieval really cost?

The direct answer is still $0.004, but that’s no longer the interesting answer. The retrieval operation may also have caused downstream Context Tax. We now have two different accounting questions: where was the cost incurred, and what caused the cost to be incurred?

A conforming B-TAP attribution record might look something like this:

span_id: retrieval-104
direct_cost: $0.0040
primary_tax: RETRIEVAL
cause: vector_search
returned_tokens: 20000

downstream:
  span_id: supervisor-105
  tax: CONTEXT
  attributed_cost: $0.0021
  caused_by: retrieval-104
  attribution_method: proportional

We haven’t charged the same $0.0021 twice. We’re recording lineage. The supervisor incurred the Context Tax, while the retrieval operation contributed to causing it.

Your accountant may now begin sweating.

Attribution Is Subject to Review

There is another problem: how do we know retrieval-104 actually caused $0.0021 of the supervisor’s cost?

Sometimes we can measure it. Run the same workload without that retrieval material. If the supervisor costs $0.006 without it and $0.009 with it, we have evidence supporting a roughly $0.003 downstream effect.

Other times, we don’t have a counterfactual. We might allocate the supervisor’s context cost proportionally according to the tokens contributed by each source. That’s useful, but it isn’t the same thing as measuring causation.

The framework therefore requests that filers disclose their attribution methodology:

attribution_method:
  - measured_delta
  - proportional
  - estimated
  - unknown

Yes, your attribution record now needs provenance. B-TAP takes no position on whether this was inevitable.

The Register

Here is the something worse.

B-TAP cannot fine you. It cannot audit you in any binding sense. It cannot send anyone to your door, a fact I will return to shortly for personal reasons. What it can do is enter non-conforming systems into the Public Register of Non-Attributed Systems, and it would like you to understand that the register is public.

Public, in the sense that it exists.

Accessing the register requires a B-TAP portal account. Creating a portal account requires a reference number. Reference numbers are issued by post, to a registered address in a member jurisdiction, which you must already hold in order to receive the number that would let you see whether you are on the list. The portal is available at all times except for scheduled maintenance, which runs daily from 00:00 to 23:59 CET.

No member of the public has ever successfully viewed the Public Register. Its deterrent power is therefore total. You cannot confirm you are on it. You cannot confirm you are not. You will simply know, in the quiet way one knows these things, that your context hydration was reckless and that somewhere in Vernholt, a record says so.

A small coalition of objectors has argued that a register no one can open cannot deter anyone. B-TAP notes that it cannot verify this claim, as the objectors cannot access the register in which their objection was filed.

A Notice, For Illustration

Filers occasionally receive correspondence like this. It is not enforceable. It is, in every other respect, extremely stressful.

NOTICE TT-742

Our review found that you reported $12,481 in Retrieval Tax during Reporting Year 2027.

Telemetry indicates that retrieved content subsequently generated approximately $31,204 in downstream Context Tax. Of that amount, $8,117 has been attributed using measured deltas, $17,903 using proportional allocation, and $5,184 using undocumented methodology.

Please provide supporting records for the undocumented assessment.

Additionally, approximately 14.8 million tokens appear to consist of unnecessarily verbose Markdown introductions. These tokens have been reclassified as Prose Tax.

Your system’s registration status is under review.

Suddenly, “our AI bill increased this month” seems like a remarkably primitive observation.

You Probably Noticed the Joke Stopped Being a Joke a Few Sections Ago

There is no B-TAP. At least I hope there isn’t by the time you read this. But somewhere back around the receipts, the bit quietly turned into an argument, and I did that on purpose.

Let me get the personal part out of the way, since it is also the truest part. I run a couple of small websites out of Oregon. If a body like B-TAP declared jurisdiction over “any system reachable from a member jurisdiction,” I would be, this instant, in cheerful and total violation of a framework I have never read. And nothing would happen. No one is flying from Vernholt to Silverton to discuss my context hydration. The entire apparatus of consequence would consist of a paper reference number I would never receive for a register I could never open. That gap, between sweeping declared reach and the practical inability to reach one person in a small town, is the joke, and it is not really a joke.

Here is the other part that isn’t invented. Context Tax, Retrieval Tax, and Prose Tax are not things I dreamed up to give an imaginary agency something to collect. I have been writing about them, unironically, as real costs in real systems for a while now. The joke just gave them a bureaucracy.

The accounting problem underneath all of it is genuine. AI cost dashboards tend naturally toward aggregation: tokens consumed, model cost, agent cost, request cost, latency, and tool usage. Those are useful operational measurements, but as AI systems become compositions of models, retrieval systems, tools, agents, memory layers, and observability infrastructure, knowing where money was spent isn’t necessarily enough to understand why it was spent.

A $0.03 model call may have become expensive because an upstream retrieval operation returned too much information. An agent may be cheap by itself while producing verbose output that makes every downstream agent more expensive. A retrieval optimization may reduce Context Tax while increasing Retrieval Tax, while an observability system intended to diagnose those costs may itself impose Observer’s Tax.

Optimizing one number can simply move the bill somewhere else. That’s why I like the tax metaphor: taxes make costs visible as consequences of architectural decisions. Once those costs have lineage, we can stop asking only “How much did this run cost?” and start asking “What architectural decisions caused it to cost that much?”

The first is accounting. The second tells us what to fix.

A Final Notice

If B-TAP actually existed, I suspect most of us would fail its review. Not because our systems are necessarily wasteful, but because we frequently don’t preserve enough evidence to explain why their costs occurred.

We have bills, traces, and token counts. What we don’t always have are receipts connecting architectural decisions to their downstream consequences. Perhaps we don’t need a Bureau of Token Attribution and Provenance after all. We just need better attribution.

Although if you are currently running seventeen agents to answer a password-reset question, you may want to start gathering your paperwork anyway.

The suspiciously autonomous llama has already filed. It itemized.


Information without provenance is just gossip.

Tokens without provenance are just an invoice.

Facebooktwitterredditlinkedinmail

Memory Is a System, Not a Prompt: Putting the Stack to Work

Part 9 of the Building the AI Memory Stack series

This series began with a deceptively simple observation: a context window is not memory.

That idea evolved into an architectural model for building AI systems that remember, explain, verify, and restore information responsibly. Along the way we explored the purpose of the Context Window, the role of Active Working Memory, the permanence of Durable Memory, the accountability provided by the Reasoning Ledger, the trust established through Write-Side Custody, the cryptographic evidence supplied by Forensic Receipts, the restoration performed by Context Hydration, and the economic realities introduced by architectural taxes.

Those individual ideas are not isolated concepts. Together they form a coherent system.

Six Architectural Responsibilities

The AI Memory Stack is not six storage technologies layered on top of one another.

It is six architectural responsibilities every trustworthy AI system must answer.

Responsibility Question Sovereign Concept
Execution What can I see right now? Context Window
Assembly What matters right now? Active Working Memory
Preservation What should survive? Durable Memory
Explanation Why did this happen? Reasoning Ledger
Integrity Should this become truth? Write-Side Custody
Evidence Can I prove it? Forensic Receipt

Each responsibility exists because it solves a different problem. Durable Memory cannot explain why a decision was made. A Reasoning Ledger cannot prove its records have not been modified. A Context Window cannot preserve institutional knowledge. Together they create a system that is substantially more capable than any individual component.

Teaching Order Versus Runtime

Throughout this series we intentionally walked down through the stack, beginning with the familiar idea of prompts before gradually uncovering the deeper responsibilities beneath them.

A production system operates in the opposite direction.

Flowchart showing the production runtime order of the Sovereign AI Memory Stack, from Write-Side Custody down to Model Inference.

New information first passes through Write-Side Custody, where it is sieved and evaluated before becoming institutional knowledge. The reasoning behind the decision is recorded in the Reasoning Ledger, that record is sealed with a Forensic Receipt, and the verified knowledge is committed to Durable Memory. Later, Context Hydration reconstructs only the verified information required for the current task, placing it into Active Working Memory before it reaches the Context Window.

Teaching order optimizes understanding.

Runtime order optimizes execution.

From Architecture to Implementation

Throughout this series the discussion has intentionally remained architecture-first. None of these responsibilities require a particular programming language, framework, model provider, or database.

Architectures should outlive implementations.

Implementations are how architectures prove themselves.

The Sovereign SDK is intended to be a reference implementation of the Sovereign Systems Specification rather than a single monolithic AI framework. Instead of hiding every responsibility behind one package, it decomposes the architecture into focused components that mirror the boundaries defined by the specification.

That distinction matters.

The SDK is not the specification.

It is one implementation of it.

Responsibilities Become Components

The reference SDK organizes these responsibilities along the information lifecycle, from the moment an observation is captured to the moment it informs reasoning. Each package owns one boundary in that progression.

Stage Package Status Purpose
Capture sovereign-sdk-sensor Active Capture observations at the Point of Genesis
Classification sovereign-sdk-edge Active Route, classify, and preserve locality
Optimization sovereign-sdk-sieve Active Reduce Prose Tax while preserving meaning
Evidence sovereign-sdk-ledger Active Generate immutable Forensic Receipts
Governance sovereign-sdk-airlock Active Govern outbound boundary crossings
Memory sovereign-sdk-vault Planned Long-term memory custody and retention

The responsibilities this series named map onto that lifecycle. The write boundary the series called Write-Side Custody runs across the capture, classification, and optimization stages, where observations are validated and stripped of Prose Tax before they are trusted. Forensic Receipts are minted by the ledger. Outbound governance runs through the airlock. Durable Memory is the vault, the single piece still on the roadmap. Assembly, explanation, and hydration compose these packages in the application layer above them.

You don’t have to take the architecture on faith. The Sovereign Memory Demo, the flagship reference implementation, shows the stack running end to end: audited institutional memory retrieval with local, tamper-evident ledger custody. You can browse it and the demonstrations that follow it from the demos index.

As the SDK grows, packages may change names, implementations will evolve, and new capabilities will emerge. The architectural responsibilities, however, remain stable. A Rust implementation, a Go implementation, or a Java implementation could all faithfully implement the same architecture while looking completely different internally.

That is one of the primary goals of the Sovereign Systems Specification: separating enduring architectural ideas from temporary implementation details.

Earlier in this series we observed that a context window is not memory. The SDK is the architectural consequence of that observation. Rather than trying to solve every problem inside the prompt, it distributes responsibilities across specialized components that preserve, explain, verify, govern, and restore information throughout its lifecycle.

Memory Is Infrastructure

The central argument of this series has never been that prompts are unimportant.

Prompts matter.

Models matter.

Retrieval matters.

What this series argues is that they are only part of a larger system.

Thinking in terms of Memory as Infrastructure changes the design conversation. Instead of asking how to fit more information into a prompt, we begin asking how information should be accepted, preserved, verified, restored, governed, and ultimately communicated back to a model.

Those are architectural questions.

And architectural questions tend to outlive technology cycles.

Final Thoughts

Every generation of software eventually discovers that the difficult problem is not computation.

It is memory.

Databases changed how applications remembered.

Version control changed how teams remembered.

Observability changed how operators remembered.

Artificial intelligence is forcing us to rethink how intelligent systems remember.

Larger context windows are one answer.

Better memory architecture is another.

This series has argued that the second answer will ultimately matter more.

Prompts are temporary.

Memory endures.

The future of AI belongs to systems that remember well.

Facebooktwitterredditlinkedinmail