In short: At ten thousand people, there is finally enough volume in enough decision classes for a learning layer to earn its keep. The challenge is no longer whether to record judgment, but how one organisation runs many records without forcing them into one.
Key points
- Scale makes calibration, staggered rollouts, seeded errors and cross-division precedent practical.
- Single-ontology programmes tend to stall because divisions have different meanings, regulators, data and speeds.
- Set centrally: decision, reason, falsifier, sources and outcome on every record; supersede, never overwrite.
- Map local definitions to a short enterprise glossary rather than replacing them.
- Data and analytics firms run two brains: the internal decision record and the external context layer clients' agents consume.
A large enterprise makes thousands of comparable decisions a week in dozens of classes: credit approvals, alerts, claims, renewals, procurement, hiring, pricing. Outcomes arrive on a known schedule. Experts handle the exceptions. Someone will have to defend the calls. This is the zone where judgment systems genuinely learn, and where the measurement discipline in the rest of this series pays off.
What becomes possible
Calibration at scale. Enough outcomes per class to see, within a quarter or two, where judgment is overconfident and who reads which situations well.
Staggered rollouts as standard. Every change to a decision workflow deployed in waves, so each wave is the control for the next.
Seeded errors and second looks across every review queue, with catch rates reported like any other control.
Precedent across divisions. A credit officer in one region seeing how a comparable case was handled in another, with outcome.
The federation problem
The tempting response is one enterprise brain: a single ontology, a single definition of every term, a single store. These programmes tend to stall. Divisions have legitimately different meanings for some terms, different regulators, different data, and different speeds. Forcing them into one model takes years and produces a compromise nobody uses.
The workable design is federated.
Set centrally: the invariants. Every record has a decision, reason, falsifier, sources and outcome. Supersede, never overwrite. One trace specification. One export format. A short enterprise glossary for the terms that cross divisions: revenue, customer, exposure.
Kept locally: the records themselves, owned by the functions. Local definitions where they genuinely differ, mapped to the enterprise terms rather than replaced by them. Local decision classes and templates.
Bridged: a map between local and enterprise definitions, and a conflicts process for when they diverge. Map, do not unify.
The data provider's two brains
One nuance applies to firms whose product is itself data and analytics. They run two brains: the internal one that records how the firm decides, and the external one they sell, the context layer their clients' agents consume. The two can reinforce each other. A provider that helps clients keep a structured, exportable record of how they used its data is selling the start of a judgment layer, not just cargo. That may be the most interesting product opportunity at this scale.
In practice
- Publish the central invariants and the export format; leave records with the functions.
- Map local definitions to a short enterprise glossary instead of replacing them.
- Make staggered rollout and seeded errors standard for every decision workflow change.
- Report calibration for the five highest-volume decision classes quarterly.
What would prove this wrong. Large enterprises that deploy a single unified ontology across all divisions on schedule, with high adoption, outperforming federated designs.
Common questions
Should a large enterprise build one unified knowledge graph or ontology?
Usually not. Single-ontology programmes tend to stall and produce a compromise nobody uses. A federated design, with central invariants and local records mapped to a short enterprise glossary, is more workable.
What should be standardised centrally in an enterprise decision record system?
The invariants: every record has a decision, reason, falsifier, sources and outcome; records are superseded, never overwritten; one trace specification, one export format and a short glossary for cross-division terms.
Why do decision-learning systems work better in large companies?
Large enterprises make thousands of comparable decisions a week with outcomes on a known schedule, giving enough volume per class to see where judgment is overconfident.