When a Single Source of Truth Migration Leaves Stale State Behind

1. What happened

On August 11, 2026, technical-document-workflow adopted active/WORK_STATUS.md as the sole mutable status authority. The duplicated current-state block in §3 of AGENTS.md was removed, and the rule “do not duplicate current state in this document” was adopted.

However, §4 of the same AGENTS.md still contained mutable TOP-04-specific current-state prose. At bba09278, WORK_STATUS already described TOP-04 FORMAL DRAFT CONSTRUCTION and a FIXED_FOR_DRAFT center thesis, while §4 still described initial Evidence construction, a research hypothesis, and no formal-text progression. The §4 copy was already inconsistent with WORK_STATUS at the migration commit.

After that, the TOP-04 formal draft became DRAFT FINALIZED / HUMAN APPROVED, and WORK_STATUS plus related project documents were updated. The discrepancy with AGENTS §4 widened, but those later updates did not create the staleness. On October 12, 2026, the current-state ownership at issue in §4 was changed to reference WORK_STATUS instead.

2. The apparent contradiction

The case is easy to misread because all three of these statements were true:

• The correct canonical state existed.
• Later work updated that canonical state.
• Another document still contained an older current state.

If SSOT is treated as a mechanism that automatically rewrites every old copy, the outcome looks contradictory. It is not. SSOT transfers authority; it does not automatically erase legacy copies. If removal or reference conversion is not part of the migration, stale state can remain outside the canonical update path.

3. Timeline

1. 2026-08-11 / bba09278 — WORK_STATUS became the sole mutable status authority and the duplicated §3 state block was removed. WORK_STATUS already described TOP-04 FORMAL DRAFT CONSTRUCTION / FIXED_FOR_DRAFT while §4 still described the earlier evidence-construction and hypothesis state, so §4 was already inconsistent.
2. 2026-08-11 / d8ff5cc2 — The TOP-04 formal draft became DRAFT FINALIZED / HUMAN APPROVED, and WORK_STATUS plus related project documents were updated. Later chapter order, final citations, artwork, and PDF work remained separate. AGENTS.md was not a target of that change.
3. 2026-08-22 / 74d2b9e9 — README was synchronized with the current work status. The legacy state in AGENTS §4 remained.
4. 2026-08-25 / 779a735 — AGENTS.md itself was edited to add the release artifact boundary, but the §4 legacy state remained.
5. 2026-09-24 / 7ac8ecde — AGENTS.md itself was edited to adopt Project-DF routing policy and strengthen authority boundaries. The §4 legacy snapshot nevertheless remained.
6. 2026-10-04 / 82be6ba — AGENTS.md itself was edited to add the external concept mapping rule, but the §4 legacy state remained.
7. 2026-10-12 / d023db44 — The mutable current-state duplication at issue in AGENTS §4 was removed, and current target, next gate, evidence authority, and per-Top current state were changed to reference WORK_STATUS.

This chronology establishes the sequence of canonical updates and the later removal of the legacy copy. It does not establish the contemporaneous thoughts or intentions of the people doing the work.

4. What changed in the SSOT migration

The initial migration succeeded in naming one canonical authority. WORK_STATUS owned current state, while other entry documents were expected to point to it. That was an authority migration.

A migration also has a second side. Mutable values left in older documents must be either (a) removed, (b) converted into references to the canonical source, or (c) explicitly separated as historical records that no longer own current state. In this case, §3 was reorganized in the first direction, but the specific state prose in §4 was left unresolved.

Conceptual before/after

BEFORE

AGENTS §3: current state belongs only to WORK_STATUS

AGENTS §4: current target = TOP-04

AFTER

AGENTS §4: current target / next gate / evidence authority
          / per-Top current state are read from WORK_STATUS
          rather than duplicated here

“Before” is a conceptual illustration of two roles coexisting; it is not a verbatim quotation of the complete file.

5. What was left behind

The residue was not merely explanatory prose. The TOP-04-specific prose in §4 described a current target and work boundary, so it functioned as mutable current-state value. AGENTS.md therefore said, in one part, not to duplicate state while still holding part of that state in another section.

