# CivicSS / CSKE Database Quality Control, Human Verification, and Reporting Safety Framework

> Public Atlas edition: private-local paths have been withheld from this distribution copy. The preserved source remains unchanged and is identified by its original SHA-256 in the Atlas release records.

**Version:** 1.0.0  
**Date:** August 25, 2026  
**Status:** Current platform description and control framework  
**Companion document:** CivicSS-CSKE-Platform-Operating-Control-and-Loading-System-Snapshot-v1.0.0-20260825.md  
**Purpose:** Explain what database quality means in CivicSS / CSKE, which controls exist, how new data is tested, how uncertain data must be kept out of publishable reporting, and what still requires human review.

---

## 1. The controlling quality principle

CSKE is designed to make municipal evidence easier to preserve, organize, reconcile, query, and explain. Its controls can establish specific facts about the platform, such as:

- whether a package is the exact package that was reviewed;
- whether a row has a unique key;
- whether a declared relationship points to an existing record;
- whether a value conforms to an allowed type or code;
- whether an expected population was loaded;
- whether reported totals reconcile to identified source evidence;
- whether a record is marked publishable, unresolved, excluded, or review-required;
- whether an accepted reporting query returns the expected bounded result; and
- whether a release passed its defined technical and data-quality tests.

Those controls are important, but they do **not** prove absolute truth.

> Nothing becomes an official, certified, audited, or unquestionably correct municipal fact solely because it is stored in CSKE, passes database constraints, reconciles mathematically, passes UAT, or appears in a reporting view.

The source may itself contain an error. A document may be incomplete. OCR may misread a value. A field may have been interpreted incorrectly. A valid relationship may connect the wrong real-world entities. A calculation may be internally correct but answer the wrong question. A figure may be accurate for one period or accounting basis and misleading for another.

For that reason, the system separates:

1. preservation of source evidence;
2. faithful extraction from that evidence;
3. normalization and relationship controls;
4. technical and reconciliation testing;
5. readiness for analytical reporting; and
6. human review and approval for official use.

The final step cannot be replaced by software.

---

## 2. What database quality means

Database quality is not one PASS or FAIL value. It is a collection of distinct qualities that must not be confused with one another.

### 2.1 Physical integrity

Physical integrity asks whether the database is structurally sound:

- Does every row have the required key?
- Are required values present?
- Are data types valid?
- Do declared foreign keys point to existing parent records?
- Do code values conform to allowed domains?
- Are indexes valid?
- Did the transaction complete atomically?

Physical integrity is necessary. It does not establish source accuracy or correct interpretation.

### 2.2 Source fidelity

Source fidelity asks whether CSKE accurately preserves what the source said:

- Is the exact source artifact identified?
- Is its checksum recorded?
- Is the original value retained?
- Can the record be traced to a page, row, cell, feature, or other source locator?
- Were blanks, zeros, suppressions, and unavailable values distinguished?
- Did extraction preserve the source's units, period, status, and terminology?

A source-faithful record can still reproduce an error that was present in the source.

### 2.3 Semantic correctness

Semantic correctness asks whether the data means what CSKE says it means:

- Is the record at the correct grain?
- Is a budget distinguished from an actual?
- Is a fiscal year distinguished from a calendar year?
- Is a report year distinguished from the measurement date?
- Is an estimate distinguished from an observed fact?
- Is a project distinguished from an asset, request, appropriation, expenditure, or lifecycle event?
- Are relationships connected to the correct real-world entities?

A value can be typed correctly and source-faithful while still being classified incorrectly.

### 2.4 Completeness and coverage

Completeness asks whether the expected evidence population is present:

- Were all expected source files acquired?
- Were all pages, worksheets, rows, features, schedules, or records processed?
- Were all in-scope entities, periods, departments, funds, and categories represented?
- Are gaps explicit?
- Does table existence conceal an empty or partially populated subject area?

Completeness must be evaluated against a defined source census. A table with zero errors may simply contain zero data.

### 2.5 Reconciliation and calculation correctness

Reconciliation asks whether the translated data agrees with defined source controls:

