08 — Data and Database Management Checklist#

Review data ownership, schema design, migration safety, transactional correctness, data quality, and lifecycle management. This checklist covers the integrity and governance of information throughout its use; apply the separate Security, Legal, Reliability, and Performance checklists for their deeper controls.

Scope: Frontend-specific. This file is one part of the 08_Data_and_DatabaseManagement.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

• Project / product:
• Release / version / environment:
• Scope and applicable jurisdictions / markets:
• Database engines / storage platforms:
• Critical data assets and data owners:
• Reviewer / owner:
• Review date:
• Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

1. Copy this template to a project-specific review; leave all checkboxes unchecked in the shared repository.
2. Mark [x] only after verification from schema definitions, migration tests, quality metrics, data dictionaries, lifecycle policies, or other relevant evidence. Record failed items and documented N/A reasons in project records or issues keyed by DATA ID, not in this shared checklist.
3. Apply storage-specific controls according to the actual data stores and interfaces. Relational constraints, transaction isolation, partitioning, and OpenAPI are not universal requirements for document, key-value, graph, or other stores.
4. Review ## API Checks and ## Frontend Checks separately for each applicable product surface, with explicit N/A rationale where necessary.
5. Revisit the checklist after material data-model changes, new integrations, data migrations, changed processing purposes, or updates to privacy/retention obligations. Consult qualified legal and privacy specialists for jurisdiction-specific obligations.

Integrity and quality#

• DATA-044 Identify and enforce business invariants at an appropriate durable boundary, not only in frontend validation.

Frontend Checks#

• DATA-104 Ensure forms display clear field labels, required status, units, formatting guidance, and acceptable values.
• DATA-105 Validate inputs for prompt feedback while relying on authoritative server-side or database validation for integrity.
• DATA-106 Display field-level and summary error messages that preserve previously entered valid data.
• DATA-107 Distinguish missing, null, zero, empty string, and unavailable values correctly in user interfaces.
• DATA-108 Format dates, times, timezones, numbers, and currencies consistently with the user's locale and the underlying data semantics.
• DATA-109 Prevent accidental duplicate submissions of transactional or high-impact actions and expose completion status.
• DATA-110 Handle concurrent edits or stale versions with meaningful conflict feedback rather than silently overwriting data.
• DATA-111 Communicate unsaved changes, autosave progress, and failed saves before users navigate away or close a workflow.
• DATA-112 Treat server-confirmed state as authoritative when optimistic UI updates fail, and provide a recovery path.
• DATA-113 Show stale or cached data warnings when freshness could materially affect user decisions.
• DATA-114 Preserve stable record identity and selection through pagination, filtering, sorting, and refreshed results.
• DATA-115 Ensure loading, empty, deleted, forbidden, and failed data states are distinguishable and recoverable.
• DATA-116 Do not expose sensitive data in browser storage, URLs, analytics events, or diagnostic output without a documented approved need.
• DATA-117 Clear or partition private client caches appropriately on logout, account switching, or permission changes.
• DATA-118 Check that deleted or corrected records disappear or update in relevant UI views and accessible search results.
• DATA-119 Provide understandable confirmation and progress for data export, correction, or deletion requests when supported.
• DATA-120 Keep imported or uploaded file validation feedback actionable, including rejected rows and partial success.
• DATA-121 Make large tables, filters, and data visualizations understandable to keyboard and assistive-technology users.
• DATA-122 Verify long text, unusual characters, null values, and internationalized content render without corruption or clipping.
• DATA-123 Check user-facing data summaries and totals against authoritative values after refresh or reconciliation.
• DATA-156 For applications using IndexedDB or another versioned local database, test upgrades from every supported schema version, interrupted upgrades, and multi-tab versionchange or blocked-connection handling without silently losing records.
• DATA-157 Test browser-local database quota exhaustion, storage eviction, private-browsing limitations, and denied persistence requests; protect or clearly disclose the risk to unsynchronized user edits.
• DATA-158 For offline-first local databases, verify crash-safe mutation queues, reconnect replay, deduplication, and conflict resolution against server state after prolonged offline or multi-device changes.

Release gate#

• Critical datasets have identified owners, documented data definitions, authoritative sources, and appropriate access/classification boundaries.
• Schema and migration changes have been reviewed and tested against realistic data volumes and compatible application versions, with a credible path to recovery or remediation.
• Business-critical invariants, transaction and concurrency guarantees, and data-quality checks have been validated; material discrepancies are reconciled or have accepted remediation plans.
• Data retention, deletion, and archival controls have documented purposes and responsible owners, including relevant downstream and derived data copies.
• API and frontend data contracts are consistent with authoritative semantics and remain compatible with the proposed release, where those interfaces exist.
• Unresolved integrity, schema-change, or lifecycle risks have a named owner, priority, deadline, and authorized disposition recorded outside this shared template.

Domain-specific approval rule: Do not approve a release when critical records can be corrupted or silently lost, required migrations lack a safe plan, authoritative data ownership is unresolved, or significant retention and lifecycle risks remain unaccepted. Passing this review does not establish privacy-law compliance, database recoverability, or security certification.

Trusted references and scope#

The following primary sources inform these practical verification questions. The checks are not direct quotations of standards and do not imply that one data architecture is universally required.

• PostgreSQL — Constraints — database-level uniqueness, checks, keys, and referential integrity.
• PostgreSQL — Concurrency Control — transaction isolation, locking, and consistency under concurrent access.
• PostgreSQL — Modifying Tables — schema evolution and constraint changes.
• PostgreSQL — ALTER TABLE — schema changes, lock behavior, and constraints in live databases.
• Microsoft Azure Well-Architected — Data platform considerations — governance, consistency, and schema evolution.
• Microsoft Azure Well-Architected — Partitioning data — partition management, consistency, and lifecycle implications.
• AWS Well-Architected — Data classification — classifications and related data protection/lifecycle decisions.
• AWS Well-Architected — Data lifecycle management — handling, retention, transformation, and disposal policy.
• AWS Well-Architected — Back up data — recovery prerequisites for critical data and configurations.
• UK ICO — Storage limitation — personal-data retention and erasure considerations where applicable; guidance is under review.
• OpenAPI Specification — machine-readable API data contracts when applicable.
• MDN — Using IndexedDB — local database upgrade and transaction behavior.
• MDN — IndexedDB blocked event — handling parallel-tab upgrades.
• MDN — Storage quotas and eviction criteria — eviction and quota failures.
• MDN — Background Synchronization API — offline replay patterns and limited browser support.

Applicability: PostgreSQL-specific constraints and transaction behavior apply only to PostgreSQL or as illustrative relational concepts; verify equivalent capabilities for other engines. The UK ICO source is relevant only where the applicable data-protection framework requires it and is currently under review; do not apply UK-specific duties automatically to other jurisdictions. This checklist does not replace qualified legal, security, or data-architecture review.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

• Test focus: migrations, constraints, permissions, data integrity, rollback, and concurrent writes; include browser and client behavior where applicable.
• Cross-stack: pgTAP + Testcontainers.
• Python: testcontainers-python + Pandera + pytest; for pytest-based suites, run python -m pytest -q.
• TypeScript: Testcontainers + Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
• JavaScript: Testcontainers + Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
• Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

• data-quality-frameworks — Evaluate integrity and data-quality checks (wshobson/agents, 42,437 repo stars).
• database-migration — Review schema changes and rollback risks (wshobson/agents, 42,437 repo stars).
• property-based-testing — Find integrity and transaction edge cases (trailofbits/skills, 8,150 repo stars).

How to check: In a project-specific copy, have the agent audit the frontend scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.