Why systems of record can leave content authority unclear

A legitimate system of record can still leave authority unresolved

A platform can truthfully call itself a system of record while customers still see an outdated marketing claim. Its record may establish what the organization approved, while another system controls what customers receive. For teams evaluating platforms or connecting AI agents, the risk begins when authority over one responsibility is assumed to cover the entire content process.

At Bynder Connect in Amsterdam, Bob Hickey, CEO of digital asset management vendor Bynder, linked record authority to governance and AI readiness. A digital asset management platform, or DAM, manages media assets, and Bynder benefits commercially when buyers see that role as a foundation for AI adoption. Hickey’s keynote slide stated that “the System of Record is the foundation,” linking it to five promises: governance, control, compliance, searchability and being “ready for activation”. Without such a record, he warned, AI is “at best ineffective and at worst a liability.”

Aprimo also gives the DAM a central role, a position that supports its commercial interest in selling DAM software. Its company blog describes “using the DAM as the system of record and the downstream CMS as a system of delivery,” while calling the media record “the definitive source of truth”. A content management system, or CMS, manages content for publication. Aprimo’s distinction identifies a delivery responsibility, but the organization still needs to assign responsibility for original creation and approval accountability.

These statements draw different boundaries: Hickey emphasizes governance and AI readiness, while Aprimo explicitly separates the media record from delivery. Each vendor can accurately describe its platform’s responsibility while a buyer assumes broader coverage. Buyers therefore need to establish which decisions a platform governs before extending its record authority to the rest of the content process.

Authoring, approval and live delivery answer different questions

Establishing that scope begins with separating content creation from approval. An authoring environment holds the work as people draft and assemble it, answering where the content originated. An approval record establishes which version was accepted, who accepted it and which policy applied. Both responsibilities can sit in one platform, but an origin record alone cannot establish that the content passed the required review.

Approval then needs to connect to a third responsibility: live delivery, meaning the version currently reaching customers at a publication destination. An approved version is eligible for use, but the publishing system may still be serving an earlier version. So authoring answers where content originated, approval establishes who accepted which version under what policy, and live delivery establishes what customers receive now.

A platform may cover one, several or all three functions, provided its records and controls demonstrate that coverage. The architectural decision is where each responsibility belongs; the number of products follows from how the organization implements those responsibilities. The governance gap appears when a vendor legitimately claims a record function and the buyer interprets that claim as authority over the entire sequence.

That broader interpretation can leave work unassigned even while every system operates correctly within its scope. The approval platform records approvals, and the publishing platform serves its stored content. Neither necessarily reports an error when the organization has failed to connect an approved change to the version customers receive.

An auditable correction can leave an outdated claim live

The missing connection becomes visible when a marketing claim is corrected inside the approval platform. The correction receives a timestamp, and the organization can audit the decision, but the page carrying the earlier claim sits in a separate publishing system. Unless the correction reaches that destination, customers continue to see the outdated claim. Both platforms can remain accurate about what they track while the transition between them fails.

Customers are already asking how platforms handle these changes in claims and digital-rights management, which governs permission to use assets. A correction requires replacement content to reach the affected destinations, while a revocation requires published derivatives, versions made from the primary asset, to be withdrawn wherever they remain in use. Updating the primary asset’s rights record can leave those copies available elsewhere. The operational question is whether the change reached every affected publication destination.

An unnamed content operations veteran described three places that teams need to distinguish: where work is authored, where evidence of approval is held, and where the approved version is live. Each location carries a different responsibility, even when a broad system-of-record label groups them together. Assigning governance to the wrong location can therefore leave a team with sound records and an unresolved publication obligation.

Life sciences provides a long-established example of assigning approval accountability explicitly. Most large pharma and biotech firms use Veeva Vault as the accountability record for regulated content, with audit trails and standardized workflows designed to support regulatory scrutiny. Vault is deliberately separate from the marketing CMS and the DAM in this architecture, giving regulatory affairs teams a clear place to establish what was approved.

That approval record has a specific regulatory purpose, so a promotional platform’s assertion about an asset cannot replace it. The hypothetical justification “our DAM said it was fine” illustrates why such an assertion would be inadequate for Food and Drug Administration (FDA) accountability. Compliance drove this separation for decades before the current AI-agent discussion because organizations needed to account for regulated content and the consequences of getting it wrong.

Separating approval evidence still leaves a delivery responsibility to assign. Vault can hold the accountable approval record, the DAM can manage the media, and the CMS can determine what customers receive. The organization must connect those roles so it can distinguish an approved correction from one that has reached publication and identify who resolves any difference.

Veeva’s move toward unifying more of these functions shows that explicit responsibility can also exist within a combined platform. Veeva sells Vault and benefits commercially from customers bringing more functions into its platform, so its expansion also serves a business interest. One platform may genuinely manage authorship, approval accountability and delivery. Its combined coverage still needs to show who approved a version, whether it reached customers and which market or team it applies to.

MCP gives agents access while authority still needs a rule

These responsibilities matter more when AI agents retrieve information across systems without a person selecting each record manually. At Connect, Bynder demonstrated conversational retrieval: open Claude, ask a question and receive information drawn directly from Bynder. MCP, the Model Context Protocol, provides a standard way for AI applications to access connected systems and their tools or data. The conversation is the user interface; MCP enables the connection behind it.

