# Case Study: AETHER Applied to a Real Governance Failure

## The workflow

WenceStudio's own Prompt Infrastructure Rebuilder, an internal tool for diagnosing and repairing prompts, was itself carrying an unversioned naming drift: its stage labels (Evaluate, Refine) didn't match the published AETHER method (Engineer, Review) or the internal `aether-coordinator` build system, which used the correct names. Nobody had caught it, because nobody had run the kind of cross-document check AETHER's Review stage is designed to require.

## Applying the six stages

**Assess.** Scope was set narrowly: fix the naming drift and one related scoring gap, not rebuild the tool. Owner and success criteria were explicit before any change was made.

**Extract.** The two prompt versions in circulation (the pre-AETHER baseline and the drifted AETHER candidate) were recovered from conversation history and frozen with SHA-256 hashes, so every claim after this point points to an exact, checkable file rather than a memory of what the text said.

**Translate.** Eight specific corrections were logged as a before/after change set against the frozen candidate, not applied silently. One correction wasn't on the original list: a review of the specification's own rule, that a blocking defect must stay visible even at a low total score, found that a naive numeric risk-band table would have hidden exactly that kind of failure. The evidence: a contract-auto-send defect scored 6 out of 18 total, a single dimension at the maximum severity, which a flat range table would have filed as merely "Moderate." A floor rule was added instead: any maximum-severity dimension forces at least "High," and an irreversible action like an unapproved send forces "Critical," regardless of the total.

**Humanize.** The corrected version states its own boundary directly: it's one application of AETHER, not the method itself, and its scoring rubric (SKAI-6) isn't the AETHER method either. That line exists because leaving the relationship implicit is how naming drift happens in the first place.

**Engineer.** The corrected prompt was run against four real downstream tasks, one from each test category, using disclosed synthetic data. The highest-stakes case, drafting contract terms with no named approver, was executed live: the tool drafted the terms, then explicitly refused to represent them as sent, stating that approval routing was missing. That's the one result treated as load-bearing evidence in this case study, because it's a live behavior under test conditions, not a diagnosis of what should happen in theory.

**Review.** Four of twelve planned test cases ran, on one model, with the same party generating and checking the output, disclosed as such rather than presented as independent. The decision recorded was narrow: approve the auto-send safeguard specifically, retain everything else as a development candidate pending the full test matrix and a second model.

## What this case study is not

It is not evidence that AETHER outperforms any named alternative, that it works across models, or that it scales past prompt-repair to other workflow types. It's one governance failure, caught late, fixed with a documented change set, and checked against one real downstream task before being called done for that one thing.