- Do row counts match the source inventory?
- Do subtotals and totals recompute?
- Do cross-foot and roll-forward checks pass?
- Are duplicates and omissions accounted for?
- Are exclusions disclosed?
- Are incompatible units, periods, and stages prevented from being added together?

Reconciliation demonstrates consistency with a defined test. It does not independently certify the underlying source.

### 2.6 Fitness for a reporting purpose

Fitness asks whether data is safe for a particular query or story:

- Does the view have a documented grain?
- Are periods, units, stages, assurance, and exclusions visible?
- Are unresolved candidates kept out of totals?
- Can the user drill back to evidence?
- Is the result current enough for the question?
- Does the query avoid double counting?
- Has the exact query contract been accepted?

Data may be useful for discovery but not safe for totals. It may be safe for one bounded question but not for another.

### 2.7 Human and official acceptance

Human acceptance asks whether an authorized reviewer has judged the source, interpretation, calculation, and presentation fit for the intended use.

Independent UAT is a strong control, but UAT is not automatically Town approval, Finance Committee approval, audit certification, legal approval, or acceptance of a public presentation. Those are separate acts by the appropriate people.

---

## 3. Current structural control environment

The accepted DB Architect assessment captured the following point-in-time physical census after release 0356 verification and before Master Control integration:

| Measure | Assessed count |
|---|---:|
| Base tables | 698 |
| Views | 292 |
| Sequences | 522 |
| Column records | 15,330 |
| Constraints | 10,523 |
| Foreign keys | 1,459 |
| Indexes | 2,022 |
| Base tables with primary keys | 698 of 698 |
| Invalid indexes | 0 |
| Constraints marked NOT VALID | 36 |

These figures are a dated architecture snapshot, not a claim about all later changes.

The snapshot shows a structurally capable database with extensive relational controls. It also shows material documentation, semantic-contract, and reporting-readiness work still to be completed.

### 3.1 What the main schema controls do—and do not do

| Control | What it protects | What it does not prove |
|---|---|---|
| Primary key | Each stored row has a unique database identity | The row represents a unique real-world fact or the correct natural grain |
| Unique constraint | A declared combination cannot be duplicated | The chosen combination is the correct business identity |
| Foreign key | A declared child value has a matching parent value | The child was linked to the correct real-world parent |
| NOT NULL | A value must be supplied | The supplied value is correct, meaningful, or source-supported |
| Data type | A value can be stored in the required technical form | A number has the correct unit, period, sign, accounting basis, or meaning |
| Check constraint | A row satisfies an encoded rule | The encoded rule is complete or the source fact is accurate |
| Reference table | A value uses an allowed controlled code | The selected allowed code is the right classification |
| Index | A query or integrity check may be supported efficiently | The result is correct or the workload is optimized |
| Transaction | An authorized change commits completely or rolls back | The intended data was correct before it was committed |
| Checksum | A file is byte-for-byte identical to the sealed file | The content inside the file is true or well designed |
| Migration ledger | A controlled database change was recorded | The release was complete, accepted for reporting, or integrated into Git and Master Control |
| Reporting view | Consumers receive a bounded representation | The view is governed, complete, current, or safe unless its contract says so |

### 3.2 Referential integrity

Referential integrity is one of the strongest relational controls in CSKE. A physical foreign key can prevent a child record from referring to a parent key that does not exist. It can also define what happens when a parent is updated or deleted.

It is important to distinguish four cases:

1. **Enforced physical relationship.** A valid foreign key is present and PostgreSQL enforces it.
2. **Unvalidated physical relationship.** A foreign key exists with NOT VALID status. It protects qualifying new changes, but PostgreSQL has not certified the entire historical population as validated.
3. **Logical or polymorphic relationship.** The relationship is represented by type and identifier fields that cannot safely point to one fixed parent table.
4. **Candidate relationship.** A similarly named identifier suggests a possible relationship, but its business meaning has not been proven.

At the architecture snapshot, 36 constraints remained NOT VALID: 34 foreign keys and two checks. Independent bounded profiling found zero current violations, which is valuable evidence. It does not change PostgreSQL's catalog trust state. They remain an explicit validation and governance item until a controlled release validates or otherwise resolves them.