The connection makes information held in a platform easier to obtain, but the organization still needs to decide which platform governs the question. Permission to consult a system does not establish its authority over approval, publication or a particular claim. An agent therefore needs both access and a rule for choosing the relevant record.

Consider a stack containing a DAM, a CMS, a product information management system, or PIM, which manages product information, and, in a regulated organization, Vault. In this scenario, all four have authorized MCP connections and can return information within their scope. Before selecting an answer, the agent still needs to know which system governs the specific question.

Without that rule, an implementation could answer from whichever system responds first. This is an illustrative failure scenario, separate from Bynder’s demonstration and from MCP’s inherent behavior. Response speed establishes availability, while authority depends on whether the responding system governs the requested function.

A person facing that uncertainty may distrust a record and ask someone elsewhere. An agent can also be designed to recognize uncertainty and escalate, provided it has guidance on when an answer is insufficient. Authorizing several connections without defining their responsibilities leaves that judgment unspecified.

Even a clear platform assignment can fall short when different contexts require different versions. Two markets or two teams may legitimately use different versions of the same marketing claim, and retaining every derivative does not tell the agent which one applies. The selection rule therefore needs to identify the function, the claim and the relevant market- or team-specific version.

With those details defined, an agent asking what was approved can select a different record from one asking what is currently published. A unified platform must preserve the same distinctions within its own records. As vendors add MCP access, these rules need to accompany the connections so that easier retrieval produces an answer appropriate to the task.

Test authority, propagation and accountability before granting agent access

Defining those rules starts during platform evaluation, before a record label becomes an architectural assumption. Ask vendors to demonstrate their claimed scope, then map the organization’s stack against authoring, approval accountability and live delivery. Apply the same review during a renewal or agent rollout, because an existing platform may be authoritative within its scope while the organization relies on it beyond that scope.

A six-question governance check makes that review concrete by examining responsibilities that can fail independently. Clear platform coverage can coexist with weak propagation, the transfer of content changes to publication destinations, and complete approval evidence can coexist with unclear ownership of live content. Each question therefore needs its own answer, supported by the records, controls and people responsible for that part of the process.

Coverage: Which parts of authorship, approval and current publication does the platform govern? Ask which records establish each function and where the platform’s responsibility ends. When another system holds the answer, name it explicitly so the boundary is clear. A product covering all three functions should demonstrate each one through its records and controls.
Correction and revocation: What happens at every affected publication destination when a claim changes or a right is revoked? Follow the change beyond the primary record to the places where content is published. For a correction, establish whether the updated version reaches those destinations; for a revocation, establish whether affected derivatives are withdrawn. This tests propagation across the full publication scope.
Traceability: Can the organization reconstruct the sequence from draft to approval to live content? Connect the authored version to its approval evidence and then to the version actually reaching customers. Separate records can each be accurate while leaving their relationship unclear. Traceability establishes whether the organization can reconstruct that relationship when a discrepancy occurs.
Agent routing: What directs an agent to the authoritative platform when several systems have authorized MCP access? Inspect what the agent retrieves and what it leaves out. A response from an authorized system begins the assessment, because the selection rule must also explain why that system governs this particular knowledge question. Include the conditions under which the agent should seek clarification or escalate.
Version context: How is authority attached to the derivative required by the relevant market or team? When two markets or two teams need different claims, retaining both versions still leaves a selection decision. Establish how the organization identifies which version applies to the request. That context must remain available and clear when an agent retrieves the content.
Accountability: Who resolves a difference between the platform’s record of what is live and what customers actually receive? Name the party responsible for investigating and correcting that difference. If ownership falls to whoever assumed the platform covered the entire process, the original gap remains. Assign the responsibility before a discrepancy occurs so the response has a clear owner.

More than one or two uncertain answers should prompt a closer review of whether authority over one function has been extended to all three. Use that threshold as a practical rule of thumb rather than a validated scoring instrument. Its purpose is to identify assumptions that a platform demonstration or architecture discussion can resolve.

Regulated-content requirements add a further test: consider what separation of responsibility a regulator would require from the organization. Apply the same six questions to every vendor platform and internal system claiming record authority, including systems that combine several functions. Require the responsible team to demonstrate which record governs the requested function and version, and how the agent will select it.

Key takeaways for leaders

Define platform coverage: Platform buyers need evidence of which systems govern authoring, approval and live delivery. Require vendors to demonstrate each claimed responsibility and identify where another system takes over.
Verify corrections and revocations: Content operations owners need to track corrected claims and revoked rights through every affected publication destination. Confirm that updates reach live content and affected derivatives are withdrawn.
Connect draft, approval and publication records: Governance owners need a traceable link between the authored version, its approval evidence and the version customers receive. Test whether those records let the organization reconstruct a discrepancy.
Set agent routing rules: AI platform teams need explicit rules directing agents to the system that governs each question. Define when an agent needs clarification or escalation before enabling access across multiple platforms.
Preserve version context: Content owners need to attach market and team context to each approved version. Ensure agents can use that context to select the claim appropriate to the request.
Assign responsibility for live discrepancies: Publishing and governance owners need a named party responsible for resolving differences between platform records and customer-facing content. Establish that ownership before deployment or agent rollout.