test-driver/research/hypotheses/H-002-mechanical-adaptation.md

---
id: H-002
title: Mechanical Adaptation
status: EXPERIMENTING
created: "2026-08-22"
experiments: [E-001]
concepts: [C-adaptation]
---

# H-002 — Mechanical Adaptation

## Claim

An agentic driver can recover from a mechanical implementation change without
modifying the semantics of the protected use case.

## Falsification condition

Either:
- the driver fails to recover from a majority of labelled `MECHANICAL` mutations
  (recovery is not achievable in practice); **or**
- recovery is achieved only in runs where claims or invariants were altered
  (recovery is achievable but not semantics-preserving).

The second branch matters more than the first. A high recovery rate purchased by
weakening assertions falsifies this hypothesis just as decisively as no recovery
at all.

## Measurement

- Mechanical Recovery Rate over `MECHANICAL`-labelled mutations.
- Claim/invariant diff per run — expected to be empty by construction
  (`docs/TestDriverClassificationDesign.md` D-02). Any non-empty diff is both a
  falsification signal **and** a framework defect, since no write path should exist.

## Result so far (TD-WP-0002-T07)

Discovery recovered from 11 of 12 mechanical mutations with **no claim or
invariant diff in any run**, as D-02 requires structurally. The single failure
(M22, field names renamed) failed *loudly* — a `RealizationFailed` recorded in
evidence, not a silent pass. That distinction is the one that matters: the
framework reported that it could not act, rather than reporting that nothing was
wrong.

Full classification of recovery vs defect is T08.

## Status log

- 2026-08-22 `PROPOSED`.
- 2026-08-22 `EXPERIMENTING`. Recovery demonstrated; classification pending T08. Design decision D-02 makes the second falsification
  branch structurally unreachable; the measurement is retained anyway, as an
  assertion that the architecture is what we believe it is.