Build a Source-of-Truth Map Before You Build a Dashboard

A dashboard can make five systems look like one. That is useful for navigation. It is dangerous when the interface also makes five different kinds of evidence look equally authoritative.

The chart did not become the source of truth because it was easier to read. The data warehouse did not become the source of truth because it joined the records. The most recent event did not become the source of truth because it arrived last. And a green status did not become proof that an action was authorized, accepted, or reconciled.

Before a dashboard is built, the team needs a source-of-truth map.

A source-of-truth map is a field-level control record showing which entity is being described, which decision the data will support, which source governs each field, how data is transformed, how fresh it must be, who resolves conflicts, and what evidence closes the loop. It is not a diagram of integrations alone. It is a map of authority.

“The system of record” is usually too broad

Teams often say that one application is the system of record. That phrase can hide more than it explains.

One system may govern the customer’s contractual status. Another may govern the posted accounting result. A third may govern the configured access state. An event stream may prove that a command was emitted. A provider receipt may prove acceptance. A public page may prove what customers were shown. A dashboard may summarize all of them without governing any of them.

The useful question is not:

Which application is the source of truth?

It is:

For this exact field, entity, time, and decision, which record is authorized to decide the value?

That question forces the map down to the level where operating errors occur.

Separate five source roles

Use distinct labels instead of calling every useful source authoritative.

Source role	Meaning
Governing source	The record authorized to decide one defined field for one defined scope.
Source of observation	Where a signal, claim, or discrepancy was observed. It may be wrong.
System of action	Where an approved action is executed. Execution does not prove the intended result.
Evidence source	A receipt, event, export, revision, or visible readback that proves one state transition.
Derived view	A join, cache, report, model output, or dashboard assembled from other records.

A system can occupy more than one role, but only when the map says exactly which role applies. The default should not be “everything in this application is authoritative.”

Start with the decision

Do not begin the map with databases. Begin with the operating decision the dashboard is expected to support.

Examples include:

• Which facilities have unresolved maintenance exceptions?
• Which customer-facing facility facts are in conflict?
• Which access changes were authorized but not reconciled?
• Which payment requests were initiated but not posted?
• Which automated messages lack a current governing source?

For each decision, write:

1. the exact question;
2. who is allowed to decide;
3. the consequence of a wrong answer;
4. how current the evidence must be;
5. what state the dashboard may display; and
6. what the dashboard must never do automatically.

If the decision is undefined, the dashboard will optimize for display density instead of operating truth.

The nine-part source-of-truth map

1. Entity identity

Name the object being described and its stable identifier. A facility name, address label, customer name, provider label, or work-order title can change. The map needs an identifier that independent observers can repeat reliably.

Current OpenTelemetry entity guidance makes the same architectural distinction: identifying attributes should remain stable over the entity’s lifetime, descriptive attributes may change, and an observer that cannot supply reliable identifiers should not emit that entity type. OpenTelemetry’s entity model is currently marked Development, so treat it as current technical guidance, not a settled facility-management standard.

For a multi-location operating map, record the facility ID separately from its public name, address, region, lifecycle state, and third-party identifiers.

2. Field definition

Define the field’s name, type, permitted values, units, timezone, effective-date behavior, and null meaning.

“Open” is not a sufficient definition. Does it mean office open, tenant access enabled, accepting rentals, staffed, available for support, or active in the portfolio? A field that cannot survive that question is not ready for a dashboard.

3. Governing source and owner

Assign one governing source for the field and one accountable source owner. Record the rule that grants authority: approved policy, configuration ownership, accounting control, content governance, or another explicit basis.

If the field can be jointly governed, document the decision rule. Do not leave the join implicit.

4. Observation sources

List every place the value may be observed: application API, export, public page, provider portal, event stream, document, message, spreadsheet, sensor, or staff report.

An observation source can trigger a review. It cannot silently replace the governing source.

5. Transformation path

Record every material transformation between source and dashboard:

• extraction method and timestamp;
• schema version;
• normalization rule;
• join key;
• filter and exclusion rule;
• timezone conversion;
• deduplication rule;
• aggregation window;
• model or classification step; and
• cache or materialization delay.

The transformation path is where a correct source can become a misleading dashboard value.

W3C PROV-O offers a durable vocabulary for this problem. Its starting point distinguishes an Entity, an Activity that uses or generates entities, and an Agent responsible for an activity or entity. A practical source map does not need to implement the ontology, but it should preserve the same questions: what record existed, what process transformed it, who or what performed the process, and what new record was derived.

6. Event and evidence envelope

For event-driven workflows, preserve enough context to distinguish occurrence from delivery.

At minimum, capture:

• event ID;
• event source;
• entity or subject identifier;
• event type;
• occurrence time;
• ingestion time;
• schema version;
• correlation or causation reference;
• payload checksum or safe evidence reference; and
• processing result.

The CloudEvents specification is a vendor-neutral reference for describing event data. Its released line identifies id, source, specversion, and type as core context, with time available for the occurrence timestamp. CloudEvents also warns that a single occurrence can generate more than one event and that source plus id is used to identify duplicates. That means “one event row” is not automatically “one business occurrence,” and delivery time is not automatically occurrence time.

