There is no buyer

Every query the feature needed began “for this buyer”, and the only buyer-shaped predicate in the codebase was a case-insensitive substring regex behind a list filter, already wired end to end, from a query parameter in the browser client through to the repository.

That filter is correct as what it is: a search box. As an identity function it fails in both directions. It splits one buyer into many, because an acronym and the full legal name behind it share no substring. And it merges buyers that are not the same, because any short name that is a prefix of a longer, unrelated organisation’s name matches it, which in a dossier means listing another company’s tenders as this buyer’s history.

The dangerous part is that it was the path of least resistance. Reusing it required writing no new query at all, so the wrong turn was available to anyone who never asked whether the existing filter was an identity function.

Store a normalised key on the bid and match on equality, never on a substring. A small buyer collection keyed on that value, created lazily on first view, holding the alias list, because aliases are the whole problem and there is nowhere else to put them, and per-bid copies of buyer facts are how three bids end up with three drifting versions of the same knowledge.

Two deliberate limits. Aliases are added by hand, by whoever notices the duplicate: automatic entity resolution over a few hundred bids is solving a problem that does not exist yet, and its failure mode is silently merging two real buyers. And the key is re-derived when the customer name is edited, not only stamped on create. The name is editable, and a stale key is a bid that silently drops out of its own buyer’s history.

A normaliser already existed and shipped, doing whitespace collapse and case-insensitive matching, backing the customer field on both the content library and the reference register. The new buyer key needed punctuation and legal-suffix stripping and alias resolution on top. The obvious move is to make the new one a superset and compose it over the stored value.

A superset is right, and composing it at query time is not a query. Both of those collections normalise on write and keep the original spelling, and they match it with an anchored case-insensitive comparison. So “normalise the stored value, then compare” means loading every content-library document and every reference on each page load and normalising in application code, which is the exact scan the identity model exists to remove, reintroduced on two more collections.

The same trap has a second door: the reference register’s own search filter is an unanchored substring regex, which is the collision bug of exhibit 1 on a different collection.

Keep both representations on the buyer record, and be explicit about which store consumes which. Aliases are normalised keys, and they are what the keyed collections match on. Spellings are the observed original spellings, the display name plus whatever each alias was typed as, and they are what the two spelling-keeping collections match on, as a set of anchored patterns, which is a clause those repositories already build.

That also keeps the human action singular: whoever adds an alias supplies the spelling they saw. One action, two representations, rather than two alias mechanisms to keep in step.

Two report types already existed on a bid: one model call over that bid’s tender index, persisted, with tender-scoped citations, a generation job, a status endpoint and a card state machine. The obvious implementation is a third one.

It fits none of that. This dossier’s provenance is record links, meaning bids, documents and register entries, and the citation scopes on the existing reports are all search indexes. But the deciding argument is staleness, and it is a structural one: this artefact changes when a different bid changes. Persist it and it is silently wrong the moment a colleague closes out another deal for the same buyer, and nothing in the system would know to regenerate it.

Computed per request, it is always current, and the entire apparatus disappears: no generation job, no template type, no status polling, no stale badge. The card navigates. It never says Generating….

The address had the same shape of error in the first version of my own plan, which specified the dossier under the bid. Nothing on the page is a fact about this tender; it is all facts about the buyer. Hang it off a bid and three bids with the same buyer produce three URLs rendering identical pages, with the notes and aliases stored against whichever bid someone happened to be looking at, so saving a note from one leaves it invisible from the others. It also cannot be reached before a bid exists, which is exactly when someone wants to look a buyer up.

A read model at a buyer-level address, linked from the bid card. Same query, same blocks, same permission: a choice of address rather than a bigger build, and five minutes now against a URL migration later. The rejected report type is written down with its full cost: a generate handler, a status handler, a template branch, a repository case and a card state machine, to deliver a page that is a database query.

“What we answered for them” sounds like a count. Three separate facts about the data model make the obvious count wrong, and they are only visible if you go and look.

One workbook is sixteen documents. A returnable parent copies the bid’s customer name, and every sheet copies the parent’s name and its bid id. So a fifteen-sheet workbook matches a naive count sixteen times, and the honest-looking sentence “we answered forty-seven questionnaires for this buyer” can be three workbooks.

A missing bid link means “shared with everything”, not “orphaned”. Reusable-answer provenance is declared on the model and written by none of the five import or creation paths. And the repository treats a nil bid id as globally shared, so the obvious provenance query does not return nothing. It returns the entire corpus, labelled as this buyer’s answers. That is a confidentiality problem wearing a wrong count’s clothes.

The early-engagement work is not reachable through bids. A questionnaire carries its own customer name, deliberately independent of any bid, and is routinely answered before a bid exists. A dossier that walks only bids omits exactly the work the block is meant to surface.

Exclude returnable sheets and count parents, as the returnables screen already does. Cut the reusable-answers block to a labelled empty state rather than ship a query that is wrong in the worst direction, with the provenance stamping named as a prerequisite ticket rather than a nice-to-have. Add the key to bid-less questionnaires only, and match the attached ones by bid id instead: a questionnaire under a bid has its customer name copied from that bid, so keying it too would create a second source of truth that goes stale on rename. Splitting on that makes the two branches disjoint by construction, so the union needs no deduplication pass.

Then bound the whole thing. Every repository read on the collections involved took a single bid id, so the dossier as first sketched was a per-prior-bid fan-out. The fix is set-membership variants plus projections, a cap on prior bids shown newest-first, and logged truncation, so “3 prior bids” never silently means three of eleven.

The hand-written half of the page is the half worth opening: relationship state, named people and roles, the incumbent and competitive read, how this buyer buys. All of it already exists, in kickoff decks. Rather than build an upload control, reuse the content-library upload that exists: tag the deck to this buyer and the page reads whatever is tagged. One upload, two payoffs.

The set of content classes withheld from the answering lane is exactly two, and the comment above it says plainly that a file with no class tag is not withheld. So a kickoff deck tagged only with a customer name is chunked, indexed and retrievable by the answering lane, and that deck is the single worst document in the corpus to make quotable. Its weaknesses column is our weakness, not the buyer’s, and its margin notes are working shorthand about the buyer written for an internal audience. A citation puts either in front of a customer.

The cheapest step in the plan turned out to be the one whose failure mode is a buyer reading our competitive read on them.

The reuse stands, but the upload is not the bare existing flow. Withhold-from-answering is not optional on this path, and it is a checklist item with a test: upload a deck for one buyer, then run answering on an unrelated bid and confirm no chunk of it is retrieved or cited. And the retag case is covered explicitly. If a deck goes up un-withheld and is flipped afterwards, the cached answers derived from it must be invalidated, or a source that has been withdrawn keeps being served from cache.

The AI half is deliberately narrow. Drafting the knowledge fields from a deck is suggest-then-confirm: editable unsaved values, nothing written to the record without a human saving it, never re-run over a field that already holds a human-entered value, and only ever over the one document the user picked. No background crawl of everything findable about this buyer. An LLM reading a deck densely packed with shorthand and judgement calls will produce fluent, plausible, wrong values, and a suggestion a human deletes costs nothing while a silent auto-fill costs the correction nobody knows to make.