Deviation and drift

Specifications and systems drift apart over time. People and agents discover mid-build that a spec is wrong, hotfixes slip in outside the loop, and assumptions quietly go stale. Aigile treats all of this as a normal part of the work. Experience with earlier methods suggests that teams which treat drift as shameful end up with hidden drift instead of less of it, so the goal here is fast detection and repair rather than a spotless record.

During the build: the deviation protocol

One observable question sorts every discovery: what would have to change to accommodate it?

When acceptance tests, public interfaces, or the constitution would have to change, the deviation counts as behavioral, and work on that slice stops. An example from the order system: mid-build, the agent found that the spec assumed one currency per billing entity, while a real customer had entities trading in two. Since the acceptance tests would have to change, the agent stopped and wrote a short report instead of picking a solution:

# Deviation report: reconciliation view / slice 4
Classification: BEHAVIORAL (acceptance tests must change)
Budget: decision within 1 hour. Default on silence: option (a).

The spec assumes one currency per entity. Entity 4711 in the pilot
data trades in EUR and CHF.

Options:
(a) per-currency sub-invoices: spec change small, matches how the
    customer books today
(b) single invoice with mixed-currency lines: larger UI change,
    tax handling unclear
(c) exclude multi-currency entities from this slice: fast, but the
    pilot customer needs 4711

Two humans decided within forty minutes, chose option (a), and the spec fix shipped in the same pull request as the code. That last step is a firm rule in the method, because a deviation that gets fixed in code only turns into drift a little later.

When only internals would change and all tests still pass, the deviation counts as an implementation detail. Work continues, and a one-line note goes into a log that the retrospective reads later. In both cases, the party that wants to deviate does not judge its own case; the classification follows from the artifacts.

After the fact: the drift pipeline

Drift that is found late gets handled the way bugs are handled, in four stages.

Prevent. Spec changes travel with code changes, as above. Beyond that, specs are written to say what must stay true rather than what happens to be true. A comparison shows why this matters:

Drifts in weeks:  "Orders are stored in table `orders` with
                   columns id, entity_id, amount_cents, ..."
Holds for years:  "Orders survive process restart and are
                   queryable by customer within 500 ms."

Every line of the first kind carries an ongoing maintenance cost, so the method prefers the second kind wherever possible.

Detect. A conformance check reads specs against code and reports contradictions, for example: “spec section 2.1 claims idempotent retries; the retry path lacks deduplication.” In a small team, this check is a fifteen-minute, agent-assisted ritual inside the retrospective. A standing conformance agent becomes worthwhile only when that ritual keeps finding real drift, which is a sign that the spec surface has outgrown it.

Triage. When only prose is wrong, the fix is cheap and gets batched. When code violates written intent, a defect story is opened. When the two truth sources contradict each other, the case escalates to the amendment process.

Learn. A spec section that drifts repeatedly carries information. Either it says too much and should be demoted or deleted, or it states something fundamental that keeps being broken and should be promoted into the constitution, where breaking it stops the line.

The health number for all of this is the drift half-life: the time from a gap appearing to the gap being fixed. In the example project, descriptive findings were resolved in a median of six days. A rising finding count combined with a falling half-life usually indicates a detection process that works, rather than a project in decline.

Full treatment: When specs and code disagree.