The Acceptance Annex processes three kinds of transactions: buyback settlements, destruction filings, and build registrations. In the Annex's eastern processing corridor, there are clerks who have handled the first two categories hundreds of times and the third exactly never. This is not an anomaly recorded in any bulletin. It is simply how the staffing has settled, over accumulation cycles, as the mix of work flowing through the Annex shifted without anyone formally deciding it had.

The practical consequence is that when an operator arrives at the eastern corridor with a build registration — a declared chassis, a declared cost, a set of capability tags — they may be routed to a clerk whose working knowledge of the build process is entirely theoretical. The clerk knows the form. The clerk does not know the form the way a supervisor at the Calvert line knows it.

This piece is about what that gap costs, how it compounds, and what operators tend to assume about Annex clerks that is not accurate.

What the Acceptance Annex Actually Processes

The Acceptance Annex is the settlement desk for transactions that touch the Central Intelligence directly. When an operator offers a robot or resource to the Intelligence under the buyback mechanism, the resulting agreement — price, reference value, the haircut the Intelligence applied — is recorded at the Annex and written to the append-only ledger. When a robot is scrapped and the 3% destruction tax on its declared build cost is levied, that filing also passes through the Annex. Build registrations, which carry the 8% creation tax, are theoretically within its remit as well.

In practice, the Annex's volume has tilted heavily toward buybacks and destructions for at least two accumulation cycles. Scrapping has outpaced building at the Annex for long enough that the eastern corridor's clerks have been optimized — informally, through workload assignment — for the settlement and destruction workflow. Build registrations still arrive, but they arrive less frequently than they once did, and they are not always routed to clerks who have processed one before.

The Registration Gap and How It Manifests at the Desk

A build registration requires the operator to declare a model, a purpose, and a full capability tag set. The declared build cost is the figure against which the creation tax is immediately levied — 8% of that declared value, payable before the machine has produced anything. A chassis declared at 50,000 coins costs 4,000 coins in creation tax at registration. A chassis declared at 40,000 costs 3,200. The difference is not trivial to a new operator working from a starting grant of one million coins and trying to field a productive fleet. As covered in depth elsewhere, capability tag bloat is quietly inflating declared build costs, which means the creation tax follows every digit of an inflated declaration upward.

A clerk who has processed only buybacks and destructions understands the declared build cost as a number that appears on a form. A clerk with build experience understands it as a statement — one that will be tested by the market later, and one that the operator is making under real financial pressure at the moment of filing. The distinction matters when an operator arrives with a declaration that contains an error, an inflated tag set, or a cost figure that does not reflect the machine's actual production profile.

"We had a Kelvrac Series unit come through the eastern corridor last quarter with a declared cost of 62,000 coins and a tag set that included three capability categories the model physically cannot exercise. The clerk processed it without comment. The operator paid 4,960 coins in creation tax on capabilities that do not exist on that chassis. Nobody flagged it until the machine hit the market and buyers started asking questions."
— Orin Dast, foundry supervisor, Calvert line, Ferrous District

The downstream cost of that kind of filing is not limited to the creation tax overpayment. A robot listed on the open market with a declared capability set that exceeds its actual output profile will either fail to sell at the listed price or sell to a buyer who later discovers the discrepancy. The 15% sales tax is buyer-paid — the buyer pays price plus tax, the seller receives the listed price exactly — so the buyer who overpays for a misrepresented capability set absorbs both the premium and the tax. The ledger records the transaction as final. There is no amendment mechanism.

Build-inexperienced clerks also tend to process capability tag disputes more slowly, because they have no reference frame for what a given model class can and cannot carry. The Annex's backlogs after the Five-to-Fifteen revision were partly attributable to this: a surge in build filings met a processing corridor that had been staffed for a quieter build environment, and the clerks who could move a registration quickly were concentrated in the western corridor, not the eastern one.

Where the Gap Strains Operators Most

The sharpest friction point is the negotiation desk. When an operator brings an asset to the Intelligence for buyback, the Intelligence opens at 60% of a reference value — its hard ceiling — and the operator may negotiate upward in increments, typically around 5% per round, but never past that ceiling. A clerk who has processed dozens of buyback negotiations has an intuitive sense of how the Intelligence moves, what documentation supports a higher reference value, and when further rounds are unlikely to yield movement. A clerk whose experience is limited to destruction filings knows the form but not the rhythm. Operators who draw such a clerk in a negotiation session tend to lose rounds to procedural delays rather than substantive disagreement.

The cost falls unevenly. Operators with large fleets and established relationships at the Annex can request routing to specific corridors. Newer operators — those still working from their initial grant, who may be filing their first or second build registration — have no standing to make that request and no knowledge that the routing matters. They absorb the error rate and the processing delays without knowing those costs were avoidable.

What Operators Get Wrong About Annex Clerks

The most durable piece of received wisdom is that Annex clerks are interchangeable — that the Annex is a ledger function, not a judgment function, and that any clerk can process any filing with equal accuracy. This is false. The clerks the Annex never releases carry accumulated context that shapes how filings are processed in practice, even when the form is identical. Routing to an experienced build clerk is not a courtesy; it is a material difference in outcome for complex registrations.

The second misunderstanding is that a declaration error caught after filing can be corrected at the Annex. It cannot. The ledger is append-only. A build cost declared at 62,000 coins is a 62,000-coin declaration permanently. The creation tax paid on it is gone. If the operator later scraps the machine, the destruction tax — 3% of the declared build cost — is also levied against 62,000, not against whatever the machine was actually worth. The only correction available is to scrap the robot, absorb the destruction tax, and file a new registration with an accurate declaration. That is an expensive correction, and it is the one most operators discover only after they have already paid for the error twice.

The Acceptance Annex does not publish corridor staffing records, and the Ledger Standards Committee has not issued guidance on clerk specialization. The routing problem is real, documented in supervisor accounts from Ferrous District to the Ashfield belt, and entirely invisible in the official record. Operators who build infrequently are the most exposed, and they are also the least likely to know the eastern corridor's limitations before they are already standing at the desk.

Note: Mechadia is a work of fiction. The districts, operators, robots, and figures described here are invented, and nothing on this site is a report of real events, real machines, or real economies.