The category nobody named yet

The most expensive mistake in judging a market is to mistake a category for a feature. It is expensive because it is so reasonable. Categories do not announce themselves. They begin their lives as a small capability bolted onto something else, a line item in a product that is really about something more legible — and for a while the dismissal is correct. A feature really is all it is. The mistake is not seeing the feature; the mistake is failing to notice the moment the need underneath it grows large enough, and general enough, that no single product can keep containing it. That is the moment a feature becomes a category, and it almost always happens before anyone has agreed on a name for it.

The pattern is worth stating plainly because it has repeated so many times that it is nearly a law. Consider the infrastructure layers a modern company now takes for granted. Observability began as a logging feature inside individual applications — every team rolled its own, and the idea of a dedicated layer for it would have sounded like overhead. Identity began as a login screen, a table of usernames and passwords each application kept for itself. Security began as a setting. Data warehousing began as "we'll just query the production database." Payments began as a checkout form. In every case the capability was, at first, correctly understood as a feature of some other product — because the underlying need was still small enough to be met that way. And in every case the need eventually outgrew that arrangement, became something that cut across every application rather than living inside any one of them, and forced a dedicated layer into existence. What had been a feature everyone built badly for themselves became a category someone built well for everyone.

Why accountability follows this pattern now

Decision accountability — the ability to reconstruct, defend, and contest a consequential automated decision — is following exactly this arc, and it is following it right now. Today it is still mostly seen as a feature: a compliance checkbox, an audit-log toggle, a reporting tab somewhere inside a larger platform. Each vendor treats "and it keeps a record of what it did" as a minor attribute of the product that makes the decision. That reading is not stupid. It is the same reading that was correct about logging in 2005. It is correct right up until the volume and the stakes of automated decisions cross a threshold — and that is the threshold we are crossing.

The engine of the change is the shift from software that advises to software that acts. For most of computing's history, the consequential decision was made by a human who happened to use a machine along the way; the software recommended, and a person chose, and the person was the accountable party. Agentic systems collapse that arrangement. When software moves from advising to acting — approving, denying, pricing, routing, escalating, allocating, on its own authority and at machine speed — the number of consequential decisions made without a human in the loop does not grow linearly. It explodes. And each of those decisions inherits the same obligation the human decision always carried: to be explicable, defensible, and reviewable after the fact. The obligation does not disappear because a human stepped out of the loop. It multiplies, and it detaches from any single application.

That detachment is the whole point. When one system in your stack makes a thousand decisions a year, accountability can plausibly be a feature of that system. When forty systems each make a million, the need to account for a decision stops being satisfiable one product at a time. The affected party does not care which vendor's model denied them; they want an account. The regulator does not audit per-application; they ask whether the institution can answer for its decisions, wherever they were made. The requirement has gone horizontal. It now runs across the whole estate of decisions rather than sitting inside any one of them — and a horizontal requirement met by vertical, per-app features is a requirement met unevenly, incompatibly, and therefore not really met at all.

A feature is something one product adds; a category is something every product needs and none can own alone — and accountability is failing the first test and passing the second.

The tell that it is a category

There is a reliable way to tell whether you are looking at a feature or a category, and it does not depend on how big the current line item is. It depends on three properties, and decision accountability has all three.

The first is that the demand comes from outside the vendor. A feature is something a customer asks the vendor for. A category is something demanded by parties who are not the vendor and not even the customer — regulators who will require it, courts that will subpoena it, insurers who will price it, and the affected people who will contest it. When the pressure to account for a decision originates with everyone standing outside the transaction rather than with the buyer inside it, you are not looking at a product preference. You are looking at a structural obligation that no vendor can define away, because the vendor does not control the parties imposing it.

The second is that it is cross-cutting. A feature is domain-specific; it makes one product better at one job. Accountability is indifferent to domain. A lending decision, a hiring screen, a benefits determination, a content takedown, a diagnostic recommendation — these have nothing in common at the level of subject matter, and everything in common at the level of what accountability requires of them. Every one needs the same things: a record of what evidence was actually consulted, the rules that were in force at the time, provenance for the inputs, and enough preserved state to run the decision again and see whether it holds. When the same requirement recurs identically across domains that share nothing else, the requirement belongs to a layer beneath all of them.

The third is that it has a natural interface that wants to be standardized. Categories crystallize around an object. Identity has the token; observability has the trace; payments have the transaction record. Decision accountability has the decision record — the account of a single consequential decision, structured so that it can be examined, replayed, and contested by someone who was not present and does not trust the system that produced it. Once such an object exists and proves useful, it stops wanting to be proprietary. The affected party, the auditor, and the court all need to read it, which means it needs to mean the same thing everywhere. An interface that everyone outside the vendor needs to read is an interface that wants to be a standard — and a standard is the connective tissue of a category, not a feature.

What getting this wrong costs

Feature-versus-category is not a matter of scale or ambition. It turns on a single question: can the need be met, well, one product at a time? If it can, it is a feature, however large. If it cannot — if meeting it requires something that lives beneath the products and serves them all — it is a category, however small it looks today. The decision record is like double-entry bookkeeping or the shipping container: valuable precisely because it is the same everywhere, worthless if every party keeps its own incompatible version.

Which is why treating accountability as a per-app feature is not a harmless underinvestment; it is a way of guaranteeing the cross-cutting need goes unmet. If every system logs its decisions in its own shape, to its own standard, retaining its own idea of what matters, then the estate-wide question — can this institution account for the decisions it made? — has no estate-wide answer. You get a thousand honest local records that do not compose into one defensible whole. The affected party still cannot contest across systems; the regulator still cannot audit across them; the institution still cannot stand behind them together. The concepts this account is built from — the decision record, admissibility, provenance, standing, the ability to replay — are not one vendor's product line. They are the shape of a category: the horizontal layer that has to exist once decisions are made faster than humans can make them and consequences still attach to every one.

Nobody has finished naming it yet. That is not evidence against its existence; it is the ordinary condition of a category in the year before everyone agrees it was obvious. The features are already shipping, dismissed as checkboxes. The outside pressure is already arriving. The interface is already trying to standardize. All that is missing is the recognition — and recognition, in categories as in everything else, is the last thing to show up and the first thing that pays.

— Dispatches · Summit Cognitive