Decisions and Decision Value Loops

Two concepts carry most of mDecide: the decision record, which is what the platform keeps, and the Decision Value Loop, which is the rhythm it keeps it in. This page defines both, and draws the line between a loop and one pass through it — a distinction that shows up everywhere else in the product.

The decision record

A decision record is a single durable entity holding everything about one decision:

• Context. What was being decided, by whom, by when, with what at stake.
• Alternatives. The options that were on the table, not only the one chosen.
• Evidence. The materials that informed the choice, each with its own traceable origin.
• The choice. Which option was selected, by which person, and their reasoning.
• The projection. What the decision was expected to produce.
• The outcome. What was actually observed, once it became measurable, and how far it diverged from the projection.
• The trace. A phase-by-phase account of how the decision was reached.

The record is queryable, versioned, and portable. A decision can be revisited: an amended decision supersedes the earlier one, and both are retained. A large decision can carry smaller ones beneath it, so a strategic call and its tactical consequences stay connected.

Two things a decision record is deliberately not:

• It is not chat history. A message stream records what was said. It holds no alternatives, no projection, and no outcome.
• It is not an audit log. An audit log records what happened. It does not hold what was considered and rejected, or what was expected.

Decision states

A decision moves through a small, explicit set of states.

What a Decision Value Loop is

Decisions of consequence rarely happen once. They recur: information arrives, options are weighed, a call is made, work is dispatched, results accumulate, and the next decision is shaped by the last. mDecide names that recurring rhythm the Decision Value Loop (DVL) and treats it as a structure you configure rather than a process you re-describe every time.

A DVL has five phases.

The Learn phase is the part that makes the rest worth doing. Without it, the accumulated record is history. With it, every measured outcome informs the next cycle: what to watch for in Sense, which analysis to weight in Analyze, which judgments have evidence behind them in Decide. A Learn phase produces three kinds of finding — the metrics tracked across the cycle, root-cause hypotheses for whatever diverged from projection, and predictive findings carried into the next cycle.

Each of the three words is doing work. Decision keeps the focus on the unit of value rather than on “data analysis” or “AI workflow.” Value ties the loop to a measured outcome; a loop with no outcome capture is a workflow. Loop commits to the recurrence — mDecide is not a one-shot recommendation engine, it is a structure that improves at a class of decisions over time.

Which decisions suit a DVL

The pattern fits a recurring operational decision that:

• draws on data from several enterprise systems at once;
• requires synthesis across objectives that compete;
• carries measurable financial consequence each time it is made;
• recurs on a predictable cadence — daily, weekly, monthly.

Well intervention selection, pipeline integrity prioritization, manufacturing changeover sequencing, pharmaceutical batch release, covenant monitoring, and restaurant food-cost management are all decisions of this shape.

Decisions that do not fit: one-off strategic choices with no recurrence, and high-volume decisions already fully determined by a rule. The first has no loop to compound; the second does not need synthesis.

Loops and cycles are different things

This is the distinction to hold onto:

A DVL is the loop definition — configured once, for a class of decisions. A DVL Cycle is one pass through that loop’s five phases.

The definition holds what is stable about the decision type: what to sense, how to evaluate alternatives, when outcomes become measurable and what variance is tolerable, what to learn. A cycle holds what is specific to this pass: the phases it has moved through, the approvals it required, the evidence it assembled, the decisions it produced, and what it cost.

Cycles are the unit of measured work. Each carries per-phase cost — model spend, human time, elapsed time, agent invocations, tool calls — which is what makes it possible to report a cost per decision rather than a cost per platform.

A cycle usually produces one decision, but it need not: a cycle can carry several related decision records. And a single cycle may be completed by one span of agent-led work or composed from several, including more than one within a single phase. The cycle is the accounting boundary, not a constraint on how the work is organized.

Evidence, lineage, and outcome attribution

Everything a decision rests on carries a traceable origin. The unit of contribution is the Decision Material — a frozen dataset, document, chart, workbook, or report that has been explicitly bound to something a phase must satisfy before it can close. A material carries its own lineage: which data products it was derived from, which source systems those reached into, which agents and which people produced it, and what it cost to produce.

Lineage runs in both directions, using one vocabulary of named relationships (derived from, incorporates, supersedes, rendered from, and others — a shape drawn from the OSDU lineage-assertion conventions). Upstream, a material points back at what produced it. Downstream, once the Learn phase observes an outcome, that outcome points back at the materials that informed the decision.

That second direction is outcome attribution, and it is what turns evidence into a measurable contribution. Without it, a material is “something that informed a decision.” With it, the material carries a share of the result, and over many cycles it becomes visible which sources of analysis actually move outcomes and which are consulted and ignored.

Lineage is not bookkeeping for its own sake. A decision with no traceable evidence cannot be defended to an auditor, cannot be improved, and gives the Learn phase nothing to attach an outcome to.

Where to go next

• Decision Packs — how a configured loop, its agents, and its domain knowledge are packaged and deployed.
• Workstreams and phases — how the work inside each phase is organized, and what a phase gate checks before a cycle advances.
• Tour of one decision cycle — the same concepts followed end to end through a single decision.