Single Source of Truth: Define Ownership Before the API

A single source of truth needs a clear answer to a practical question: which system is allowed to decide the value of this record? We recommend answering that before designing the API. A shared endpoint should expose an agreed authority, rather than leave each department to decide which copy to trust.

The Government Data Quality Framework treats quality as fitness for purpose and calls for accountability, work at source and continuing assessment. Our approach applies those principles to integration: name the owner, describe the permitted changes and test what happens when copies disagree.

Define authority for a specific record

Start with one workflow, such as completing a site inspection. Write down where the inspection identifier comes from, who can change the result and which system records acceptance. Treat a local draft, a submitted inspection and an accepted inspection as different states in the design. Do not let the same label conceal different responsibilities.

We would not start by requiring every department to use one database. Instead, assign authority to each type of information. In a proposed construction workflow, the inspection service could own inspection status while finance owns invoice status. Give both systems a common project identifier, but do not give both permission to redefine the same status independently.

Record these decisions beside the interface definition. For every shared field, specify its meaning and who approves a correction. Add the source system and revision to exported records where consumers need them. Ask the business owner to resolve disagreements about meaning before an engineer encodes one department's assumption.

Design the contract before the applications

OpenAPI 3.0.3 provides a language-independent description of an HTTP API. It includes ways to describe parameters, request bodies, responses and security requirements. Use that description to review the interface with the people building each consumer before they implement it.

For the inspection example, define the identifier format, required fields, accepted status values and error responses. Specify how a caller distinguishes an invalid submission from a temporary service failure. Include examples of rejected requests as well as successful ones. Treat those examples as proposed acceptance tests, not proof that the running service already behaves correctly.

Keep business permission separate from the mere existence of an endpoint. We recommend writing explicit tests for who can read an inspection, who can submit it and who can reverse an acceptance. Review the implementation against those rules. An interface document should be a testable agreement, not a substitute for enforcement.

Make competing changes visible

HTTP includes a mechanism for conditional updates. RFC 9110 describes the use of If-Match to prevent accidental overwrites when clients act on the same resource. A client can send an entity tag representing the version it read, and the server can evaluate the update against that condition.

For our proposed workflow, test this with two users editing the same inspection. Let one user save first, then submit the other user's earlier version. Require an explicit outcome: reject the stale change, or send it through a documented reconciliation process. Do not describe either outcome as successful synchronisation until the test confirms the intended behaviour.

Define retry behaviour separately. RFC 9110 defines idempotence in terms of repeated identical requests having the same intended effect as one request. Do not assume that a create operation is safe to repeat. Specify how the application recognises a repeated submission and test a lost response followed by another attempt.

Be honest about offline copies

An authoritative server and a disconnected device need different promises. RFC 9111 describes a disconnected cache as unable to reach the origin server, and permits stale responses only under specified conditions. Its caching rules do not define how an application's offline edits should be reconciled.

For field work, we recommend showing when a record was last confirmed and whether a change is still waiting to be sent. Agree which actions may use an older copy. A previously downloaded address might be sufficient for navigation, while an instruction to proceed with safety-sensitive work should have its own freshness and approval requirements.

Test the return of connectivity as part of the workflow. Include a record changed on the server during the outage, a local submission whose response was lost and an action the server refuses. Require the screen to distinguish a local save from server acceptance. Keep the disputed versions available to whoever is authorised to resolve them.

Measure the reconciliation work

Before connecting another system, observe the current handover. Count the manual corrections in a defined period and record how long people spend resolving them. Separate finding a record from checking its accuracy. Do not apply a generic percentage of staff time to the payroll and call the result a saving.

After the change, repeat the observation for the same workflow and comparable work. Check whether manual reconciliation has fallen or simply moved to a support queue. Record unresolved disagreements as well as completed transfers. This is our recommended evaluation method, not a prediction of a particular financial return.

Keep the quality review tied to the users' needs. The Government Data Quality Framework recommends benchmarking and regular assessment, rather than treating cleaning as a completed project. For this workflow, choose measures that reveal incorrect ownership, outdated copies and rejected changes, then assign someone to act on the results.

Start with a disputed handover

Choose a record that two teams currently correct independently. Agree its owner, document the update contract and demonstrate a competing edit. Then disconnect a device and repeat the handover. We would use those results to decide what to change next, before extending the approach to another workflow.

Update, October 2026

For teams giving software agents access to business systems, we recommend documenting the same ownership and freshness rules in their starting context. Our engineering article What the Agent Does Not Know to Look For explains a grounding pack with dated evidence, explicit gaps and checks against code. It adds a practical way to brief an agent without treating retrieved information as unquestionable authority.

Sources

Government Data Quality Hub, "The Government Data Quality Framework", 3 December 2020.
OpenAPI Initiative, "OpenAPI Specification, Version 3.0.3", 20 February 2020.
IETF, "RFC 9110: HTTP Semantics", 6 June 2022.
IETF, "RFC 9111: HTTP Caching", 6 June 2022.
Dendro Logic, "What the Agent Does Not Know to Look For", 6 September 2026. October 2026 update only.