This mixed document role is important. Is AGENTS.md a durable worker-rule document, or is it also a current-state document? When another file is canonical for ephemeral current state, keeping those values in the durable policy document makes the ownership boundary ambiguous.

6. Why later updates did not fix it

The later state updates did not leave the copy behind because the update procedure was wrong. In d8ff5cc2, WORK_STATUS and related project documents changed, while AGENTS.md did not. That is the observed changed-file set; the commit does not establish a recorded authorization set, why AGENTS was excluded, or any lack of authority to change it.

FRAMEWORK_SPEC §4.2 in E1 states that mutable state updates normally target WORK_STATUS and that other documents change when role or reference conditions require it. The record therefore does not support saying that d8ff5cc2 lacked authority to repair AGENTS §4.

AGENTS.md itself was later edited by 779a735, 7ac8ecde, and 82be6ba, but the §4 legacy state remained. The history does not establish why it remained. Persistence therefore cannot be explained only as AGENTS being outside a later state-update path.

The bounded write scope itself is not treated as the defect. More precisely, migration residue existed from E1, the relevant state-update path did not repair it, and later AGENTS edits also left it intact.

7. Why normal validation could still pass

The history cannot reconstruct every validation command used at the time, so this article does not claim that a particular test passed. It makes a narrower observation about what was and was not directly checked by the visible change history.

The recorded changes were coherent within their intended files and scopes. But the stated semantic invariant — that AGENTS should not retain duplicated mutable current-state values — was not fully satisfied or verified for the §4 material after the first migration.

Diff and syntax checks do not automatically show whether another file contains a semantically equivalent state. This is not a general claim that those checks were inadequate; it is a distinction between validating changed-file mechanics and validating a cross-document semantic invariant.

8. Cause and boundaries

These labels organize the RCA for this case. They are not a proposed taxonomy, Gate, framework, or standard classification.

9. “Refreshing the value vs. fixing the ownership structure”

Refreshing the value

One option would be to rewrite the TOP-04 value in AGENTS §4 to the latest value. Updating a copied value is not universally wrong. For example, 74d2b9e9 legitimately refreshed README because README is a subordinate summary with an explicit WORK_STATUS-wins boundary.

For AGENTS §4, however, writing the value back would temporarily reduce the visible discrepancy while leaving mutable state ownership in a section whose adopted design says current state should not be duplicated.

Fixing the ownership structure

In d023db44, the duplication at issue in AGENTS §4 — current target, next gate, current evidence authority, and per-Top current state — was removed, and those values were to be read from WORK_STATUS instead. The change removed ownership of the old value rather than merely refreshing it.

This remediation review is limited to the §4 current-state ownership at issue; it is not a comprehensive audit of every potentially mutable statement in AGENTS.md. For §4, a reference-based fix better matches the adopted authority model.

10. Practical lessons

• An SSOT migration should include an inventory of old mutable replicas and their removal or conversion into references.
• A durable policy file should not own ephemeral current-state values when another document is canonical.
• A bounded change scope protects boundaries; it does not automatically repair a pre-existing inconsistency outside that scope.
• Diff and syntax validation may need to be complemented by a document-role invariant when the risk is semantic duplication.
• The correct remediation may be to remove ownership of mutable state rather than to update its current value.

These are bounded practical lessons from one repository case. The article does not claim that every SSOT migration fails in this way.

Evidence / provenance

Technical facts are limited to what can be established from the Git history of technical-document-workflow. The paths below are repository-relative. The “does not establish” column preserves the boundary of each commit.

Evidence source: mars70s/technical-document-workflow Git history. No private machine path or internal work-environment detail is included in the reader-facing article.

Limits

• This is a case study of one repository.
• It does not claim that all SSOT migrations produce the same failure.
• It does not claim that the failure was specific to AI agents or caused by AI.
• It does not treat the exact write set itself as defective.
• It does not claim that the stale copy was left intentionally.
• It does not infer the workers’ motives or mental state at the time.
• The commit history does not establish every validation command or what each worker knew at the time.

Related content

• AGENTS.md Maintenance: A Read-Only Audit — document responsibility and maintenance boundaries.
• AI-assisted Git Operations: When “Success” Is Wrong — confusing state with verification.
• When Correction Triggers Over-Correction — a case study of scope and verification boundaries.