At 6:40 on a Monday morning, a planner at an integrated steel plant notices that a customer order is beginning to drift. The order is not yet late. No alarm is flashing red. The shipment still appears to be inside the promise window.
But the planner knows something the dashboard does not quite express. One coil in the order has not completed quality clearance. A crane is unavailable in the dispatch bay. The customer has a narrow receiving slot, and the next available truck is already being considered for another shipment. The planner also remembers that this customer has accepted a split delivery once before, but only when the first truck contained the high-priority coils.
The planner makes a judgement call. A partial shipment is released, the remaining coil is rescheduled, and the customer service representative is asked to call ahead. The action protects the relationship and prevents a complete failure of the delivery promise.
Two weeks later, an analyst reviews the data. The system shows an order, a shipment, a revised shipment, and an eventual delivery. It does not show the reasoning. It does not show that the partial delivery was deliberate. It does not show which constraint mattered most, what alternatives were considered, or whether the customer’s response validated the decision.
The organisation has data. It does not yet have memory.
This distinction matters as manufacturing companies invest in analytics, copilots, machine learning, and agents. A large repository can tell us what happened. A decision-capable enterprise must also remember what people knew, what they did not know, what choices were available, why one choice was made, and what happened afterwards.
That is the purpose of a decision lake.
FAQ targets
By the end of this chapter, you must have answers to these questions:
- What does from data lakes to decision lakes mean for manufacturing leaders?
- How can organisations apply this idea in manufacturing?
- What role do people and governance play?
- How can success be measured?
The central argument
A data lake stores events, files, measurements, and transactions at scale. A decision lake stores the evidence and reasoning surrounding consequential choices.
The difference is not a new storage product. It is a design commitment. The organisation begins treating decisions as first-class operational objects rather than as invisible moments between system transactions.
A useful decision record may connect:
- the event that created attention;
- the operational context at that moment;
- the constraints that limited choice;
- the alternatives that were feasible;
- the recommendation or rule presented;
- the person or team with authority;
- the human decision, including an override;
- the action taken;
- the actual outcome;
- the confidence, assumptions, and explanation available at the time.
The practical test is simple: can the next planner, operator, maintenance engineer, or project manager use the record to make a better decision in a similar situation?
If the answer is no, the data may still be valuable for reporting, compliance, or historical analysis. But it is not yet serving decision intelligence.
A fresh perspective: the enterprise must remember its choices
Manufacturing organisations often describe themselves as data-rich and insight-poor. That is true, but incomplete. Many are also choice-poor in retrospect. They cannot reconstruct the decision landscape that existed when an outcome was created.
This creates a subtle organisational weakness. Every experienced employee carries a private library of situations: the customer who tolerates a split shipment, the product family that behaves differently after a maintenance intervention, the supplier whose confirmation is optimistic, the shift pattern that makes a theoretical schedule impossible in practice. Much of that knowledge remains in conversations, notebooks, messages, and memory.
When that person changes role or leaves the company, the transaction history remains. The judgement disappears.
A decision lake is therefore not merely an AI data foundation. It is an organisational memory system for practical reasoning. It gives the company a way to preserve optionality, assumptions, exceptions, and consequences without pretending that every decision can be reduced to a neat formula.
This perspective also changes how leaders should evaluate data programmes. The question is not only, “How much data do we have?” It is also, “Which important choices can we now understand, compare, and improve?”
Why data abundance still produces action scarcity
The modern plant may have thousands of tags, production records, quality results, work orders, transport updates, customer messages, and planning transactions. Yet a person making a decision at 3:00 in the morning may still be forced to ask three basic questions:
1. What is actually happening?
2. What can I do about it?
3. What will happen if I choose each option?
The data may exist, but it is scattered across systems with different clocks, definitions, identifiers, and ownership. A delivery promise is represented differently in the order system, the planning board, the logistics portal, and the customer service mailbox. A quality hold may appear as a status, a laboratory result, a note, and a verbal instruction. A capacity constraint may be technically visible but socially unusable because the shift cannot safely perform the proposed sequence.
The result is a familiar pattern. People spend time assembling a temporary picture before they can reason about action. Under pressure, they rely on memory and local workarounds. Later, the organisation evaluates the result without understanding the conditions under which the decision was made.
The decision lake addresses this gap by bringing evidence and meaning together around a decision episode.
The decision episode: the unit of useful memory
A transaction answers, “What record was created?” A decision episode answers, “What situation was someone trying to manage?”
Consider a maintenance intervention on a finishing line. The event may begin with vibration readings crossing a threshold. The context includes current production campaign, available spares, technician skill, customer priority, safety restrictions, and the planned maintenance window. The alternatives may include immediate shutdown, controlled operation until a planned stop, speed reduction, or inspection during the next changeover.
If the system stores only the work order, future teams learn that maintenance happened. If it stores the decision episode, they can learn why immediate intervention was or was not chosen, which evidence was persuasive, and whether the chosen risk was acceptable in retrospect.
A decision episode does not need to be a long essay. It can be a structured record supported by short human notes, system evidence, and automatically captured timestamps. Its value comes from consistency and linkage.
The decision episode should be created close to the moment of choice, when the situation is still understood. Reconstruction months later is often distorted by hindsight.
The Decision Lake Schema
The core framework for this article is the Decision Lake Schema. It is a practical minimum structure for capturing decisions without imposing a universal data model on every plant.
1. Event
What brought the situation to attention? It might be a predicted delay, a quality deviation, a breakdown signal, an order change, a supplier warning, a safety observation, or a project milestone at risk.
The event should include time, source, severity, and the relationship to the affected asset, order, material, customer, batch, or project.
2. Context
What else was true at the time? Context may include inventory, staffing, campaign, weather, customer priority, shift, maintenance status, open exceptions, and recent decisions.
Without context, an algorithm may learn that a particular action was associated with success while missing the conditions that made it appropriate.
3. Alternatives
Which options were realistically available? Listing alternatives prevents the record from becoming a post-hoc justification for the selected action. Options should include infeasible or rejected choices when they were seriously considered, together with the reason they were removed.
4. Recommendation
What did the system, rule, analyst, or colleague recommend? Record the recommendation as it was presented, including confidence, assumptions, and evidence. Do not overwrite an earlier recommendation when the model is later retrained.
5. Human choice
What did the authorised person choose? If the choice differed from the recommendation, capture the difference without labelling it automatically as an error.
6. Action
What was actually done? A decision that never reaches execution is not an operational decision. Link the record to schedule changes, work orders, dispatch instructions, purchase actions, or project interventions.
7. Outcome
What happened? Outcomes should be measured against the relevant objective, not merely against whether the immediate action was completed. Did the shipment arrive on time and in full? Did the intervention prevent damage? Did the quality release protect the customer and the plant?
8. Confidence
What was known, estimated, uncertain, or disputed? Confidence should describe the quality of the evidence and the stability of the situation, not create false mathematical precision.
9. Reason for override
Why did a person change, reject, or ignore a recommendation? Useful categories may include missing context, safety concern, customer knowledge, infeasible execution, policy conflict, timing, model error, or a deliberate risk trade-off.
The ninth field is often the most valuable. The most important data may be the decision someone changed.
What planner overrides are really telling you
An override is often treated as an exception to be eliminated. That response is understandable when teams are trying to automate a process. It is also dangerous.
An override can signal at least four different things:
- the model is wrong;
- the model is right about the signal but unaware of critical context;
- the recommendation is sound but impossible to execute;
- the human is taking a conscious risk that the model does not represent.
These situations require different responses. Retraining the model will not solve a missing approval route. Adding more sensors will not solve a customer relationship constraint. A new policy will not solve a recommendation that arrives after the truck has already left.
Imagine an order allocation model recommending that a coil be assigned to Customer A because the margin is higher. The planner assigns it to Customer B because Customer B’s line will stop without it, while Customer A has confirmed a flexible delivery window. If the system records only the override, the organisation may conclude that the planner is inconsistent. If it records the reason, the organisation learns that customer criticality and production impact were absent from the objective function.
The purpose of override capture is not to turn experienced people into training data without consent or context. It is to create a respectful learning loop in which the system can become more useful and the organisation can distinguish judgement from noise.
From prediction to action
Prediction is an important beginning, but it is not the value event.
A model may predict that a shipment has a high probability of missing its delivery promise. That statement is useful only if it arrives early enough, identifies the relevant order, explains the drivers, and supports a feasible response. The decision lake should connect the prediction to the choices that followed.
At the next level, a system can compare alternatives: expedite transport, split the order, change the production sequence, substitute inventory, renegotiate the slot, or accept the risk. Each option should show the operational consequences it is able to estimate.
At a higher level of maturity, the capability can prepare an action. It may draft a customer communication, reserve a vehicle, prepare a revised schedule, or create a maintenance work order for approval. Bounded execution may follow only when the action is reversible, within policy, and appropriately monitored.
The progression is not a race toward autonomy. It is a movement toward dependable action. A simple recommendation that a planner trusts may create more value than an agent with broad permissions that nobody is willing to rely on.
When an AI recommendation fails, ask:
- Was the event detected early enough?
- Did the system understand the decision’s real objective?
- Were the constraints current and complete?
- Were alternatives feasible in the physical operation?
- Did the recommendation explain its trade-offs?
- Did the correct person receive it with enough time to act?
- Was the action executed as intended?
- Was the outcome measured fairly?
These diagnostic questions turn failure into architectural learning.
Architecture for a decision lake
A decision lake should not become another large repository that nobody can explain. Its architecture should follow the flow of a decision.
Event and evidence ingestion
The first layer brings together operational events from ERP, MES, APS, quality systems, maintenance platforms, warehouse systems, logistics providers, documents, sensors, and human observations. The purpose is not to force every source into one format. It is to preserve provenance and establish shared identifiers for orders, materials, assets, customers, batches, and projects.
Semantic and context layer
This layer explains what the records mean and how they relate. It distinguishes a planned completion date from a confirmed dispatch date, a quality hold from a quality failure, and a forecast from a commitment. Context may be assembled dynamically for a particular decision rather than copied indiscriminately into every record.
Decision ledger
The decision ledger stores the episode itself: trigger, context, alternatives, recommendation, human choice, authority, action, outcome, and explanation. It should preserve versions. If a recommendation changes at 10:00, the 08:00 recommendation should remain available because it was the basis for the earlier decision.
Feature and model services
Feature stores and model registries can support prediction, but they must be connected to the decision record. The organisation should know which model version, features, thresholds, and policies influenced a recommendation.
Policy and authority registry
Not every person or agent can make every decision. A policy registry should define approval thresholds, safety boundaries, segregation of duties, escalation paths, and permitted actions. Authority should be visible at the moment of recommendation.
Outcome and feedback store
The loop closes when actual outcomes return to the decision lake. Was the promised delivery achieved? Did a changeover take as long as expected? Did the supplier recover? Did the customer accept the revised plan? This layer supports evaluation, learning, and honest calibration.
The architecture is therefore less like a warehouse of facts and more like a connected memory of operating choices.
Five manufacturing examples
Order balancing in steel
A steel plant must allocate constrained coils across customers with different promised dates, margins, contractual penalties, and operational requirements. A decision lake can preserve the trade-off behind an allocation, including why a lower-margin order received material because its customer had no substitute and a production line was at risk.
Quality disposition in automotive
A batch may be technically outside a preferred range but still usable for one application. The decision episode should connect laboratory evidence, customer specification, engineering judgement, approval, and downstream performance. This is more useful than recording only “released” or “rejected.”
Maintenance in mining
An operator may continue running equipment with increased monitoring because immediate shutdown would strand a crew and create a larger safety exposure during an unsafe weather window. The record must make the boundary conditions explicit and verify whether the chosen monitoring plan worked.
Supplier risk in pharma
A procurement team may accept a supplier delay because an approved substitute is available and the affected batch has sufficient safety stock. The decision lake can show whether the substitution was actually viable, whether quality approvals were timely, and whether the apparent resilience depended on a hidden buffer.
Project forecasting in aerospace
A programme lead may revise a completion forecast after an engineering dependency slips, even though the schedule tool shows float. The decision record can capture the dependency, the confidence level, the alternatives, and the intervention that ultimately protected or failed to protect the milestone.
Across these cases, the recurring question is not “What did the system calculate?” It is “What did the organisation choose, under which conditions, and what did it learn?”
Governance: memory must not become surveillance
Decision capture raises legitimate concerns. People may fear that every judgement will be used against them. A planner may stop recording useful context if an override is treated as proof of failure. A shift in-charge may avoid documenting uncertainty if the record is later interpreted without the circumstances that created it.
Governance must therefore define purpose and access. The decision lake should support operational learning, safety, quality, and accountability. It should not become an indiscriminate employee-monitoring system.
Useful safeguards include role-based access, retention rules, clear ownership, versioned records, explanation of how data will be used, and a distinction between coaching evidence and disciplinary evidence. Personal data should be minimised. Sensitive customer, employee, and commercial information should be protected according to local requirements.
The organisation should also establish a correction path. If a decision record is incomplete or misleading, the authorised participants should be able to add context without rewriting history. Trust depends on preserving the original record while allowing a transparent amendment.
A practical first decision lake
Do not begin by attempting to capture every decision in the enterprise. Select one recurring decision with visible consequences and a motivated owner.
A strong candidate has:
- a meaningful operational cost or customer impact;
- repeated frequency;
- enough existing evidence to start;
- human choices that materially affect outcomes;
- a safe environment for observation before automation.
Order promise recovery, quality disposition, maintenance prioritisation, and constrained material allocation are often suitable candidates.
Start with a lightweight template. Ask the decision owner to record the trigger, context, alternatives, choice, action, and outcome. Integrate system evidence gradually. The first version can be imperfect as long as its limitations are visible.
The early objective is not model accuracy. It is learning whether the organisation can describe its decisions consistently. If people disagree about what the decision was, who owned it, or what success meant, the data-lake problem is actually an operating-model problem.
A ninety-day implementation sequence
Days 1–30: listen before designing
Interview planners, schedulers, operators, quality teams, customer service, maintenance, logistics, and managers who live with the decision. Ask them to describe the last difficult case, not the ideal process.
Questions should include:
- What tells you that this decision needs attention?
- What information do you search for first?
- Which constraints are not visible in the official system?
- Which option do people usually avoid, and why?
- When do you override a recommendation?
- What happens after the decision is made?
- How do you know whether it worked?
The goal is to discover the practical decision, including workarounds and invisible dependencies.
Days 31–60: capture episodes manually and connect evidence
Create a small decision ledger for real cases. Link orders, assets, batches, schedules, approvals, and outcomes where possible. Define a short override taxonomy. Resist the urge to add dozens of fields; the record must be usable during a shift.
Review the first episodes with participants. Ask whether the record reflects their reality. If it does not, fix the schema before adding automation.
Days 61–90: introduce decision support in observation mode
Provide recommendations without automatic execution. Compare the recommendation with the human choice and the eventual outcome. Study disagreements respectfully. Look for recurring missing context, infeasible actions, delayed alerts, and unclear authority.
At the end of ninety days, decide whether the use case is ready for stronger support. The evidence may justify a better model, a new policy, improved master data, a workflow change, or no automation at all.
Measures that matter
Decision-lake success should not be measured only by records ingested or dashboards created. Consider:
- time required to assemble decision context;
- percentage of decisions with explicit alternatives;
- quality and usefulness of outcome capture;
- recurring override categories;
- recommendation acceptance with outcome quality;
- time between event, decision, and action;
- number of decisions that can be reconstructed;
- reduction in repeated avoidable surprises;
- user confidence and perceived fairness.
These measures reveal whether the capability is helping people act, learn, and improve.
Questions for leaders
- Which recurring decision creates the most avoidable value leakage?
- Where is important context currently held only in people’s memories?
- Can we distinguish a bad recommendation from an impossible recommendation?
- What does a good outcome mean for this decision?
- Which human overrides are signals of missing design rather than resistance?
- Who owns the decision, the data, the policy, and the learning loop?
- What authority can safely be delegated, and what must remain human?
- Are we building organisational memory or merely collecting more exhaust?
Conclusion: remember the reasoning, not only the result
Manufacturing organisations do not become intelligent because they accumulate more data. They become more intelligent when they can use evidence, context, and experience to make better choices repeatedly.
A data lake tells the organisation what passed through its systems. A decision lake helps it remember what people were trying to protect, what they were willing to trade, which alternatives were available, and whether the choice worked.
That memory is especially valuable when experienced people are unavailable, conditions change quickly, or AI systems begin recommending actions at scale. Without decision context, automation can repeat the same blind spots faster. With decision context, disagreement becomes a source of learning, exceptions become visible, and recommendations can improve without erasing human accountability.
The first decision lake does not require a grand transformation programme. It requires one important decision, one honest group of practitioners, a small schema, and the discipline to follow the outcome to the end.
Clean data is useful. But useful decisions are the finish line.
Disclaimer
Industry situations in this chapter are composite illustrations unless explicitly attributed to a public source. They are not claims about any particular company, plant, vendor, or incident. A decision-lake implementation must be validated against local safety, quality, cybersecurity, regulatory, contractual, labour, privacy, and data-governance requirements. AI recommendations should remain within clearly defined human authority and operational controls.
#DecisionLake #DataLake #DecisionIntelligence #ManufacturingAI #EnterpriseMemory #OperationalLearning #IndustrialData #SmartManufacturing #AIArchitecture #DigitalTransformation
