There is no single source of truth without state, provenance, and conflict rules

A central database does not become truth through concentration; only a layer preserving facts, provenance, effective time, and conflict rules can explain which state is believed and why. If two sources disagree and the last received value wins without considering who asserted it or when it occurred, the organization has a convenient cache rather than a source of truth.

Separate fact, projection, and inference

A fact is a received assertion: an order was approved, a payment settled, a container departed. A projection calculates current state from facts and rules: “order ready for dispatch.” An inference estimates something not declared: “high delay risk.”

Mixing the three makes audit impossible. An inference can silently replace source data; a correction can look like a new occurrence; a projection can be stored as though it was always true. The contract must label origin and function.

Identity before state

Define a stable object identifier and explicit relationships to external identifiers. Do not use email, supplier name, or an unscoped document number as a universal key. Maintain:

• immutable internal object_id;
• object_type and versioned schema;
• source_aliases with system, scope, and validity;
• parent/child and business relationships;
• projected state and version;
• references to supporting events.

An alias can change or be reused. The object keeps continuity while the relationship explains when and in which source it was valid.

Minimum truth-layer contract

Field	Rule
object_id/type	stable identity and versioned type
event_id/source	unique combination for deduplication
assertion_type	declared fact, correction, inference, or decision
effective_at	when the assertion was true in the business
observed_at	when the organization received it
payload_schema	contract used to interpret data
provenance_ref	source, activity, agent, and permitted evidence
supersedes	corrected assertion, never erased
expected_version	version the writer expects to update
conflict_status	none, pending, resolved, or accepted
policy_version	rule that projected or resolved state
projection_version	reproducible derived state

The CloudEvents specification requires context attributes such as id, source, specversion, and type and advises against sensitive information in those attributes. It can serve as a transport envelope; the business contract adds object, effective time, provenance, and policy.

Provenance: entity, activity, and accountable agent

The W3C PROV-O Recommendation models Entity, Activity, and Agent, with relationships such as used, wasGeneratedBy, wasDerivedFrom, and wasAssociatedWith. Full ontology adoption is not necessary to benefit from the triad:

• Entity: document, event, object version, or artifact.
• Activity: extraction, matching, approval, or transformation.
• Agent: person, organization, or software responsible for activity.

For example, the “invoice approved” projection was generated by an approval activity using invoice and order, associated with an approver, and governed by a policy. That chain is more useful than storing only approved=true.

Two times prevent a false history

Store effective_at and observed_at. A supplier may report today that an event occurred yesterday. Ordering by receipt would make operational history wrong; ordering only by occurrence would hide that the team decided with late information.

Current projection uses an agreed policy and facts known at a point in time. For audit, answer both “What do we believe occurred?” and “What did we know when we decided?” This does not require an elaborate academic implementation. It requires not overwriting the two times.

Conflict rules that do not depend on arrival

Define per field or transition:

1. Authority: which source may assert the fact.
2. Precedence: when one source may correct another.
3. Validity: when the assertion starts and ends.
4. Compatibility: which states may coexist.
5. Resolution: automatic rule or human owner.
6. Evidence: what must be retained to accept change.

Do not use last-write-wins for consequential fields. In update APIs, the If-Match mechanism in RFC 9110 can condition a write on a matching entity tag and prevent accidental overwrite by a stale writer. ETag does not resolve the business conflict, but it detects that the writer acted on an old version.

Illustrative conflict example

This case is illustrative. The ERP asserts that an order was cancelled effective Monday. A warehouse system reports on Tuesday that it was picked, but the message arrives Wednesday. The truth layer does not select “picked” merely because it arrived last.

Policy declares the ERP authoritative for cancellation and the warehouse authoritative for physical picking. Both facts remain. The projection raises a conflict: cancelled object with later physical activity. An exception opens to decide return, release, or correction. Resolution creates another event associated with a person and policy without deleting either source event.

If an agent summarizes the case, it cites events and acknowledges conflict. It cannot invent a clean sequence.

Read and write as different contracts

An executive read can return a compact projection: state, age, owner, and next action. An audit read returns events, provenance, and version. A write requires expected_version, reason, actor, and evidence. Separate views avoid sending complete history to every consumer while retaining reconstruction.

Materialize projections for speed, but treat them as derived. When a rule changes, create a new projection_version and reprocess from compatible facts. Preserve the version seen by an already executed decision.

Representing the model in Quantum

In Quantum Automation Center, the business object can link executions, state, timeline, artifacts, and logs. Agents and automations appear as activities; permissions and approvals identify authority; analytics consume projections without erasing evidence. The Quantum ontology supplies a connection point between objects and processes.

Do not load every sensitive payload. Keep protected references and the minimum data needed for correlation and decision.

Counterargument: this discipline makes simple queries expensive

It does. Events, two times, provenance, and versions require design and storage. A dashboard should not rebuild full history on every load. The answer is materialized projections, indexes, and retention policy—not a return to overwrite.

Use proportional depth. An irreversible financial object needs more evidence than a temporary interface preference. The common contract can remain small with domain extensions.

When not to build a truth layer

Do not build one for temporary data shared by no consequential decision. Do not replicate a system of record already providing sufficient identity, history, permission, and concurrency. Publish it as an authoritative source and link its events.

Do not begin with a central platform before agreeing authority and conflict rules. Technology only accelerates an undefined rule.

Test whether truth is useful

Take one disputed state and answer: which facts support it, who asserted them, when they occurred, when they became known, which policy projected state, and how conflict was resolved. Then reproduce the projection. If an answer depends on “that table always wins,” the truth contract is still missing.

Sources

• W3C PROV-O: The PROV Ontology — w3.org
• IETF RFC 9110: HTTP Semantics — ietf.org
• CloudEvents Specification — github.com