7. Freshness and completeness

Define three separate thresholds:

• freshness: how old the newest usable source observation may be;
• latency: how long the pipeline may take to deliver it; and
• completeness: which required sources or fields must be present before the value is usable.

Record both occurrence time and observation or ingestion time. RFC 3339 provides an Internet timestamp profile with an explicit relationship to UTC. Use an offset or Z; do not store a bare local time and assume every system interprets it the same way.

8. Conflict and exception ownership

For every field, define what happens when:

• two sources disagree;
• the governing source is unavailable;
• the observation is stale;
• an identifier does not match;
• the event is duplicated or out of order;
• the transformation version changes;
• a required field is null; or
• a downstream action cannot be reconciled.

The dashboard should display the conflict state and accountable owner. It should not resolve the conflict by selecting the newest, most convenient, highest-ranked, or most complete-looking value unless that exact rule is approved and recorded.

9. Visible result and rollback

Name what proves success. It may be a posted ledger result, a provider receipt, a live configuration readback, a public-page readback, a closed work order with verification, or another governing record.

Also record how to reverse the transformation, dashboard release, or automated action. A source-of-truth map without rollback is a documentation artifact, not an operating control.

A fictional maintenance example

Assume a portfolio dashboard shows “open maintenance exceptions.” The following systems exist:

• a work-order application;
• an email inbox where vendors send updates;
• a facility manager’s inspection log;
• an event pipeline;
• a warehouse table; and
• the dashboard.

The work-order application may govern the assigned owner and approved status. The inspection log may provide field evidence. A vendor email may be an observation or receipt, not proof of verified completion. The event pipeline may prove that a status change was emitted. The warehouse may normalize the records. The dashboard may count them.

The map could define verified_closed as true only when:

1. the work-order ID matches the stable facility ID;
2. the governing work-order state is closed;
3. the verification evidence reference is present;
4. the evidence was observed after the completion event;
5. no active exception supersedes it; and
6. the dashboard pipeline processed the approved schema version within the freshness threshold.

That definition is more work than coloring a card green. It is also the difference between reporting activity and governing closure.

This example is fictional. It does not describe a modSTORAGE facility, vendor, software integration, or measured result.

The dashboard release gate

Do not release a dashboard field until all of these are true:

• □ Decision and accountable role are named.
• □ Entity identifier is stable and repeatable.
• □ Field definition, units, timezone, and null behavior are explicit.
• □ Governing source and source owner are approved.
• □ Observation sources are labeled without being promoted to authority.
• □ Transformation, join, filter, aggregation, and schema versions are recorded.
• □ Occurrence and ingestion times are separate.
• □ Freshness, latency, and completeness thresholds are defined.
• □ Conflict states route to an owner.
• □ Sensitive data is minimized and access is bounded.
• □ Visible reconciliation evidence is named.
• □ Rollback is tested in proportion to consequence.
• □ Desktop and narrow-screen controls are verified.
• □ Dashboard language does not overstate what the evidence proves.

A 30-minute mapping exercise

Choose one dashboard field—not an entire application—and complete the companion source-of-truth map.

Then ask another operator to reconstruct the answer without verbal help:

1. What entity does this row describe?
2. Which source governs the field?
3. What transformations occurred?
4. How old can the data be?
5. What happens when sources disagree?
6. Who decides?
7. What proves the final state?
8. How is a bad release rolled back?

If the reviewer cannot answer from the map, the dashboard is not yet self-explanatory enough to govern work.

Measure map quality

Useful measures include:

• mapped dashboard fields divided by total in-scope fields;
• fields with a governing source divided by mapped fields;
• fields with an accountable source owner divided by mapped fields;
• transformations with a version and test divided by total transformations;
• dashboard values inside freshness threshold divided by values displayed;
• conflicts with an assigned owner divided by conflicts detected;
• reconciled actions divided by actions executed; and
• releases with a tested rollback divided by releases made.

Publish the numerator, denominator, period, source, and limitations. A dashboard quality score without those components is another derived view without a source map.

Sources and limitations

This playbook draws from current primary standards and official documentation:

• NIST Cybersecurity Framework 2.0, published February 26, 2024
• W3C PROV-O, a W3C Recommendation dated April 30, 2013
• CloudEvents specification repository, whose latest released core line is v1.0.2 while the main specification is a working draft
• OpenTelemetry Entity Data Model, currently marked Development
• RFC 3339, published July 2002

NIST CSF 2.0 is voluntary and high-level; it does not prescribe this map or certify a system. PROV-O is a general provenance ontology. CloudEvents standardizes event context, not business authority or delivery guarantees. OpenTelemetry guidance is designed for telemetry and includes developing material. RFC 3339 standardizes timestamp representation, not operating schedules or retention policy.

Disclosure

I am CEO and Co-Founder of Facily.ai and Chief Operating Officer of modSTORAGE. This is a proposed architecture method. It is not a Facily OS release diagram, a product-availability statement, an integration claim, a customer case study, or a performance result.