Write-Back Gap

A one-way integration is a design outcome, not a failure

Integrations get specified in the direction somebody asked for: push the customer to the tool, push the job to the field, push the applicant to the rater. The return path is a separate build with a separate cost, and it is the one that carries operational truth back. Nothing breaks when it is missing. The record simply stops receiving the entries that describe what actually happened.

The gap is invisible from inside the record, because a record cannot report on entries it never received. It surfaces indirectly — a renewal conversation with no service history, a handover with no context, a report whose denominator is quietly the subset that happened to be captured.

How to detect it without new instrumentation

1. Name the system of record for the entity in question.
2. List every downstream or edge system that receives it — portal, rater, field application, provider, scheduler.
3. For each, ask what the person there produces: a note, a status, a completion, a measurement, a signature.
4. Check whether any of that appears in the system of record, and by what path.
5. Where it does not, reconcile: export transactions from the external system for a bounded period and compare them against the record.

This is a reading exercise, not a build. The data already exists and was already created by a person doing real work; the question is only whether it is carried.

Decide the identity key at the outward hop

A return path is only useful if the returning entry can be matched to the record it belongs to. Event specifications make this explicit rather than incidental: a producer must ensure that the combination of `source` and `id` is unique for each distinct event, and a consumer may assume that events sharing that pair are duplicates ^{[cloudevents_spec]}. The same discipline applies to a write-back — decide the key when the record leaves, because reconciling on names and dates afterwards is additional work that deciding a key once avoids.

Retry behaviour belongs in the same decision. A method is idempotent when the intended effect of several identical requests is the same as the effect of one ^{[rfc9110_idempotent]}, which is why a return path built on repeatable writes survives the timeouts and redeploys that occur in normal operation. Platform guidance for at-least-once delivery makes the same point from the consumer side: where events may be received more than once, the consumer must be idempotent so that processing the same event repeatedly has the same outcome as processing it once ^{[azure_resilient_event_design]}.

What identifying a write-back gap establishes

Where this sits

The integration and orchestration systems guide owns the broader architecture; this is one supporting entity inside it. The documented event surface determines whether a return path can be event-driven at all, and terminal state configuration governs what a sequence writes when it stops. This entry sits in the Glossary. Locate the capability under the Integration & Orchestration Systems domain, and use Revenue Scan when the next question is whether public surfaces show observable gaps.