The Smallest Unit of Learning

At Cask we built data infrastructure for a living, which means I spent years professionally close to a seductive idea: capture everything, sort it out later. Our platform could ingest anything a company emitted. Events, logs, clicks, transactions, the full firehose. I have watched enterprises stand up petabyte lakes with the confidence of people building a library of Alexandria.

And I will tell you what I learned watching those lakes fill: more exhaust is not more knowledge. The companies that captured the most were rarely the companies that learned the most. Something between the capturing and the learning was missing, and it took me until the AI era to name it. The missing thing was a unit. Chemistry got nowhere until it had the atom. Genetics got nowhere until it had the gene. Organizational learning has been stuck at "let's do a retro" because nobody agreed on what the atom of experience is.

Part 1 of this series argued that enterprises need the learning properties of the coding loop: state, intent, decision, action, result, comparison, adaptation. This part is about the data structure that makes those properties real. Academic process-mining research backs the intuition that this is where the pain lives: raw operational data must be identified, extracted, aligned, and interpreted before it means anything, and prior estimates put that pre-analysis work at up to 80% of the effort in process-mining initiatives.¹ The problem is not recording. The problem is representation.

So the question is not "can we record everything?" It is this: can we convert messy observations into an economical representation of state, intent, decision, action, and outcome without destroying context or human trust? That is a much more tractable problem, and it starts by rejecting three tempting fundamental units.

Not the document: documents record conclusions, not choices. Not the meeting: meetings are where decisions hide, not where they are structured. And not the click: I will come back to the click, because the click is a trap with a product category built on top of it.

The fundamental data structure should be what I call a Decision-Outcome Graph: a set of linked, hierarchical decision episodes anchored to real enterprise objects. A decision episode is not necessarily a big executive decision. It is the smallest unit at which there is enough meaningful choice and observable consequence to learn something useful.

Three real-shaped examples. A support case approaches its SLA; the agent decides to escalate to tier two; sends a diagnostic summary and reassigns; the specialist accepts within twelve minutes; the customer gets an answer; the case closes without reopening. An enterprise prospect raises a security concern; the salesperson decides to bring a security architect into the next call rather than send documentation; the meeting happens; the objection clears; procurement starts fourteen days later; the deal eventually closes. A production alert fires; the operator infers a faulty deployment rather than infrastructure failure; chooses rollback; error rates fall within four minutes; the service recovers; the incident never recurs.

These are learnable trajectories. A strategy deck is not. A keystroke is not. The episode is where choice meets consequence at a scale reality can grade.

For each consequential episode, I would capture ten fields:

This is not an industry standard; it is my synthesis of what process mining, object-centric process modeling, task mining, decision-centric architectures, and agent observability are all converging toward. And one word in that synthesis matters more than it looks: object-centric. A sales "case" might be an opportunity, but one sales decision touches an account, a contact, a product, a contract, a security review, a legal issue, and maybe a channel partner. Real enterprise processes form graphs, not clean linear workflows. Microsoft added object-centric process mining precisely because forcing every event into one case identifier hides the relationships between orders, invoices, deliveries, and payments; Palantir's architecture treats enterprise objects as nouns, actions as verbs, and keeps decision lineage.²³

Now the trap. If every click can be captured, should every click become a training event? Task-mining products prove the capture is possible: commercial tools record mouse clicks, keystrokes, hotkeys, and screenshots of real desktop work.⁴ The engineering me of twenty years ago would have found that irresistible. The operator me knows better, because at click granularity three things break at once.

The signal-to-noise ratio collapses: moving between two browser tabs is rarely an economically meaningful decision. Attribution becomes impossible: a six-month sales outcome cannot reasonably be assigned to a mouse click five months earlier. And pervasive capture rapidly starts to look like employee surveillance rather than process learning, which researchers studying process-mining adoption report as a real source of distrust.¹ The right resolution is hierarchical:

Business outcome
  └─ process / case
      └─ phase
          └─ decision episode
              └─ actions
                  └─ raw events

Keep the low-level exhaust for reconstruction where lawful and appropriate, but train and evaluate at the level of meaningful state transitions. This is the same reason long-horizon agent systems benefit from intermediate subgoals instead of one terminal reward: a three-month revenue result is too sparse to teach every preceding action. The intermediate outcomes are the analog world's partial test results: objection resolved, next meeting scheduled, approval received, ticket reopened, escalation accepted, invoice exception cleared, forecast changed, rework requested.

One more trap before the cliff. Defining a single enterprise reward is how you build a fast support team whose customers call back two days later, a procurement agent that lowers price while raising supplier risk, or a sales agent that maximizes win rate by giving away margin. The test suite needs dimensions: speed, quality, cost, revenue, risk, customer effect, employee effect, reversibility. Different workflows weight them differently. The analog enterprise rarely has one truth function. It has trade-offs.

The closest practical equivalent of a test suite is therefore an outcome contract attached to a process: an explicit statement of what good looks like at several horizons.

Immediate: error rate normal
1 hour:  service stays stable
24 hrs:  no recurrence
7 days:  root cause complete
30 days: corrective fix shipped
Always:  no security breach

Now a human or agent action can be tested against something real. Which raises the question this whole architecture lives or dies on: the analog world does not hand you clean episodes. Intent is invisible. State lives in hallways. Outcomes arrive months late, tangled with luck. At DataRobot I watched the best predictive models in the world walk into exactly this mess, and what the mess did to them changed how I think about all of it.