Measure coverage of the data-flow inventory

Define what a covered path means

For each component receiving task data, require a known payload scope, destination, identity, retention rule and access owner. Mark whether those details come from intended design, deployed configuration or an observed request.

These evidence levels are different. A diagram can describe the desired route while a proxy or fallback sends actual requests elsewhere. A configuration record can establish settings, while a trace demonstrates that a particular test used them.

Keep unresolved entries visible. Reporting the percentage of completed rows without showing which important paths remain unknown can create false confidence.

Include exceptional and secondary routes

Count successful inference, retries, timeouts, fallback models, embedding jobs, evaluation calls and diagnostic exports. A path used rarely can still receive the most sensitive payload during an incident.

Group entries by the data they carry and the consequence of exposure. A metrics endpoint receiving aggregate counts differs from a trace store holding full prompts. Weighting or prioritising those differences is more useful than treating every box as equal.

Use a synthetic marker to verify representative paths. Retain the request identifier and configuration version so the observation can be reproduced after a change.

Measure policy enforcement directly

Where the requirement is to deny unapproved destinations or identities, include negative tests. A successful request through the approved endpoint does not show that other routes are blocked.

For retention, verify the configured lifecycle and the behaviour the platform actually supports. Do not report immediate physical erasure if the requirement and service only establish application-level unavailability or scheduled deletion.

For access, test the roles that should and should not read stored prompts or traces. A documented owner is not proof that the permissions match the intended audience.

Turn gaps into owned work

Report missing evidence with the affected data and responsible team. A useful acceptance record might say that runtime routing is verified while an evaluation export's retention remains unresolved. That is more actionable than a broad claim that the system is 95 percent private.

Set release criteria according to the actual data-handling requirements. Recheck changed paths when adding services or modifying logging. The inventory is complete enough to support a decision when the team can identify what is verified, what remains uncertain and why each remaining gap is acceptable or blocking.