The assessment also found identifier-like columns that were neither primary keys nor foreign keys. That is a review signal, not proof that each column should receive a foreign key. Source-native identifiers, external identifiers, and polymorphic relationships must not be mechanically converted into physical relationships without understanding their grain and meaning.

Foreign-key indexing is a separate performance question. The assessment identified many foreign keys without an obvious candidate supporting index. This does not prove a performance defect. Index decisions should be based on actual joins, update/delete patterns, row volumes, and query plans; indiscriminately adding hundreds of indexes would increase write and maintenance costs.

### 3.3 Type and code controls

The assessed database used reference tables, checks, and foreign keys rather than application-specific PostgreSQL enum or domain types. That can be a sound design because governed reference data is easier to extend and describe.

The risk is not the absence of enums by itself. The risk occurs when a column behaves like a controlled status or category but remains unconstrained free text. Every important code should therefore have one of the following:

- a foreign key to a governed reference table;
- a complete check constraint;
- an intentionally open vocabulary with documented rules; or
- an explicit unresolved/source-native treatment until mapping is approved.

### 3.4 Comments, catalogs, and contracts

Physical integrity alone does not make a database understandable. In the assessed snapshot:

- 515 of 698 tables lacked table comments;
- 218 of 292 views lacked view comments; and
- only 10 of 163 reporting views were represented in the centralized active contract catalog.

Those are important governance gaps. A name ending in **v1** does not by itself create a stable contract. A trustworthy reporting interface also needs a documented grain, keys, measures, units, periods, source coverage, exclusions, readiness rules, version, owner, and safe-use statement.

---

## 4. Quality architecture: evidence must remain distinct from accepted facts

CSKE's quality model follows a layered evidence chain:

**Source artifact → retrieval record → native page, row, cell, feature, or record → normalized entity or fact → relationship or lifecycle event → definition and unit → verification, exception, and reconciliation → stable reporting view**

This separation prevents several dangerous shortcuts:

- a source record is not automatically an accepted fact;
- a parsed value is not automatically a correctly interpreted value;
- an available row is not automatically adopted for reporting;
- an accepted database release is not automatically adopted by every report;
- an estimate is not an actual;
- a blank is not zero;
- a report year is not necessarily a measurement date; and
- a successful load is not proof of complete subject coverage.

### 4.1 Immutable evidence and correctable normalized data

Authoritative raw and source evidence should remain immutable. Corrections must not rewrite history or obscure what the source actually contained.

Normalized core data is different. If normalized data is demonstrably wrong, it must be corrected, removed, or explicitly marked unresolved through a controlled corrective migration. The system must not create endless parallel **fixed**, **corrected**, or **new** tables merely to avoid repairing the governed core.

The correction must retain:

- the original evidence;
- the prior normalized value when needed for audit history;
- the reason for correction;
- the correcting release and migration;
- the reviewer and verification evidence;
- the effect on reporting; and
- the replay and rollback behavior.

---

## 5. Quality statuses, missingness, and assurance

Quality cannot be represented by one generic **verified** flag. At minimum, CSKE distinguishes the nature of the source, the internal verification performed, the usability of the record, and whether an unresolved exception exists.

### 5.1 Standard assurance and quality vocabulary

The loader standard includes statuses such as:

- **PUBLIC_OFFICIAL**
- **AUDITED**
- **ISSUER_PREPARED_UNAUDITED**
- **SOURCE_RECONCILED**
- **CALCULATED_FROM_SOURCE_FACTS**
- **PROJECTED**
- **ESTIMATED**
- **PROPOSED**
- **REVIEW_REQUIRED**
- **UNRESOLVED_CONFLICT**
- **EXCLUDED_FROM_TOTALS**

These terms answer different questions. For example:

- **AUDITED** describes an external assurance state.
- **SOURCE_RECONCILED** describes an internal comparison to source controls.
- **CALCULATED_FROM_SOURCE_FACTS** describes derivation.
- **REVIEW_REQUIRED** describes incomplete acceptance.
- **EXCLUDED_FROM_TOTALS** describes permitted analytical use.

