docs(ms-ai-architect): R11 §9.8 — idx-26b/26c lukket; stale constraint fanget i overleveringen denne gangen [skip-docs]

Skriver opp lukkingen av begge 26-oppfolgerne, de to ratifiserte formene og
begrunnelsen for at det avviste alternativet ble avvist.

Hovedfunnet er metodisk: §9.7s lardom 'stale constraints arves' gjentok seg en
okt senere, men denne gangen la den stale beskrankningen i STATE framfor i
koen. Pastanden om at et resolved anker MA slutte a matche er falsifisert mot
lib/g7-queue.mjs:69-75. Den ekte mekanismen er det omvendte av pastanden:
sjekken fanger at fila endres uten at entryen lukkes, ikke at en entry lukkes
uten at teksten endres. Les koden, ikke notatet om koden.

Ogsa: markor-regelen lest forlengs. §9.7 viste at a FORNYE en markor forplikter
deg til alt den dekker; samme regel sier at en markor ikke kan STYRKES av en
reparasjon som er smalere enn dens scope. Derfor ble stempelet under
compliance-tabellen ikke oppgradert selv om raden under det nettopp ble malt.

Og en presisering mot §9.7: idx-26c ble SKAPT av sin reparasjon (a datere et
stempel gjorde et latent gap til en aktiv pastand). idx-26d ble ikke det —
parafrase-driften forelaa; reparasjonen gjorde den lesbar.

docs/r11-pilot-results.md

@@ -918,6 +918,73 @@ near-certain, but it is an inference and is recorded here as one.
 **Queue state: 6 open, 2 resolved.** Suite 1047/1047; both idx 26 anchors correctly
 stopped matching, and the entry carries its `resolution`.
 
+### 9.8 idx-26b and idx-26c closed together — and a stale constraint caught a second time
+
+**The source was re-fetched live again, not read off §9.7.** §9.7 was written in the
+session that booked both entries, so it is a premise. `how-to-responsible-ai-scorecard`
+was fetched fresh and enumerates seven segments — summary/model overview, data
+analysis, model performance, cohorts, top important factors, fairness insights, causal
+insights — and names the accuracy segment *model performance*. Both measurements
+confirmed independently of §9.7.
+
+**A machine constraint asserted in STATE was false, and it was blocking the edit
+form.** STATE said a resolved entry's anchor *must* stop matching or the check fails,
+"by design". `lib/g7-queue.mjs:69-75` says otherwise: a `resolved` entry returns before
+the anchor check, so it is fully exempt, and anchor drift only bites an entry left
+open. The real mechanism is the inverse of the claim — the check catches *editing the
+file without resolving the entry*, not *resolving without changing the text*. Had the
+claim gone unchecked it would have forced insertion in source order for idx-26c on
+machine grounds that do not exist. **This is §9.7's "stale constraints are inherited"
+lesson recurring one session later, with the stale constraint now living in the
+handover rather than in the queue.** Read the code, not the note about the code.
+
+**idx-26b — operator ratified rename over removal.** The Accuracy metrics row now
+reads `Responsible AI Scorecard: model performance`. Deletion was available and
+rejected: the EU AI Act accuracy-metrics mapping is genuine and source-supported, so
+dropping the row would have removed true information in order to repair a naming
+defect. Line 77 keeps *Quantitative analyses* as a Model Card section — correct there,
+and the reason the cross-attribution was visible at all.
+
+**idx-26c — operator ratified adding the two over downgrading the list.** *Model
+performance* and *Cohorts* were appended as items 6 and 7; the existing five were left
+untouched, confining the change to the measured gap. Appending rather than inserting in
+source order is defensible because the list carries no ordering claim and the original
+five were already not in source order, so appending introduces no new falsity. Item 7
+is worded *automatisk uttrukket av scorecard-en* to keep it distinct from the
+`Cohort analysis` bullet in the Customization block, which is operator-defined and
+enumerates no segment — the same distinction the queue entry warned would otherwise
+look like a cure.
+
+**Two trust markers, decided explicitly in opposite directions.** The
+`Verified (MCP: microsoft-learn, 2026-08-03)` stamp at line 129 is **kept unchanged**;
+its scope was checked rather than assumed, and it now vouches for a complete
+seven-member enumeration re-verified against the live source on the date it already
+carries. The `Verified (Baseline + MCP-inferred)` stamp under the compliance table is
+**deliberately not upgraded**, even though the row beneath it was just measured against
+first-party source: that stamp covers six rows and five of them were not measured, so
+strengthening it would extend a verification claim over unmeasured content. §9.7 taught
+that renewing a marker commits you to everything it covers; the same rule read forward
+says a marker may not be strengthened by a repair narrower than its scope.
+
+**idx-26c's anchor still matches verbatim, and that is the first real exercise of the
+exemption.** Item 5 was untouched, so `5. **Data quality**: …` still occurs in the
+file. idx-26b's anchor did stop matching. Both validate, because `resolution` is what
+the gate demands of a resolved entry.
+
+**The sweep opened a fourth entry — idx-26d — but not in the same way §9.7 did.**
+idx-26c was *created* by its repair: dating a stamp converted a latent gap into an
+active claim. idx-26d was not created by this one. The paraphrase drift in items 1–5
+predates both edits — item 5 *Data quality* is the source's *data analysis*, item 3
+*Model interpretability* is *top important factors*, and item 1 describes the summary
+segment as "Architecture, training data, intended use", which is Model Card content and
+is the same cross-attribution class as idx-26b rather than mere imprecision. What the
+repair changed is **visibility**: items 6 and 7 carry source names, so the list now
+mixes two naming dialects and the drift is legible where it was not before. Full
+canonicalisation was put to the operator as a third option for idx-26c and was not
+chosen, so the ratified scope was completeness alone and this is booked, not folded in.
+
+**Queue state: 5 open, 4 resolved.** Suite 1047/1047.
+
 ## Appendix A — the 15 admitted proposals, hand-verified
 
 Every proposal the classifier (§4 + context condition) admitted over the whole