Chapter 07 · Evolving practice
What does it take before a stored value is safe to use?
No single software control proves that a number is true. A value becomes safer to use only when its source, meaning, completeness, calculations, exclusions, reporting purpose, and required human acceptance have each been tested—and the remaining uncertainty stays visible.
What the evidence shows
What supports this answer
- The quality framework separates seven questions that are often blurred together: physical integrity, source fidelity, semantic correctness, completeness, reconciliation, fitness for a reporting purpose, and human or official acceptance.
- The dated architecture snapshot found 36 constraints still marked NOT VALID. Bounded checks found no observed violations, but that does not change PostgreSQL’s catalog trust state.
- Only 10 of 163 reporting views in the reviewed scope were represented in the centralized active contract catalog, so the catalog is not yet a complete safety boundary.
- The governing suspect-data method is preserve, classify, exclude, expose, and resolve—not delete, silently repair, or turn missing into zero.
Why it matters
How this changes the question
A polished report can still be wrong if the source was wrong, a field was misunderstood, part of the population was missing, or an exclusion was bypassed. This layer makes “safe for this exact claim” a visible conclusion instead of an assumption.
How it was created
The working method
- 1
Trace the claim from source and native locator through normalized fact, definition, calculation, exception, and accepted reporting view.
- 2
Keep missing, not applicable, not collected, not stated, uncertain, and true zero as different states.
- 3
Require the report to use the exact accepted view or query contract that enforces publishability and exclusions.
- 4
Reconcile row counts, totals, and known exceptions for the stated reporting purpose.
- 5
Keep human verification and official Town acceptance separate from technical UAT.
Limits and unresolved work
What this does not yet prove
- CSKE does not yet have one proven universal suspect-data filter that protects every possible report or direct base-table query.
- The architecture counts and control gaps are a dated snapshot and may change through later governed releases.
- Technical acceptance does not make a fact independently audited, certified by Sherie Schaefer, or officially approved by the Town.
Open the working evidence
Documents included in this shareable edition
Sources and methodology
These are the principal materials used for this chapter. They establish provenance, not an assertion that every source is complete, current, or officially adopted.
- CivicSS-CSKE Database Quality Control, Human Verification, and Reporting Safety Framework v1.0.0, August 25, 2026.
- The chapter describes the framework’s point-in-time evidence and does not claim a universal certification of CSKE data.