- Product defect
- The product behaves incorrectly, contradicts its intended decision model, creates a dead end, or presents an unsafe or misleading customer state. Example: A page displays “Review work-from-home requirement” even though the environment cannot execute the work-from-home question. Customer consequence: The visitor reaches a dead end or receives an untrustworthy decision. May require product remediation.
- Test defect
- The test expectation, fixture, locator, or assertion is incorrect even though the intended product behavior works. Example: A diagnostic expected the message field’s accessible name to equal one exact string even though the field was correctly labelled and described. Customer consequence: Delivery is blocked by faulty evidence rather than faulty product behavior. May require test remediation.
- Evidence-harness defect
- The mechanism used to create or retain evidence fails before it can validly judge the product. Example: An evidence package could not start because its output directory or attestation-output contract was invalid. Customer consequence: The product remains unadjudicated; no pass or failure may be inferred. Requires valid evidence before judging the product.
- Continuous-integration defect
- The automated integration pipeline, test runner, or build orchestration changes or destabilizes the evidence environment. Example: Automatic Continuous Integration (CI) Git-diff capture changed the checkout to a shallow repository after browser tests, invalidating later source-custody checks. Customer consequence: Release evidence cannot be trusted until the pipeline behavior is corrected. Requires pipeline or test-runtime remediation.
- Environment defect
- The deployed or test environment is incompatible with the approved source, schema, runtime, access, viewport, or binding contract. Example: A QA database lacked required foundational tables, so the customer journey could not be executed end to end. Customer consequence: Product behavior remains unproven in that environment. Requires environment reconciliation or a new environment.
- Quality Assurance (QA)
- The independent validation activity or role that challenges source and intended product behavior. Quality Engineering is the broader team or function. Quality Assurance is the independent validation activity or role; neither label is a claim of extra staffed headcount.
- Continuous Integration (CI)
- Automated source, build, test, security, and evidence checks performed when changes are integrated. CI may block release. CI cannot approve its own exception. A passing CI check does not replace human product ownership or UAT.
- Agent Customer-Journey Simulation (M2A)
- A deterministic agent simulation that exercises frozen personas across required product paths. M2A can expose path defects and contradictions, but it cannot establish human understanding.
- Agent Customer-Journey Simulation, Round 2 (M2A-R2)
- A deterministic second-round simulation that evaluates frozen personas across required product paths. Official M2A-R2 is not executed and not authorized. It is agent simulation, not human research or human-comprehension evidence.