Reconciliation cannot turn an unaudited source into an audited source. A calculation from official data does not itself become an official Town calculation.

### 5.2 Missing is not zero

Missing values require explicit meaning. The standard vocabulary includes:

- **ZERO_REPORTED**
- **BLANK_IN_SOURCE**
- **NOT_APPLICABLE**
- **NOT_PUBLISHED**
- **NOT_YET_AVAILABLE**
- **SUPPRESSED**
- **SOURCE_NOT_ACQUIRED**
- **PARSER_NOT_IMPLEMENTED**
- **OUT_OF_SCOPE**
- **UNRESOLVED**

Reporting queries must not silently convert these states to zero. A zero affects sums, averages, rates, and time-series interpretations. Unknown or unavailable data must remain visibly unknown unless a specific, documented calculation calls for another treatment.

### 5.3 Quality-exception records

A durable quality exception should contain:

- a stable exception identifier;
- the affected domain, object, source, and record keys;
- a clear description of the issue;
- severity and materiality;
- whether the record may be used for discovery;
- whether it is excluded from totals or publication;
- current status;
- evidence required to resolve it;
- owner and next action;
- dates opened, reviewed, resolved, and adopted; and
- the release or correction that closed it.

The record should remain traceable after resolution rather than disappearing from the historical record.

---

## 6. Quality assurance for every new data source

Every new source should pass a controlled sequence. The depth of testing may vary with risk and complexity, but the categories should not be skipped merely because a file loaded without an error.

### 6.1 Source authority and acquisition

Before designing tables, the loader establishes:

- who produced the source;
- whether it is official, audited, issuer-prepared, third-party, estimated, or informal;
- its publication or effective date;
- how and when it was retrieved;
- the exact artifact inventory and checksums;
- any use, distribution, privacy, or confidentiality restrictions;
- whether a more structured authoritative version exists; and
- whether the acquired corpus is complete.

Credentials, personal-contact records, student-level information, and protected personal data are not copied into packages or chat transcripts.

### 6.2 Source census and coverage

The loader defines the expected population before claiming completeness:

- files and archive members;
- worksheets and named ranges;
- pages and sections;
- tables and schedules;
- records, rows, or GIS features;
- entities and departments;
- periods and measurement dates;
- source totals and control totals; and
- known gaps or inaccessible material.

This is the defense against the empty-table failure mode. Verification must test rows, subject coverage, periods, reconciliation, and source completeness—not merely whether table names exist.

### 6.3 Extraction and native preservation

Extraction tests should address:

- encoding and line endings;
- delimiters and quoting;
- expected field counts;
- worksheet, page, cell, row, or feature locators;
- OCR confidence and layout ambiguity;
- source-native labels and values;
- duplicate, omitted, rejected, and quarantined records; and
- reproducibility from the sealed source artifacts.

An OCR line should not be forced into a normalized fact when page interpretation is unresolved. It can remain preserved evidence awaiting semantic review.

### 6.4 Grain, normalization, and relational design

Before loading, the package defines:

- one natural grain for each table;
- stable database and business keys;
- entities, observations, events, relationships, and classifications;
- period, stage, status, version, unit, and measurement basis;
- reusable reference data;
- how slowly changing or historical facts are retained;
- how estimates, proposals, budgets, actuals, and forecasts differ;
- provenance from facts back to exact evidence; and
- intended reporting interfaces.

Repeated groups, encoded lists, unrelated facts in one row, and subject values hidden in JSON or free-form text receive design review. Normalization should improve meaning and reuse, not split data mechanically into more tables.

### 6.5 Payload quality tests

Before execution, the exact payload is tested for:

- uniqueness of declared keys;
- parent-child coverage;
- valid data types and controlled codes;
- allowed entity, geography, department, fund, and period populations;
- units, scale, sign, and precision;
- null, zero, suppression, and missing-state treatment;
- duplicate disposition;
- quarantine and exception disposition;
- record counts and control totals;
- formulas and derived values;
- provenance and source locators; and
- acceptance-query results.

