From Event to Economic Outcome: The Causal Chain by Business Object
By Equipo Quantum Developers
Summarize:
Operating thesis
A trace ID shows that technical operations belong to one execution. It does not prove a decision caused an outcome or that the outcome produced economic value. A defensible claim needs five links: event → decision → action → operating outcome → economic outcome. They must join by object, preserve provenance, and state where observation ends and attribution begins.
The W3C PROV-O ontology provides concepts for describing entities, activities, agents, and derivation relationships. It does not define automation ROI, but it supplies an essential discipline: record what an activity generated, which entity it used, and who was associated. That structure prevents a final number from becoming detached from the facts that produced it.
The object as the spine
A business object is the stable identity crossing systems: invoice, shipment, quote, order, or case. It is not a file or API call. It may have versions and relationships, but retains a governed business key.
Every chain record includes:
- business_object_type and business_object_id;
- object_version and known state;
- correlation_id for execution;
- source occurred_at and observer recorded_at;
- source_system, owner, and evidence reference;
- schema_version for later interpretation.
OpenTelemetry maintains semantic conventions that provide common names for traces, metrics, and logs across technologies. The enterprise can extend that principle to objects and decisions. Do not replace native state: preserve the original value and normalized translation.
Link 1: event
An event is an observed change or signal, not a conclusion. Minimum fields are:
| Field | Purpose |
|---|---|
| event_id and event_type | identity and controlled vocabulary |
| object_id and object_version | state observed |
| occurred_at and source_clock | time and temporal authority |
| source_system and source_ref | verifiable provenance |
| payload_hash or artifact_ref | evidence without copying sensitive data |
| freshness_status | whether the signal was current at decision time |
| ingestion_status | complete, late, duplicate, or corrected |
“Likely delay” should not be an event when it already contains inference. The event might be “ETA changed”; the later decision determines whether intervention is needed.
Link 2: decision
The decision transforms events and policy into a recommendation or choice:
- decision_id and used event references;
- object state and version;
- decision_type, alternatives, and selected option;
- policy, rule, model, or prompt version;
- known limits and omitted evidence;
- confidence band, without treating it as probability of correctness;
- proposing agent, reviewer, and approval;
- exception reason and eligible population.
A material input change creates another decision. Do not overwrite the first one; the sequence explains why the answer changed.
Link 3: action
An action is an attempt to change the world. Record:
- action_id, decision_id, and intent;
- destination system and permitted operation;
- executing identity and permission;
- approval and preconditions;
- idempotency key;
- dispatch time and state: requested, confirmed, failed, or uncertain;
- native reference and available compensation.
An accepted decision is not a completed action. A sent command is not a confirmed result. This separation prevents value from being credited to commands that never arrived or executed twice.
Link 4: operating outcome
The outcome appears later and belongs to the process: resolved case, posted invoice, confirmed margin, closed exception, or intervention inside its window. Fields include:
- outcome_id and related actions;
- metric definition and version;
- value, unit, denominator, and segment;
- observation period;
- confirming system;
- final state and reopening;
- coverage: how many actions have observable outcomes;
- applicable baseline or comparison.
The outcome may contradict the action. A quote sent quickly can lose margin; a correct alert can arrive after the intervention window. The chain preserves both facts.
Link 5: economic outcome
Economic translation needs a separate rule:
- type: cash, avoided cost, used capacity, or mitigated risk;
- source operating outcome;
- unit value and finance source;
- realization rate;
- complete incremental cost;
- period and accounting entity;
- uncertainty range;
- validating owner;
- attribution status.
Do not count released capacity as savings without reduced cost or reassignment to measurable work. Do not convert hypothetical risk into realized cash.
Label the strength of the claim
Use four levels:
- Observed: events and outcomes exist, without a relationship claim.
- Linked: the chain shares an object and plausible timing.
- Compared: a baseline or cohort shows a difference.
- Attributed: the evaluation design supports incremental effect.
The UK Treasury Magenta Book explains that impact attribution requires estimating what would have happened without the intervention. A perfect event pipeline improves traceability, but it does not create causality by itself. The evidence level travels with the KPI.
Illustrative example: a shipment exception
An event records an ETA change from a current source. The agent decides the delay threatens a window and proposes alternate expediting. A person approves; the action creates a TMS request and receives a reference. The operating outcome confirms delivery inside the window. Finance validates added cost and compares with the contracted alternative when estimating value.
The chain permits several conclusions. Without a comparison, delivery is observed and linked, not an attributed benefit. If the action failed but delivery occurred anyway, the agent receives no credit. This example contains no benchmark and claims no actual savings.
Artifact: the causal envelope by object
The envelope contains IDs for the five links, versions, source, coverage, and claim level. One query should answer:
- which event opened the case?;
- what information and policy supported the decision?;
- which action did the destination confirm?;
- when did the outcome appear, and did it reopen?;
- how was it translated into value, and who validated it?;
- what share of the population has a complete chain?;
- which part is observation and which part is attribution?
In Quantum Automation Center, timelines, states, artifacts, logs, and operational and financial analytics can assemble this view. Systems of record still confirm state, and finance validates economic translation.
Quality, privacy, and retention
Do not copy complete payloads by default. Use references, hashes, necessary fields, and controlled access. Evidence retention follows obligation and risk; technical telemetry may have a different window. Correct events through new versions rather than silent edits.
Measure incomplete chains, transitions without IDs, late events, unobservable outcomes, and economic values without validators. Coverage is part of the result: ROI calculated on a selected minority does not describe the whole population.
The strongest counterargument
The complete chain requires integration, shared vocabulary, and discipline. For low-value decisions, instrumenting five links can cost more than automation. The organization may become obsessed with lineage and delay learning.
That criticism is valid. Apply proportionality: object, decision, and action always; outcome and economics when making an impact claim. Sampling is reasonable during early stages. What is not reasonable is presenting ROI with missing links and no disclosed limitation.
When not to use this approach
Do not implement the complete schema for creative work without verifiable outcomes, isolated exploration, or workflows without stable object identity. Do not force causal language when no defensible comparison exists.
Use it when repeated decisions reach systems of record and the enterprise wants to govern or monetize outcomes. The chain does not guarantee ROI. It guarantees every claim can travel back to the object and reveal exactly which evidence supports it.
Sources
Article topics
