+++ title = "Why healthy services can produce incomplete financial reports" description = "Healthy services can still omit financial events. Learn why operational monitoring needs separate checks for reporting completeness." date = 2026-09-11 draft = false [taxonomies] topics = ["observability-production-operations", "regulatory-reporting-control-evidence", "data-orchestration-quality-lineage", "trade-capture-matching-confirmation"] kinds = ["advanced-explainer"] [extra] tier = "public" schema_type = "Article" article_class = "advanced-explainer" related_concepts = ["observability", "reporting completeness", "source population", "submission acknowledgement", "control evidence"] sources = ["https://opentelemetry.io/docs/what-is-opentelemetry/", "https://prometheus.io/docs/introduction/overview/", "https://www.catnmsplan.com/specifications", "https://openlineage.io/docs/"] source_details = [{ title = "What is OpenTelemetry?", publisher = "OpenTelemetry project", url = "https://opentelemetry.io/docs/what-is-opentelemetry/", checked = "2026-09-09" }, { title = "Prometheus overview", publisher = "Prometheus project", url = "https://prometheus.io/docs/introduction/overview/", checked = "2026-09-09" }, { title = "Technical Specifications", publisher = "FINRA CAT", url = "https://www.catnmsplan.com/specifications", checked = "2026-09-09" }, { title = "About OpenLineage", publisher = "OpenLineage Project", url = "https://openlineage.io/docs/", checked = "2026-09-09" }] faq = [{ question = "Does a 100% request-success rate prove a complete report?", answer = "No. Events omitted before request creation are outside that denominator." }, { question = "Does a schema-valid file establish population completeness?", answer = "No. Field validation and coverage of required events answer different questions." }, { question = "Do matching row counts prove the same events were reported?", answer = "No. An omission and a duplicate can produce equal counts with different populations." }] evidence_as_of = "2026-09-09" related_articles = ["lineage-quality-reconciliation", "order-to-settlement-systems", "automated-fraud-screening-manual-review"] category_slug = "infrastructure" category_name = "Infrastructure" +++ Reporting completeness is coverage of a defined population of required events through a specified reporting cutoff and correction policy. A successful request rate measures attempted operations and can exclude required events that never reached the request stage. ## Operational success and the source population Operational telemetry describes service behavior through metrics, logs and traces. OpenTelemetry supplies instrumentation and transport components. These observations help locate processing failures, but their population depends on what the instrumentation observes. A report has a separate population: the events required under its purpose, entity scope and period. Completeness needs a comparison between that required population and the records represented in the reporting outcome. Take 1,000 required source events, of which 980 reach a submission worker. All 980 submission requests succeed. The worker’s request-success rate is 980 divided by 980, or 100%. Population coverage is 980 divided by 1,000, or 98%, under the assumed one-event-per-record mapping. Both percentages are arithmetically correct. The missing 20 events are outside the request-success denominator. Improving the precision of that percentage cannot make it detect events it never counts. ## Source events, transformed records and receipts The mapping from source events to submitted records must be explicit. Some reporting designs aggregate several events, split an event into several records or include corrections. Equal row counts therefore establish little without the required mapping. A submission receipt confirms the event defined by the receiving interface. Transport acceptance, format acceptance and completion of a corrected reporting obligation are separate states. Their labels need to preserve what actually happened. The Consolidated Audit Trail, or CAT, publishes specifications for defined reporting data and formats. Those specifications concern a particular program; they do not create one universal reporting schema. The applicable version and event population remain part of a scoped implementation. ## Omission, duplication and correction A completeness comparison retains the identifiers linking required events to reported records. It must distinguish an omitted event from a duplicate record and from a superseded version. A count can match while the identity population differs. Take one omitted event and one duplicate submitted in its place. The submitted count can equal the required count, but the populations are different. An amount total can also match by coincidence or offset. Population reconciliation requires the relationships needed to explain those cases. Corrections extend the state machine. An original record, a correction request and an accepted corrected result are different pieces of evidence. Overwriting the earlier record without preserving the relationship obscures which version was sent and which remains operative. ## Cutoffs and evidence ownership A completeness result needs its source population, extraction cutoff, transformation version, submitted population, receipts and unresolved exceptions. A later source correction changes the relevant comparison without retroactively changing what the earlier test actually established. Lineage identifies processing relationships. Quality checks test specified properties. Reconciliation compares the required and represented populations. Keeping those results separate makes an operationally successful but financially incomplete pipeline detectable. ## Scope of a healthy-service claim A healthy service has met its stated operational criteria for an identified observation population. That finding does not establish a complete report unless those criteria include the required population and its reporting states. What changes is the obligation and record mapping. The stable distinction is between successful processing of observed work and complete handling of required work. ## Questions about observability ### Does a 100% request-success rate prove a complete report? No. Events omitted before request creation are outside that denominator. ### Does a schema-valid file establish population completeness? No. Field validation and coverage of required events answer different questions. ### Do matching row counts prove the same events were reported? No. An omission and a duplicate can produce equal counts with different populations.