The package should be built from the acceptance questions backward. If the intended reporting need is a complete population time series, the package must explicitly test the supported years, period basis, missingness, and source drill-through.

### 6.6 Package and migration quality

The executable package is separately tested for:

- complete manifest and checksum seal;
- exact input and output inventories;
- secret scanning;
- deterministic paths;
- one controlled command or entry point;
- migration order and ledger behavior;
- explicit mutation allowlist;
- protected-object fingerprints;
- transaction boundaries;
- safe failure and rollback;
- successful first run;
- idempotent or safely rejected replay;
- verification queries; and
- exact handoff evidence.

Prepared is not executed. Executed is not accepted. Database acceptance is not Git completion. Git completion is not Master Control adoption or reporting publication.

### 6.7 Independent UAT before and after execution

UAT is independent of the loader that prepared the package.

Before execution, UAT verifies the exact sealed version, source census, payload, reconciliation, mutation boundary, rollback behavior, replay behavior, and query contracts.

After execution, UAT verifies committed database state, protected boundaries, object and row populations, constraints, reconciliation, gap and quarantine populations, stable views, and accepted query examples.

UAT must test the assignment's real promise. A table-existence test cannot accept a promised normalized subject load. A row-count test cannot accept a promised complete time series without checking the supported period population and meaning.

### 6.8 Master Control and reporting adoption

Master Control records the accepted release, authoritative artifacts, objects, evidence, limitations, query contracts, and current governed state.

Reporting adoption is a later, explicit step. A reporter must:

- use the accepted view or bounded query contract;
- query the database fresh as required;
- confirm results against accepted examples;
- preserve status, assurance, provenance, and exclusions;
- disclose material missingness or limitations;
- record wrong, missing, non-normalized, essential-missing, and helpful-missing data; and
- obtain human review for any official use.

---

## 7. How suspect or unresolved records are kept out of reporting

The safe pattern is **preserve, classify, exclude, expose, resolve**.

### 7.1 Preserve

Do not delete or rewrite the authoritative raw evidence merely because it is suspect. Preserve the exact source and source-native record.

### 7.2 Classify

Record the appropriate verification, assurance, exception, and usability state. Examples include **REVIEW_REQUIRED**, **UNRESOLVED_CONFLICT**, or **EXCLUDED_FROM_TOTALS**.

### 7.3 Exclude

The governed publishable view or accepted query contract must explicitly exclude records that are not eligible for its stated use. Exclusion can occur at several levels:

- **Row level:** one fact is unresolved.
- **Relationship level:** the fact exists but its entity match is unresolved.
- **Aggregate level:** a subtotal cannot be published because its population is incomplete.
- **Subject or release level:** the loaded domain is not yet publishable.
- **View level:** only approved states are exposed through the stable reporting interface.
- **Report-adoption level:** the report has not yet adopted the accepted contract.

### 7.4 Expose

Excluded data must not vanish. A separate gap, quarantine, exception, or review view should show what is missing or unresolved without allowing it to be confused with publishable totals.

### 7.5 Resolve

Resolution requires evidence, a documented decision, a corrective release when data changes, independent retesting, Master Control adoption, and reporter adoption when applicable.

### 7.6 Conceptual query pattern

The following is a design illustration, not the name or definition of a current universal CSKE view:

~~~sql
SELECT
    fact_id,
    entity_id,
    period_id,
    amount,
    unit_code,
    assurance_status,
    verification_status,
    source_record_id
FROM governed_subject_fact
WHERE publishable_flag = true
  AND verification_status IN ('SOURCE_VERIFIED', 'RECONCILED')
  AND totals_exclusion_flag = false;
~~~

The companion review queue might use:

~~~sql
SELECT
    fact_id,
    source_record_id,
    verification_status,
    quality_exception_id,
    issue_description,
    evidence_needed,
    next_owner
FROM governed_subject_fact_review
WHERE resolution_status <> 'RESOLVED';
~~~

The exact allowed statuses depend on the subject contract. A projected or estimated value may be publishable in a clearly labeled forecast view while being prohibited from an actual-expenditure view.

