Form & Data UI Audit

Operation

Inspect the named boundary and report supported findings. Do not edit product code. Include concrete evidence, impact, the owning source, one remediation direction and a meaningful validation route. Severity follows actual impact, not a category example.

Goal and scope

Audit a form, editor, table, search, filter, pagination, or data-entry surface against validation and persistence contracts.

Domain invariants

• Field names, types, units, nullability, defaults, normalization, and validation agree with the authoritative API/schema.
• Dirty state, autosave, submit, duplicate submit, optimistic state, server errors, and conflict recovery are explicit.
• Sorting, filtering, pagination, selection, and bulk actions retain stable identity and tenant/permission scope.
• Labels, instructions, errors, focus, keyboard use, and screen-reader relationships remain accessible.

Audit method

1. Trace each changed field or data operation from UI representation to serialized request and persisted result.
2. Check client/server validation drift, timezone/locale/unit conversion, partial edit, refresh, back navigation, and conflicts.
3. Inspect table identity, cursor/page semantics, selection across pages, and stale query behavior.
4. Identify data loss, duplicate submission, misleading success, and inaccessible error recovery.

Priority model

• P0: a reachable flow that causes data loss, unsafe action, access leakage, or blocks a critical user journey.
• P1: a material task-completion, state, accessibility, or activation defect.
• P2: a lower-risk but concrete comprehension, consistency, or secondary-flow issue.