The most useful thing this source gives a metrics reader is a structure, not a verdict. A blog post from BEA describes the data quality framework developed by the U.S. Federal Committee on Statistical Methodology (FCSM), a group of senior statisticians from across the federal government. At the top level the framework has three domains: utility, objectivity, and integrity, which the post loosely glosses as usefulness, accuracy, and adherence to standards.
Below that, each domain has dimensions. The post names two examples: timeliness and granularity sit under utility, while accuracy and reliability sit under objectivity, and security and confidentiality appear under integrity. Treat those as illustrations, not a complete inventory — the source says "two of" and "dimensions of," not "all of."
For anyone building or auditing an indicator dataset, this is a workable skeleton. What follows is a method page that separates what the source actually says from the adaptation built on top of it.
What the source states plainly
The post opens by conceding that "data quality" does not excite most people, and that statisticians around the world have yet to agree on a common definition. In the United States, the author observes, there seems to be convergence on a framework. That framing is important: convergence is not adoption, and a blog post is not a standard.
The author of the BEA blog post calls the FCSM framework comprehensive and intuitive and says it is the best way they have come across to think about data quality. Those are the author's judgments, not measured results. Nowhere does the post present a scoring scale, weights, thresholds, or a worked example of applying the framework to a specific dataset.
The three domains, as described:
- Utility — glossed as usefulness. Named dimensions include timeliness and granularity.
- Objectivity — glossed as accuracy. Named dimensions include accuracy and reliability.
- Integrity — glossed as adherence to standards. Named dimensions include security and confidentiality.
Note the overlap that trips people up: accuracy appears both as the loose gloss for objectivity and as a named dimension inside objectivity. When you operationalize this, keep the domain label and the dimension label distinct in your notes, or your audit trail gets confusing.
The three domains side by side
| Domain | Loose gloss in source | Dimensions named in source | Typical question for an indicator dataset |
|---|---|---|---|
| Utility | Usefulness | Timeliness, granularity | Is it current enough and fine-grained enough for the decision at hand? |
| Objectivity | Accuracy | Accuracy, reliability | Does it measure what it claims, and does it repeat? |
| Integrity | Adherence to standards | Security, confidentiality | Is it protected and handled to stated rules? |
The fourth column is this article's adaptation, not the source's wording. It converts each domain into a question a pipeline owner can answer, which the source does not attempt.
A repeatable checklist you can apply
The source offers no procedure, so the following is an original adaptation built on the three domains. Score each dimension 0, 1, or 2: 0 for unknown or absent, 1 for partial or undocumented, 2 for documented and reproducible. Record the evidence next to each score — a version hash, a retrieval timestamp, a coverage note.
- Timeliness — is there a stated publication lag and a last-updated field you can read programmatically?
- Granularity — can you recover the unit of observation, and does aggregation lose a level you need?
- Accuracy — is there an independent or revised benchmark you can compare against?
- Reliability — if you pull the same series twice under identical parameters, do you get the same values?
- Security — is access controlled and logged?
- Confidentiality — are suppressed or masked cells documented as such?
The value of scoring the same six dimensions on the same scale across several datasets is comparability. It forces you to write down why a number got a 1 instead of a 2, which is exactly the audit trail that a prose assessment usually skips.
Worked example (Hypothetical)
Suppose a reader audits an indicator feed and fills in the six dimensions: timeliness 2, granularity 1, accuracy 2, reliability 1, security 1, confidentiality 2. The sum is 9 out of a possible 12, which is 0.75, or 75%. If a later revision documents the aggregation level and adds a reproducibility note, granularity rises to 2, taking the total to 10 out of 12, about 83.3%.
Both figures are Hypothetical and are pure arithmetic on an invented scale. They carry no information about any real dataset, and they are not a quality certification. The point is that the movement from 75% to about 83.3% is traceable to two named dimensions, which is what makes the score usable in a review.
Where readers usually go wrong
Two failure modes dominate. First, treating the domain glosses as definitions — calling objectivity "accuracy" and then stopping there loses reliability, which is a separate property. Second, treating the example dimensions as the full list. The source names a handful; it does not claim completeness for the dimension layer, so a checklist built only from these names will miss things like coherence or accessibility that other frameworks might raise.
Keep the checklist open-ended at the dimension level and fixed at the domain level. That way you borrow the framework's spine without pretending the source blessed every line item.
What the source does not say
Several things a careful reader might expect are simply absent. The post does not provide a formal definition that statisticians have agreed on; it states the opposite. It does not list the full set of dimensions under each domain, only examples. It offers no weights, scoring scale, or acceptance threshold, and no worked application to a concrete dataset.
It does not claim the framework has been formally adopted as a standard; the language is convergence, not mandate. Nor does it rank the domains, assert that one is more important than another, or describe how BEA itself scores its products. The blog author's assessment that the framework is comprehensive and intuitive is an opinion, not a measurement — useful framing, but not evidence of performance.
There is also nothing on how revision cycles should be handled, how to reconcile conflicting sources, or whether the same dimensions apply with equal weight to real-time and historical data. Those gaps are precisely where your own documentation has to do the work.
How to use this in practice
Start from the three domains verbatim, keep the named dimensions as a floor rather than a ceiling, and add your own evidence column. Apply the same scale to every dataset in a comparison so the numbers mean something across rows. When you publish the score, publish the per-dimension evidence next to it, because the sum alone persuades nobody and hides exactly the disagreement that matters.
Finally, label your adaptation as an adaptation. The BEA blog post supplies a vocabulary; the scoring routine is a construction layered on top, and a reader who recomputes it should be able to see where the source ends and your method begins.