### 7.7 Critical present-state qualification

CSKE has the control vocabulary, release gates, domain-specific status fields, quarantine patterns, and accepted-view method needed to block suspect data safely. Some migrations and tests already enforce review statuses for particular subjects.

However, the accepted architecture assessment did **not** establish that one universal database-wide suspect flag automatically protects every report. Only 10 of 163 reporting views were then present in the centralized active contract catalog.

Therefore:

> A record is proven blocked from reporting only when the exact accepted reporting view or bounded query contract enforces the exclusion, the relevant subject or release is publishable, and the report actually uses that accepted interface.

A direct query against a base table can bypass reporting safeguards. Base tables are not automatically report-authoritative. Reporters should use accepted stable views and query contracts, not infer safety from table names or row status alone.

Closing this gap requires:

- cataloging every stable reporting interface;
- documenting grain, allowed statuses, exclusions, and provenance;
- testing unresolved-record leakage;
- limiting official reporting to accepted interfaces;
- versioning contract changes;
- recording report adoption; and
- retiring or clearly labeling unsafe legacy views.

---

## 8. What cannot be assumed to be correct

Unless the specific claim has been tested and reviewed, **nothing should be presumed correct merely because it is available in the platform**.

| Observation | What may be concluded | What may not be assumed |
|---|---|---|
| The source is a Town document | The Town published or supplied the identified document | Every value is accurate, complete, current, audited, or internally consistent |
| A row exists in a table | The row was stored | It is accepted, unique in the real world, or safe for reporting |
| A primary key exists | Database row identity is unique | The table has the correct natural grain |
| A foreign key passes | The referenced parent key exists | The relationship is the correct business relationship |
| A value is NOT NULL | Something was supplied | It is known, correct, or meaningful |
| A numeric type is valid | The characters form a storable number | Unit, scale, sign, period, basis, and interpretation are correct |
| A checksum matches | The file is unchanged from the sealed copy | The file's content is accurate or complete |
| A loader completed | Its transaction or command completed as recorded | All promised data loaded or the mission is complete |
| Tables were created | Structure exists | Data was populated, normalized, or reconciled |
| Row counts match | The compared populations have the same number of rows | The same facts are present or correctly mapped |
| Totals reconcile | The encoded calculation agrees with the defined control | The source or interpretation is independently correct |
| No constraint is violated | Encoded structural rules pass | All business rules were encoded or semantic meaning is correct |
| UAT passed | The exact tested acceptance criteria passed | Every possible use is safe or an official body approved the result |
| A release is accepted in the database | The bounded database state passed its gate | Git, Master Control, reporting, deployment, or public use is complete |
| Git is clean and pushed | Tracked source history is reconciled | The database contains the intended data or reporting adopted it |
| Master Control recorded a release | Governed metadata was adopted | Every report has adopted the data |
| A view ends in v1 | A version-like name was used | The view has an active, complete, stable contract |
| A record is public | It may be obtainable as a public record, subject to law and policy | It is accurate, ethically appropriate for every reuse, or free of privacy concerns |
| OCR extracted a value | Software recognized text or layout | The value and its semantic context were interpreted correctly |
| Missing is displayed as zero | A software choice was made | The source reported zero |
| Two records share a name | Their text labels match | They represent the same person, asset, project, parcel, fund, or organization |
| Two GIS schemas have matching structures and counts | They matched on the tested dimensions at that time | They are permanently equivalent or both are canonical |
| Data is normalized | It follows the accepted relational design for its subject | It is accurate, complete, current, or approved |
| A source is audited | The identified source received the stated external assurance | Every transformation, calculation, join, or report built from it was audited |
| A report is visually polished | The presentation is clear and finished | Its data and conclusions have been reviewed or approved |

### 8.1 Known examples of why these distinctions matter

The architecture assessment identified several concrete cases:

