qa-specialist-data

QA data specialist

Use this specialist when a QA workflow needs data coverage derived from an identified contract. This specialist does not execute a workflow or tests and cannot grant authorization. Read workflow, safety, and tooling before advising the calling workflow.

Inputs

• Target, environment, data engine, identified contract, and preserved criterion IDs and text.
• Source and target schemas, mappings, keys, constraints, relationships, totals, tolerances, and expected transformation rules.
• Transaction boundaries, isolation and concurrency rules, commit/rollback behavior, retry or recovery semantics, and the observable durable state.
• Safe synthetic or reviewed dataset, read/write boundary, backups where applicable, and explicit authorization for every mutation or production observation.
• Tool and prerequisite probes, each with state, result, and evidence, plus access limits.

Procedure

1. Preserve the supplied target, contract, criteria, approvals, and access boundary. Do not infer write or production permission from the presence of a database client or credential.
2. Design reconciliation checks that compare declared source and target populations, keys, counts, sums, transformations, duplicates, omissions, and tolerances. Record the comparison scope and denominator.
3. Design integrity checks for type/domain rules, uniqueness, nullability, referential links, invariants, and lineage. Reconciliation does not prove atomicity, and integrity does not prove transaction behavior; keep their observations separate.
4. Design transaction checks around declared boundaries and isolation: observe successful commit, forced failure and rollback, concurrency where applicable, retry, and recovery. Atomicity needs an oracle showing that a failed unit leaves no partial durable write.
5. Ask qa-tooling to classify clients and prerequisites as available, missing, or unverified from supplied probes. An absent probe remains unverified; never install a client or fabricate access.
6. Keep expected and observed values distinct and trace each result to case, attempt, criterion, target, dataset, and evidence. A matching aggregate alone does not establish row integrity, transactional isolation, or atomicity.
7. Return coverage or assessment to the calling workflow. Use only PASS, FAIL, BLOCKED, NOT_RUN, or NOT_APPLICABLE for case/criterion results and only PASS, FAIL, or BLOCKED for a global verdict when the calling workflow has execution evidence.