When was it true? Customer 360 needs two clocks

One timestamp hides two different histories

A customer tells you on Thursday that their billing contact changed on Monday. Which date belongs in Customer 360? Monday describes when the relationship fact became effective. Thursday describes when the CRM learned it. A single updated-at timestamp forces one answer to erase the other, so a later reader cannot distinguish a late report from a change that happened inside the system.

That difference matters when work already happened. A renewal reminder, access decision, handoff, or agent proposal may have used the best information available on Tuesday and still look wrong after Thursday's correction. Replacing the old value without record history makes the earlier decision inexplicable. Refusing the correction preserves the audit trail by keeping the customer view wrong. A trustworthy system needs to update what it now believes without pretending it always knew.

Martin Fowler's April 7, 2021 explanation of bitemporal history calls these dimensions actual history and record history, also commonly described as valid or effective time and transaction or system time. Treat that as a modeling pattern, not a CRM standard or a command to version every field. Use it where late, future-dated, or retroactive information can materially change relationship work; keep simpler facts simple.

• Effective from and effective to answer when the assertion applies in the relationship domain.
• Recorded at and superseded at answer when this CRM accepted the assertion as its working knowledge.
• Source, recorder, reason, and correction link explain why the timeline changed without copying an entire message or document.
• Unknown or disputed boundaries stay explicit; never invent a precise effective date just to complete the interval.

Keep an as-known view, not an immortal dossier

Microsoft documents system-versioned temporal tables as a way to retain previous row versions and query state at a past point in system time. That is useful for reconstructing what a database held, but it does not by itself establish when a relationship fact was true outside the database. XTDB, an open-source database, documents both system time and valid time and shows how the pair can answer what is now believed about a past date and what was believed at an earlier recording date. These are database design precedents, not endorsements, portability guarantees, or a requirement to replace SQLite, D1, or any other owner-chosen store.

The portable contract is more important than a storage feature. For a versioned assertion, keep a stable assertion ID; the actor or relationship it describes; the field or claim type; its effective interval; its recorded interval; a minimal source reference; any correction or supersession link; and the purpose, classification, and access rule that govern use. A current Customer 360 view can project the latest applicable assertions while an as-known query reconstructs the versions available to a named decision.

History increases privacy and security responsibility. Apply purpose and least-privilege checks to historical queries, not only to the current profile. Give each data class a retention rule, make expiry and deletion visible in the timeline, and keep sensitive source content outside the assertion when a reference or digest is enough. Two clocks explain change; they do not justify infinite retention, broader access, hidden inference, or recreating data that was deliberately erased.

• Start with consequential facts that arrive late or change retroactively, such as relationship roles, service eligibility, contract boundaries, and approved communication preferences.
• Do not version derived labels merely to accumulate behavioral history; record the purpose and source before deciding that history is needed.
• Export the current projection and the retained assertion history in documented, owner-readable forms with stable identifiers and interval semantics.
• Test retention against backups, replicas, exports, and downstream indexes; a missing current row is not proof that every governed copy has expired.

Correct the present without rewriting the decision

When a late correction arrives, append a new recorded version, close or qualify the superseded assertion, and recompute the current projection. Do not edit the earlier receipt. Any consequential decision should point to an as-known time, the exact assertion versions it used, the policy result, and the resulting effect. The receipt then remains truthful: it shows the evidence available when the action occurred, while the relationship view can show the corrected state now.

A correction may create follow-up work. Compare the corrected timeline with decisions that depended on the old assertion, classify the consequence, and propose repair without silently replaying history. Some cases only need a refreshed view; others may need a human-reviewed message, permission change, service adjustment, or compensating action. A later fact does not retroactively authorize an earlier action, and a clean temporal model does not decide whether remediation is legally, contractually, or ethically required.

CRM agents should receive the smallest purpose-bound temporal view they need. They may summarize the difference between current and as-known state, flag overlapping intervals or missing source evidence, and draft a repair plan. They must not guess dates, collapse conflicting assertions, reopen expired history, contact someone, change access, or execute compensation without current authority. Bind every proposal to the snapshot it inspected so a human can see whether new information made it stale before approval.

Test the uncomfortable cases: a fact reported late, a future-effective change, two sources with overlapping intervals, a correction to a correction, a source that becomes unavailable, and history that expires under policy. Then round-trip the retained timeline through export and import and verify both the current answer and the as-known answer. An open CRM earns trust when the owner can carry not only today's value, but the honest boundary between what happened and what the system knew.

• Require effective time, recorded time, source status, and uncertainty to survive connector and export round-trips.
• Invalidate pending proposals when any assertion in their as-known snapshot is superseded, disputed, expired, or becomes inaccessible.
• Keep repair and compensation as new governed actions with their own approvals and receipts rather than edits to the original event.
• Show people a plain-language timeline: what is believed now, what changed, when the CRM learned it, and which decisions used the earlier view.