Rethinking Truth in Operational Systems

This article is in reference to:

Your System of Record Is a Relationship

As seen on: cfcx.work

Why this argument about “truth” exists at all

The original post exists because a simple question keeps quietly sabotaging complex organizations: “Which system is the system of record?” It sounds like a governance move. It behaves like a power grab.

Behind that question is a deeper tension. Modern companies run on a mesh of specialized tools, but they still try to govern them as if there were one ledger, one schema, one master file. The post is pushing against that reflex. It is trying to name the cost of pretending that a single database can represent how work actually happens.

At stake is more than data architecture. It is the shape of responsibility. When one system is crowned as “the source of truth,” teams are asked to contort their workflows around that decision. The article is arguing that this is backwards: truth in an operating company is not a record in a table, but a living agreement about who owns what, when, and for which decisions.

From master records to negotiated responsibilities

The core move in the original piece is a shift from objects to relationships. Instead of asking “Where does the vendor live?” it asks “Who owns which attributes of a vendor, at which moment, for which purpose?”

This move matters because the old framing hides asymmetry. Systems care about different slices of the same real-world entity. ERP cares about payability and compliance. Procurement cares about sourcing and evaluation. Logistics cares about movement and timing. Calling any one of these the vendor, full stop, forces everyone else to inherit that system’s worldview.

The post suggests that what organizations call a “system of record” is usually a shortcut for a more complex map of responsibilities:

• Who is allowed to create and change certain attributes?
• Who is accountable for validating them?
• When is a field “good enough” for a particular workflow, even if it is incomplete?
• How do different tools know they are talking about the same underlying entity? By surfacing this map, the article is trying to replace the winner-takes-all model with a federated one: multiple systems are “of record,” but only for the pieces they are qualified to own. The real integration work moves from copying data to managing these relationships over time.

What dummy vendors are really signaling

The vendor onboarding example is not just a design pattern. It is a diagnostic. Dummy vendors, shadow spreadsheets, and bypassed approvals are not integration bugs; they are symptoms that the declared “system of record” does not match operational reality.

In the ERP-first pattern, finance’s definition of readiness dominates. A vendor is only “real” once the legal name, tax details, banking, and compliance checks are in place. Procurement’s earlier need—to test, quote, and compare potential suppliers—is made subordinate to this definition. When work cannot wait for full readiness, people invent side doors.

The relationship-based pattern reframes those workarounds as legitimate needs. It splits the entity into two identities with different owners and thresholds for adequacy:

• An operational identity sufficient for sourcing and evaluation.
• A financial identity sufficient for payment and accounting. The linkage table and state-based gates are not just technical constructs. They encode a more honest story: a supplier can be “real enough” to quote before they are “real enough” to pay. The design is acknowledging that truth comes in stages, and that governance should mirror those stages instead of erasing them.

This is the deeper signal behind the article: when people build dummy vendors, they are not trying to break controls. They are trying to restore continuity to a workflow that has been distorted by a rigid notion of truth.

Data contracts as social contracts

The post’s emphasis on data contracts, crosswalks, and event-driven states is easy to read as architecture advice. At a higher altitude, it is about making implicit agreements explicit.

Every integration already contains a social contract. Someone assumes they can change a field without breaking another team’s process. Someone expects that a state transition in one system will unlock or block action in another. When those expectations are undocumented, the fallback is hierarchy: the “primary” system’s model wins by default.

By asking teams to define system of entry, system of change, system of approval, and propagation rules per attribute, the article is pushing toward a different kind of control: constraint by design instead of constraint by centralization.

Crosswalks and stable identifiers carry the same message. Relying on one system’s internal IDs is a quiet form of dependency: if that system changes, everyone else must follow. A crosswalk is a small act of decoupling. It accepts the cost of maintaining a mapping table now to avoid forcing every future system to share the same lineage.

Similarly, modeling events and states “invited → quoted → selected → onboarded → payable” reframes integrations from static mirrors to choreographies. Instead of asking, “Are the records in sync?” the question becomes, “Are we in the same stage of the story?” The post is arguing that organizations regain control not by minimizing these stories, but by representing them faithfully.

Control, fear, and the comfort of a single throne

Underneath the technical language sits a governance anxiety. The drive to name a single system of record is rarely only about convenience. It often reflects a fear that, without a central authority, data will drift and controls will erode.

The article counters this fear by separating control over data from control over behavior. Centralizing all attributes in the ERP does not guarantee that teams will follow the intended process; they will still route around obstacles when the model does not fit reality. In contrast, aligning constraints with actual workflows—“no payments before financial identity is linked,” “no POs without at least a pending onboarding state”—ties governance to the moments where decisions are made.

This is a quiet but important reframing. Control becomes a property of well-designed interfaces and lifecycle gates, not of schema ownership. A networked architecture can be more governable precisely because it accepts that different teams own different truths, and binds those truths together with explicit contracts.

In the end, designing for the way work really happens

In the end, the post is less about integration techniques and more about organizational honesty. It is asking leaders and builders to admit that their companies do not, and cannot, operate as if there were a single, static “source of truth” for each entity.

Ultimately, treating the system of record as a relationship is an attempt to reconcile two stories: the story systems want to tell about neat, unified data, and the story people live as they move work forward despite partial information, delays, and changing conditions. The proposal is to let the second story shape the first.

Looking ahead, this framing suggests a different starting question for integration and process design. Instead of “Which system wins?” the more useful prompt becomes: “Which responsibilities need to be clear, and how do we encode them so people are not forced into workarounds?”

As more organizations stitch together specialized tools, the cost of clinging to a single throne for truth will rise. The argument in the original post is an invitation to update an old mental model: to see systems not as competing claimants to reality, but as participants in a negotiated network of responsibilities that mirrors how work actually gets done.