- The Annual Town Report corpus contained 17 reports and 1,597 pages, yet 38 of 51 typed Annual Town Report subject tables were empty. Extensive evidence discovery did not equal normalized subject completeness.
- The Annual Town Report population series was present by report year, but most measurement dates were unspecified. The safe description is population stated in each Annual Report by report year, not automatically a consistently dated census series.
- The CNA correction state contained quarantined schedules and review-required records and was not publishable at the assessed point. Corrected storage did not equal reporting acceptance.
- Thirty-table GIS families existed in both the main and dedicated GIS schemas. Matching structure and row counts did not establish canonical ownership or permanent equivalence.
- Thirty-six constraints had no current observed violations but still remained NOT VALID in PostgreSQL.

These are not reasons to distrust the platform. They are examples of the platform correctly distinguishing evidence from unsupported certainty.

---

## 9. Human verification and approval

Human review should be proportional to the use.

### 9.1 Source and business review

A person knowledgeable about the source or subject should confirm:

- the correct source was used;
- its limitations and assurance were described accurately;
- fields and categories were interpreted correctly;
- the grain and period basis match the real-world concept;
- exceptions and exclusions are reasonable; and
- the data answers the intended question.

### 9.2 Independent technical and data UAT

UAT independently confirms the sealed package, execution boundary, database state, population, reconciliation, repeatability, and query examples. UAT should not simply repeat the loader's assertions.

### 9.3 Reporting review

For a material report, a reviewer should verify:

- the report used the accepted query contract;
- values match the accepted query output;
- periods, units, stages, and assurance are labeled;
- totals do not mix incompatible grains;
- missingness and exclusions are disclosed;
- source drill-through works;
- narrative statements do not exceed the evidence; and
- visual emphasis does not distort the result.

### 9.4 Official Town or Finance Committee use

If a report is to become an official presentation or official work product, the Town or Finance Committee should review and approve the supporting data used for that presentation. The analytical platform can provide the reporting structure and an exported review package, but official acceptance belongs to the authorized public body.

Until that happens, the working disclosure is:

> **CivicSS analytical working draft—not an official Town or Finance Committee report.** Prepared from the identified public and supplied sources for discussion and review. Source data has not been independently audited or certified by Sherie Schaefer. Do not use for an official presentation until the supporting data has completed Town and Finance Committee review.

This disclosure does not cure a quality defect. It makes the review state explicit while the defect or approval gate is addressed.

---

## 10. Minimum evidence required for a quality-controlled release

A complete release record should identify:

1. assignment and approved scope;
2. exact source artifacts, inventory, retrieval metadata, and checksums;
3. source authority and assurance;
4. expected and observed coverage;
5. natural grain, keys, relationships, periods, units, and statuses;
6. normalization and schema design;
7. provenance to exact source evidence;
8. missingness and exception treatment;
9. record counts, reconciliation, and acceptance queries;
10. migration, transaction, replay, rollback, and mutation boundary;
11. package manifest and checksum verification;
12. independent pre-execution and post-execution UAT;
13. protected-object and collision results;
14. Git closeout where applicable;
15. Master Control adoption;
16. reporting view and query contracts;
17. known limitations and prohibited uses;
18. report-adoption status; and
19. human approval required for official use.

If an item does not apply, the record should say why. Silence should not be interpreted as PASS.

---

## 11. Minimum reporter checklist

Before using CSKE data in a substantive report, the reporter should be able to answer:

- What exact accepted view or query contract am I using?
- What is one row?
- What periods, stages, units, and versions are represented?
- What source and assurance support the values?
- Is the subject and release publishable?
- Which records or populations are missing, quarantined, unresolved, or excluded?
- Are zeros true reported zeros?
- Could the joins or grouping double count facts?
- Do the results match the accepted examples?
- Is the data current enough for this story?
- Can a reader drill back to source evidence?
- Has the report itself adopted this version?
- What human review is still required?

If these questions cannot be answered, the reporter should stop using the result as a publishable fact and raise a data-quality or contract gap.

---

## 12. Current quality priorities

The accepted architecture work supports the following priorities:

1. **Complete the reporting contract catalog.** Every stable reporting view needs an active contract and leakage test.
2. **Make publishability machine-testable by subject.** Row, aggregate, release, and view readiness should be explicit.
3. **Validate or deliberately resolve the 36 NOT VALID constraints.**
4. **Add the missing Annual Town Report edition relationships before typed subject tables are populated.**
5. **Normalize high-value recurring time series with explicit measurement dates, units, assurance, and source drill-through.**
6. **Finish the Annual Town Report subject translations instead of treating evidence tables as subject facts.**
7. **Resolve CNA quarantine and review-required populations before publication.**
8. **Consolidate GIS canonical ownership through the approved staged migration and decommission controls.**
9. **Document table and view meaning, especially in public reporting interfaces.**
10. **Use real workload evidence before adding performance indexes.**
11. **Build human-readable quality dashboards for coverage, exceptions, publishability, and report adoption.**
12. **Require every report release to identify the exact accepted data contracts it used.**

---

## 13. Roles and accountability

| Role | Database-quality responsibility |
|---|---|
| Sherie / authorizing owner | Sets mission and material decisions; authorizes database mutation and major remediation; determines intended public use |
| CDX Loader PMO / Control | Maintains intake, assignment, writer collision control, gates, role routing, training standards, and durable handoffs |
| CDX DB Architect / Schema Control | Assesses relational design, normalization, integrity, canonical ownership, performance evidence, and architecture gates |
| Loader | Preserves sources, designs and prepares the governed package, proves source census and payload quality, and stays within the exact mutation boundary |
| UAT | Independently tests the sealed package, database result, completeness, reconciliation, normalization, replay, rollback, and query contracts |
| Master Control | Adopts accepted release state, authoritative artifacts, object inventories, limitations, and reporter handoffs |
| Reporter | Uses accepted interfaces, validates results against contracts, keeps limitations visible, and reports data defects and gaps |
| Town / Finance Committee reviewer | Reviews and approves supporting data for official Town or Committee use |

No role should silently perform another role's acceptance. Separation of preparation, independent testing, governance adoption, report adoption, and official approval is a feature of the control system.

---

## 14. Platform claim and limitation

The defensible claim is:

> CivicSS / CSKE provides a controlled, traceable process for preserving municipal source evidence, translating it into normalized data, testing structural and analytical properties, managing exceptions, publishing governed query contracts, and routing results for independent and human review.

The system should not claim:

> Everything in the database is correct.

Nor should it claim:

> A technically accepted result is an official Town conclusion.

Its value is not that it eliminates uncertainty. Its value is that it makes evidence, transformations, controls, uncertainty, exclusions, approvals, and corrections visible and repeatable.

---

## 15. Internal evidence basis

This framework consolidates the current platform controls and assessed limitations reflected in:

- the accepted CSKE Database Architecture and Schema Integrity Assessment v1.0.0;
- the current CSKE New Loader Window Training Package v1.1.0;
- the current CSKE UAT Window Training Manual v1.0.0;
- the current Master Control initialization and continuity materials;
- the current Loader PMO Control training materials;
- the Window-to-PMO direct-delivery protocol;
- current migration, test, quality-status, and reporting-contract patterns in the CSKE repository; and
- the companion platform operating-control snapshot stored in this directory.

Important internal locations include:

- **Database architecture role home:**  
  `CSKE / Database Architecture and Schema Control` (private-local path retained in the preserved source)

- **Current training-library entry point:**  
  `Training / 00 START HERE - WINDOW TRAINING LIBRARY.md` (private-local path retained in the preserved source)

- **CSKE Git repository:**  
  Private-local and remote repository locations are withheld from the public Atlas edition.

This document is a platform and process description, not an audit opinion, legal opinion, security certification, or guarantee that every historical object already implements every stated target control.

---

## 16. Copyright, attribution, and use

Copyright © 2026 Sherie Schaefer. CivicSS™ and the Civic Stewardship Knowledge Engine / CSKE framework are identified as Sherie Schaefer's analytical and reporting system concepts and working platform, subject to any separately documented ownership, license, public-body, employment, volunteer-service, or third-party rights.

This document describes current controls and intended operating boundaries as of its date. It should be versioned when material database-quality, reporting-safety, or human-approval practices change.