ms-ai-architect/scripts/kb-eval/data/g7-review-queue.json

{
  "_meta": {
    "gap": "G7",
    "form": "(b) named queue into the human review phase",
    "ratified": "2026-08-03",
    "rationale": "Measured in R11 §9.6: 2 of the 4 subtractions applied in 957ebef left a residue, so residues are the normal by-product of a delete-only envelope rather than an exception. Two of the members are replacements, not multi-locator cases, which a deletion-oriented O4 class would not have fixed. A queue absorbs both classes; an O4 return contract would have been mis-sized against the evidence.",
    "contract": "Anchors are verbatim strings, never line numbers (line ≠ real_line in 9 of 17 R11 records). An open entry whose anchor no longer occurs in its file is drift, and check-g7-queue.mjs fails rather than passing it silently. Nothing in this queue is machine-appliable by definition — every entry is outside the O2 envelope. Resolution is a human review act.",
    "evidence": "docs/r11-pilot-results.md §9.4, §9.5, §9.6; docs/ref-kb-correctness-program-2026-06.md §8 G7"
  },
  "entries": [
    {
      "id": "idx-17",
      "file": "skills/ms-ai-engineering/references/rag-architecture/rag-caching-optimization.md",
      "class": "replacement",
      "status": "resolved",
      "raised": "2026-08-03",
      "summary": "The idx 17 subtraction (957ebef) deleted the three score-threshold bands but left the lead-in ending in a colon, promising an enumeration that no longer existed, immediately followed by a **Verified** stamp. The subtraction was correct; the paragraph it left was not. V1/V2/V2b/V3 are string invariants over deleted text and cannot see document coherence, so the machine could not have caught it.",
      "evidence": "docs/r11-pilot-results.md §9.6",
      "anchors": [],
      "resolution": "Operator-ratified 2026-08-03: colon changed to a period, making the lead-in a complete and independently true sentence that the **Verified** stamp correctly covers. Corpus swept for the same defect shape (bold lead-in ending in colon, blank line, **Verified**) — no other occurrence."
    },
    {
      "id": "idx-33",
      "file": "skills/ms-ai-security/references/ai-security-engineering/ai-threat-modeling-stride.md",
      "class": "replacement",
      "status": "open",
      "raised": "2026-08-03",
      "summary": "The idx 33 subtraction removed AI asset inventory via Azure Resource Graph and the Purview Insider Risk Management bullet from an unsupported Defender for Cloud AISPM attribution. Correct — but the same capabilities survive in this file under Cloud Adoption Framework Secure AI attribution, stamped 'Verified MCP 2026-04', and are asserted in four other corpus files. The edit's benefit is corpus-wide smaller than the single line suggested. Whether the CAF attribution is itself supported has not been checked.",
      "evidence": "docs/r11-pilot-results.md §9.5 (cross-corpus check), §9.6",
      "anchors": [
        "Oppdatert 2026-04: inkluderer nå AI asset inventory via Azure Resource Graph"
      ]
    },
    {
      "id": "idx-26",
      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
      "class": "multi-locator",
      "status": "resolved",
      "raised": "2026-08-03",
      "summary": "The Responsible AI Scorecard component list names Error analysis (item 4) and Counterfactual analysis (item 5). Both were measured false against first-party docs 2026-08-03: the canonical scorecard segments are summary/model overview, data analysis, model performance, cohorts, top important factors, fairness insights and causal insights; Error analysis and Counterfactual analysis are Responsible AI *dashboard* components. The delete-only reduction could only remove item 5, because line 300 asserts Error analysis as scorecard content too — so a partial fix would have left a known-false claim standing while introducing a renumbering artifact (1,2,3,4,6,7). Operator declined the partial fix 2026-08-03 and sent the whole case here. Correct repair spans both locators.",
      "evidence": "docs/r11-pilot-results.md §9.6; https://learn.microsoft.com/azure/machine-learning/how-to-responsible-ai-scorecard",
      "anchors": [
        "4. **Error analysis**: Error rates per cohort, confusion matrices",
        "| **Risk assessment** | Responsible AI Scorecard: Error analysis, fairness assessment |"
      ],
      "resolution": "Operator-ratified 2026-08-03, form (b) — relabel rather than remove. Both source pages were re-fetched live this session and confirm the measurement independently of §9.6: how-to-responsible-ai-scorecard enumerates summary/model overview, data analysis, model performance, cohorts, top important factors, fairness insights and causal insights; concept-responsible-ai-dashboard lists Error analysis and Counterfactual what-if among the dashboard components. Locator 1: items 4 and 5 removed from the numbered scorecard list, which renumbers cleanly to 1-5 — the 1,2,3,4,6,7 artifact was forced only inside the delete-only envelope and does not apply to an ordinary Edit. The two capabilities are retained in a blockquote explicitly marked as dashboard components rather than scorecard segments, so genuine source-confirmed information survives and the reader is warned off precisely the conflation that produced the defect. Locator 2: the Risk assessment row now reads 'fairness insights' alone. The **Confidence:** Verified stamp twelve lines below vouched for the false list and was silently outside every machine check (V1/V2/V2b/V3 are string invariants; check-g7-queue only tests anchors); it is kept but dated to 2026-08-03 to record the re-verification. Document coherence around both locators was read after the edit, per the c569bdc lesson. A neighbouring defect surfaced by the file sweep is booked separately as idx-26b rather than folded in here."
    },
    {
      "id": "idx-26c",
      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
      "class": "replacement",
      "status": "resolved",
      "raised": "2026-08-03",
      "summary": "The scorecard enumeration is incomplete, and idx 26's repair made that assertion active rather than latent. The live fetch performed for idx 26 lists seven canonical segments: summary/model overview, data analysis, model performance, cohorts, top important factors, fairness insights, causal insights. The list after the idx 26 edit carries five — model overview, fairness assessment, model interpretability, causal inference, data quality — so **model performance** and **cohorts** are absent. Note for whoever repairs this: 'Cohort analysis' does appear a few lines below, but inside the *Customization* block, not as an enumerated segment, so it does not cure the omission. This was a latent incompleteness under an undated stamp before 2026-08-03; dating the stamp to 2026-08-03 as part of idx 26 turned it into a positive claim that this enumeration was verified that day, over content the same day's verification showed to be missing two members — the same class of defect §9.7 describes, where an anchor-correct edit leaves a false claim where no check reaches. Booked rather than folded into idx 26, whose ratified scope was the falsity of items 4 and 5, not the completeness of the list. The date on the stamp is deliberately NOT re-litigated here: the relabel it covers WAS verified 2026-08-03, and the operator may keep it once this entry closes the completeness gap. Adding the two missing segments is a content change requiring its own operator ratification.",
      "evidence": "docs/r11-pilot-results.md §9.7; https://learn.microsoft.com/azure/machine-learning/how-to-responsible-ai-scorecard",
      "anchors": [
        "5. **Data quality**: Dataset statistics, missing values, outlier analysis"
      ],
      "resolution": "Operator-ratified 2026-08-03, form (a) - add the two missing segments rather than downgrade the list to a selection. The source was re-fetched live this session and enumerates seven segments in order: summary/model overview, data analysis, model performance, cohorts, top important factors, fairness insights, causal insights. Model performance and Cohorts were appended as items 6 and 7; the existing five were left untouched, so the change is confined to the measured gap. Appending rather than inserting in source order was a free choice, not a machine-forced one: STATE asserted that a resolved entry anchor must stop matching or the check fails, and that is wrong - lib/g7-queue.mjs:69-75 returns before the anchor check for resolved entries, so resolved is fully exempt and anchor drift only bites an entry left open. The list carries no ordering claim, and the existing 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 does not enumerate a segment. The **Confidence:** Verified (MCP: microsoft-learn, 2026-08-03) stamp closing §3 (Responsible AI Scorecard) is kept unchanged and its scope was checked explicitly rather than left implicit: it now vouches for a complete seven-member enumeration re-verified against the live source on the date it already carries. Post-edit sweep of both regions found the surrounding prose coherent; the paraphrase drift it did surface is booked as idx-26d, not folded in. Correction 2026-08-03 (same session, later pass): this resolution originally located that stamp at \"line 129\". It is not there - line 129 is the **Status:** Public preview line, and the **Confidence:** stamp is line 131. The claim about the stamp was true; the locator was false, and it was written into a tracked artefact. Same class as the row count corrected in a9d4724, and the reason the queue contract forbids line numbers as anchors - the prohibition applies to prose inside an entry too, not only to the anchors array."
    },
    {
      "id": "idx-26b",
      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
      "class": "replacement",
      "status": "resolved",
      "raised": "2026-08-03",
      "summary": "Surfaced by the post-edit file sweep for idx 26, in the same compliance-mapping table as idx 26's second locator, but outside both of its anchors — so booked separately rather than folded in (gap discipline; operator-ratified 2026-08-03). The Accuracy metrics row attributes 'Quantitative analyses' to the Responsible AI Scorecard. That is not a scorecard segment name: how-to-responsible-ai-scorecard calls the corresponding segment 'model performance'. The defect is a cross-attribution between two different standards rather than mere imprecision — 'Quantitative Analyses' is a canonical Model Card section, and this same file lists it as one at line 77. Repair is a replacement, so it is outside the delete-only envelope. Whether the right fix is to rename the segment or to drop the row is not yet decided.",
      "evidence": "docs/r11-pilot-results.md §9.6; https://learn.microsoft.com/azure/machine-learning/how-to-responsible-ai-scorecard",
      "anchors": [
        "| **Accuracy metrics** | Responsible AI Scorecard: Quantitative analyses |"
      ],
      "resolution": "Operator-ratified 2026-08-03, form (a) - rename rather than drop the row. The source page was re-fetched live this session (how-to-responsible-ai-scorecard) rather than taken from §9.6 as a premise, and it names the segment model performance: \"The model performance segment displays your model most important metrics and characteristics of your predictions and how well they satisfy your desired target values.\" The Accuracy metrics row now reads \"Responsible AI Scorecard: model performance\". Rename was chosen over deletion because the EU AI Act accuracy-metrics mapping is genuine and source-supported; dropping the row would have removed true information to repair a naming defect. Line 77 keeps Quantitative analyses as a Model Card section, which is correct there and is what made the cross-attribution visible. The **Confidence:** Verified (Baseline + MCP-inferred) stamp at the foot of the compliance table was deliberately NOT upgraded: it covers all six rows and only one was measured against the source this session, so re-dating or strengthening it would have extended a verification claim over unmeasured content - the §9.7 defect class."
    },
    {
      "id": "idx-27",
      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
      "class": "replacement",
      "status": "resolved",
      "raised": "2026-08-03",
      "summary": "Failed out of O2 on cond 3 (§9.6): the cited source DOES establish the mechanism — faqs-generative-orchestration states 'Makers can require user confirmation before executing tools that modify data' — so deleting the Plugin-actions row would destroy source-confirmed information. The defect is modality, not fabrication: the file presents confirmation prompts as a built-in disclosure, whereas the source makes them maker-configured. The Chat-interface row in the same table is imprecise for the same reason: the FAQ documents a default transparency message ('Just so you are aware, I sometimes use AI to answer your questions.'), not a 'Powered by AI' badge. Repair is a replacement, outside the delete-only envelope.",
      "evidence": "docs/r11-pilot-results.md §9.6; https://learn.microsoft.com/microsoft-copilot-studio/faqs-generative-orchestration; https://learn.microsoft.com/microsoft-copilot-studio/faqs-generative-answers",
      "anchors": [
        "| **Plugin actions** | Confirmation prompts før sensitive actions (send email, delete file) |",
        "| **Chat interface** | \"Powered by AI\" badge i chat window |"
      ],
      "resolution": "Operator-ratified 2026-08-03. Open question #8 (does a hub page's linked children count as \"the source\") was answered NO - the strict reading R11 has held throughout stands, and no new standing grounding rule was introduced. idx-27 was instead resolved by making the child a CITED source: the Responsible AI FAQ block now lists both the hub (responsible-ai-overview) and faqs-generative-orchestration, naming the latter as the source for the two repaired claims. The FAQ was fetched live before writing; both quotes are verbatim from it. Chat-interface row: \"Powered by AI\" badge replaced with the default transparency message the source actually documents - \"Just so you are aware, I sometimes use AI to answer your questions.\" - which the source states agents include, so it belongs under Built-in disclosures. Plugin-actions row: the source says \"Makers can require user confirmation before executing tools that modify data\", a configurable safeguard, so the row was MOVED OUT of the Built-in disclosures table into a new \"Maker-konfigurerte kontroller (ikke innebygde disclosures)\" block. Repairing the text in place would have left the false modality asserted by the table heading; weakening the heading instead was rejected because it would have silently restated the modality of the two unmeasured rows (Generative answers, Data usage), and adding a modality column would have asserted \"built-in\" about them outright - creating new unverified claims to fix an old one. The deleted \"(send email, delete file)\" examples were not carried over: the source names neither. The same \"Powered by AI\" imprecision at line 218, in the Azure implementasjon list of Mønster 3, is outside this entry's anchors and is booked as idx-27b rather than swept in - the idx-26c/26d precedent. No **Confidence:** stamp covers the Copilot Studio section, so no marker obligation was triggered by this edit. Scope addendum, same session, after an adversarial read of the resolution above: both repaired claims were taken from a FAQ whose own scope line reads \"the AI impact of generative orchestration for custom agents built in Copilot Studio\", and they were written into a section headed Microsoft Copilot Studio with no qualifier - the same widening class this entry was raised for. Re-checked against the docs rather than reasoned about, and the two claims came apart. The maker-confirmation safeguard occurs ONLY in the generative-orchestration FAQ, in a safeguards list about tool execution, so it is orchestration-scoped and the bullet now says so explicitly (\"for agenter med generativ orkestrering\"). The default transparency message occurs in that FAQ AND, verbatim, in faqs-generative-answers under \"What protections are in place within Copilot Studio for responsible AI?\", framed there as a general best practice rather than an orchestration feature. Two independent feature FAQs stating it without a feature qualifier is why the Built-in disclosures row carries no scope qualifier; faqs-generative-answers was added as a third cited source so the reader can check that reasoning rather than take it on trust. Neither FAQ is a Copilot-Studio-wide statement of record, so this is grounded-as-cited, not established-for-all-agents - if a stronger claim is ever wanted, it needs a source that says so."
    },
    {
      "id": "idx-36",
      "file": "skills/ms-ai-security/references/ai-security-engineering/ai-threat-modeling-stride.md",
      "class": "multi-locator",
      "status": "open",
      "raised": "2026-08-03",
      "summary": "Applying idx 36 alone yields a severity table more precise than the prose that cites it, so a companion edit is required for the prose to match the narrowed table. Held back from 957ebef as out of envelope.",
      "evidence": "docs/r11-pilot-results.md §9.4, §9.5",
      "anchors": [
        "Øker severity bar; krever mer robust adversarial defenses"
      ]
    },
    {
      "id": "idx-18",
      "file": "skills/ms-ai-engineering/references/rag-architecture/rag-caching-optimization.md",
      "class": "multi-locator",
      "status": "open",
      "raised": "2026-08-03",
      "summary": "No reduction exists. The surviving claim is a whole titled section on Azure AI Search built-in caching plus a **Verified** row in the verification table, so no deletion confined to a single locator can repair the file. This is the member that most clearly motivated G7.",
      "evidence": "docs/r11-pilot-results.md §9.3, §9.4",
      "anchors": [
        "**Automatic Caching Behavior:**",
        "| Azure AI Search caching | **Verified** | Microsoft Learn docs (4, 6) |"
      ]
    },
    {
      "id": "idx-26d",
      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
      "class": "replacement",
      "status": "resolved",
      "raised": "2026-08-03",
      "summary": "Surfaced by the post-edit sweep for idx-26c. The five original members of the scorecard component list carry paraphrased names rather than the source segment names, and idx-26c added two members that DO carry source names, so the list is now mixed. Concretely: item 5 Data quality maps to the source segment data analysis; item 3 Model interpretability maps to top important factors; item 1 Model overview is described as \"Architecture, training data, intended use\", which is Model Card content - the source summary segment is a model overview plus the key target values the user set. That last one is the same cross-attribution class as idx-26b rather than mere imprecision, since Model details / Intended use / Training data are canonical Model Card sections listed in this same file at lines 71-76. Full canonicalisation was offered to the operator as part of the idx-26c decision and was NOT chosen; the ratified scope there was completeness only, so this is booked rather than folded in. Open choice: rename the five to the source segment names in source order, or rewrite item 1 alone (the only member where the drift produces a false attribution rather than a recognisable paraphrase) and leave the rest.",
      "evidence": "docs/r11-pilot-results.md §9.8; https://learn.microsoft.com/azure/machine-learning/how-to-responsible-ai-scorecard",
      "anchors": [
        "1. **Model overview**: Architecture, training data, intended use"
      ],
      "resolution": "Operator-ratified 2026-08-03, full canonicalisation. The source was re-fetched live before writing (how-to-responsible-ai-scorecard) and enumerates seven segments: summary/model overview, data analysis, model performance, cohorts, top important factors, fairness insights, causal insights. All five original member NAMES were renamed to the source segment names, closing the defect this entry was actually booked under - that the list mixed two dialects after idx-26c added two source-named members. Rewriting item 1 alone was rejected for exactly that reason: it removes the false attribution but leaves the booked defect standing. DESCRIPTIONS were rewritten for two members only: item 1 (was \"Architecture, training data, intended use\", which is Model Card content - Model details / Intended use / Training data are canonical Model Card sections listed in this same file at lines 71-76 - now \"Modelloversikt og de target-verdiene du har satt\", matching the source summary segment) and item 3 (was \"Feature importance (global/local explanations)\", RAI *dashboard* vocabulary inside a scorecard enumeration, contradicting this file's own callout that dashboard components are not scorecard segments - now \"Faktorene som påvirker modellens prediksjoner mest\"). Descriptions of items 2, 4 and 5 were deliberately left UNTOUCHED even though they carry specifics the source does not state, because that is a distinct defect class (unsourced specificity under a verification marker) booked as idx-26f; rewriting them here would have silently resolved an entry raised the same session and left the queue incoherent. Source order was NOT imposed: idx-26c established the list carries no ordering claim and the five were already not in source order, so reordering would be a larger diff with no measured defect behind it. Cross-file check run before editing: the five names occur elsewhere in the corpus, but in dashboard/interpretability contexts, not as a mirror of this enumeration - except stakeholder-communication-ai-decisions.md:57-62, which is a parallel five-member list in the same paraphrase dialect and is booked as idx-26e rather than swept in. What the **Confidence:** Verified (MCP: microsoft-learn, 2026-08-03) stamp closing §3 now vouches for, stated explicitly rather than left implicit: a seven-member enumeration whose NAMES are all the source's own segment names and whose descriptions for items 1, 3, 6 and 7 were verified against the live source on the date the stamp already carries. Items 2, 4 and 5 descriptions are NOT covered by that widening - idx-26f is open against them. [Superseded 2026-08-03 by idx-26f's closure: items 2 and 5 were rewritten to source wording and item 4 adjudicated a recognisable paraphrase; see idx-26f's resolution for what the stamp covers now.]"
    },
    {
      "id": "idx-27b",
      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
      "class": "replacement",
      "status": "resolved",
      "raised": "2026-08-03",
      "summary": "Surfaced by the neighbourhood sweep for idx-27. The Mønster 3 \"Azure implementasjon\" list asserts a Copilot Studio \"Powered by AI\" disclosure in the chat interface - the same claim idx-27 removed from the Copilot Studio section, and false for the same reason: faqs-generative-orchestration documents a default transparency message (\"Just so you are aware, I sometimes use AI to answer your questions.\"), not a badge. Different section, outside idx-27's anchors, so booked separately rather than swept in. Repair is a replacement, outside the delete-only envelope. Note for whoever repairs this: after idx-27 the corrected wording already exists a few hundred lines below, so the repair is a copy of an already-ratified formulation rather than a fresh judgement.",
      "evidence": "docs/r11-pilot-results.md §9.6; https://learn.microsoft.com/microsoft-copilot-studio/faqs-generative-orchestration",
      "anchors": [
        "- **Copilot Studio**: \"Powered by AI\" disclosure i chat interface"
      ],
      "resolution": "Operator-ratified 2026-08-03. The Moenster 3 \"Azure implementasjon\" bullet was replaced with exactly what the already-ratified row at the Copilot Studio section asserts: the standard transparency message \"Just so you are aware, I sometimes use AI to answer your questions.\" delivered in the chat interface. This is a copy of a formulation ratified earlier the same session (idx-27), not a fresh judgement, and the quote was grep-verified byte-for-byte against that row after the edit - hand-copying a verbatim string is where quote-style drift enters. Deliberately NOT carried over: any audience-tiering or layered-disclosure language from the surrounding Moenster 3 pattern. The bullet sits under an audience-layering table while the source row sits under \"Built-in disclosures\"; adding reach the source does not state is exactly the scope class caught in 66fb567, and this repair would have inherited it. Standing matches idx-27's addendum: the standard message is documented in both faqs-generative-orchestration and faqs-generative-answers (the latter with the broader \"best practice to communicate to users that the agent uses artificial intelligence\" framing), so it carries no scope qualifier - unlike the confirmation safeguard, which does. Cross-file grep before editing: \"Powered by AI\" occurred nowhere else in the corpus. Two neighbours were checked and deliberately NOT swept in - the Foundry agent-transparency bullet asserting a \"This chatbot uses AI\" embeddable component, and the scenario-1 tooling line naming a \"Copilot Studio disclosure widget\" where this file's own Copilot Studio section documents a pre-built \"AI disclosure\" topic in the generative AI toolkit, not a widget. Both are unverified product artefacts in other sections against other sources; they are booked as idx-27c and idx-27d rather than repaired here."
    },
    {
      "id": "idx-26e",
      "file": "skills/ms-ai-governance/references/responsible-ai/stakeholder-communication-ai-decisions.md",
      "class": "replacement",
      "status": "resolved",
      "raised": "2026-08-03",
      "summary": "Surfaced by the cross-file grep run before the idx-26d edit. This file carries a parallel five-member list describing the Responsible AI Scorecard under the heading \"Konfigurerbare elementer\", in the same paraphrase dialect idx-26d just removed from transparency-documentation-standards.md: Dataset-helse, Modell-ytelse, Target values, Fortolkningsevne, Fairness assessment. Two problems, and they are distinguishable. First, the names are paraphrases of the source's scorecard SEGMENTS (data analysis, model performance, top important factors, fairness insights), so the list is the same drift class as idx-26d. Second, and separately, the heading claims these are CONFIGURABLE elements; the source page enumerates seven scorecard segments and does not enumerate a set of configurable elements, so the framing itself is unsupported. The list sits under a *Confidence: Verified (MCP microsoft-learn)* stamp carrying no date. Booked, not folded into idx-26d: idx-26d's ratified scope was one list in one file, and this file was not re-verified against the live source this session.",
      "evidence": "docs/r11-pilot-results.md §9.8; https://learn.microsoft.com/azure/machine-learning/how-to-responsible-ai-scorecard",
      "anchors": [
        "**Konfigurerbare elementer**:",
        "- **Fortolkningsevne**: Global/lokal feature importance"
      ],
      "resolution": "Operator-ratified 2026-08-04: mirror the sibling file's structure. Both this entry's premise and STATE's framing of open question #9 were checked against ground truth before writing, and the framing was FALSE: the claim that this list sits in a file without a Verified stamp over it does not hold. The stamp *Confidence: Verified (MCP microsoft-learn)* at :81 is section-terminal and closes §1 (lines 46-81), so it reaches the list. That was the entire stated reason 26e was booked separately rather than folded into idx-26d/idx-26f, and with it gone the honesty argument from 26f applies here with the same force it had there. Two source pages were fetched live this session: how-to-responsible-ai-scorecard, which enumerates the seven segments, and concept-responsible-ai-scorecard, which is the page THIS file actually cites (Kilder #1) and which grounds the configurability claim. Relabelling the existing five members to 'Komponenter i Scorecard' without completing them was rejected on measurement rather than taste: idx-26c's ratified scope in the sibling was completeness - it ADDED the two missing segments - so a five-member components list here would have imported the exact defect idx-26c closed, the repair inheriting a sibling entry's defect class. What was written: the block is split in two, as in transparency-documentation-standards.md. 'Komponenter i Scorecard' now carries all seven source segment names, with descriptions verified against the live how-to page this session; 'Du konfigurerer' carries only what the sources state the user sets - target values for model performance, fairness target values for the sensitive groups you choose, with target accuracy and target error rate as the concept page's own examples. This closes all three defect classes the list carried, of which the entry had booked two. Name drift (26d class): the five names were paraphrases of source segments. Unsourced specificity under a verification marker (26f class, NOT booked here and found while measuring): 'Statistikk, distribusjoner, bias-indikatorer' and 'Accuracy, error rates, fairness metrics' are stated by neither source page, and 'på tvers av sensitive grupper' dropped the you-choose-them agency exactly as the sibling's item 2 did before 26f. Unsupported framing (the entry's second booked problem): neither source enumerates configurable elements; the concept page states only that you provide desired model performance and fairness target values. DELIBERATE DIVERGENCES FROM THE SIBLING, recorded so a future cross-file sweep does not book them as drift: (1) source order and bullets, not the sibling's numbering - idx-26c established the enumeration carries no ordering claim, this file's own lists are bulleted, and two numbered lists in different orders would make 'item 2' denote different members in the two files; (2) item 7 reads 'Om faktorene eller tiltakene du har identifisert har kausal effekt på utfallet i den virkelige verden' rather than the sibling's 'Causal vs correlational relationships i features' - the sibling's rendering was adjudicated a recognisable paraphrase under 26f and is NOT reopened, but 'vs correlational' and 'i features' are in neither source, and importing a looser paraphrase into FRESH text under a stamp being dated today would be the very class this programme exists to remove; (3) 'target values' is rendered 'target-verdiene' in every member, where the sibling leaves one member in bare English - 26f's ratified correction was precisely that one source concept must not carry two renderings inside one list. THE STAMP was dated to 2026-08-04 per operator choice, following idx-26's precedent of dating a stamp to record re-verification. What it vouches for, stated rather than left implicit: the seven-member enumeration and the configurability line, both verified against live sources this session; and the rest of §1 - 'Hva det er', 'Primært bruksområde', the three 'Formål' bullets and the four 'Verdi for ikke-tekniske' bullets - which were READ and checked against the concept page this session and are supported by it. Two of those bullets ('multi-stakeholder alignment i ML-livssyklusen', 'risikoofficerer') looked like paraphrase drift when measured against the how-to page alone and are near-verbatim on the concept page; measuring only the page a segment list came from would have produced two false findings. The YAML block is marked 'Typisk' and is illustrative. NOT covered by the stamp, measured and booked rather than folded in: §1 omits the public-preview banner both source pages carry while the file header declares Status: GA, and the file's fifteen listed sources do not include how-to-responsible-ai-scorecard, the page grounding the enumeration just written - booked as idx-26g. CROSS-FILE GREP before and after the edit: 'Konfigurerbare elementer', 'Dataset-helse' and 'Fortolkningsevne' occur nowhere else in the corpus; 'Modell-ytelse' and 'Fairness assessment' occur elsewhere only in dashboard, monitoring and Foundry-tooling contexts, never as a mirror of this enumeration. One of those hits is booked as idx-26i. The whole section was re-read for coherence after the edit, and - per the failure that forced 80e17ec - the new text was separately audited on the axis this repair was justified by rather than on content alone: compound forms count target-verdiene 3x and fairness-målverdiene 2x with no hybrid, and the two English metric names are the source's own examples, already mirrored in the YAML block immediately below. [AMENDED 2026-08-04, same session: this resolution overstated its own coverage. Of the four 'Verdi for ikke-tekniske' bullets, three are supported by the concept page ('Side-by-side sammenligning mellom faktisk og ønsket ytelse', 'Dokumentasjon som kan deles med juridisk og compliance', 'Grunnlag for deployment-godkjenning'). The fourth — 'Standardisert format som business forstår' — is NOT: neither page calls the scorecard a standardised format, and the 'business forstår' half is a paraphrase of 'share the report with your technical and nontechnical stakeholders'. It is an unmeasured paraphrase adopted under the stamp this closure dated, not a verified statement, and presenting all four as checked was the 26f class reproduced inside a resolution field. The corpus text is unchanged; what changes is what this artefact claims about it. Nothing in the machine checks reads a resolution field.]"
    },
    {
      "id": "idx-26f",
      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
      "class": "replacement",
      "status": "resolved",
      "raised": "2026-08-03",
      "summary": "Surfaced while writing idx-26d, and deliberately excluded from it. Items 2 and 5 of the scorecard enumeration carry specifics the live source does not state: the fairness insights segment is described with \"(gender, ethnicity, age)\" where the source says only \"your desired sensitive groups\", and the data analysis segment with \"missing values, outlier analysis\" where the source says only that it \"shows you characteristics of your data\". Neither is false on its face - both are plausible instances - but both sit under the **Confidence:** Verified (MCP: microsoft-learn, 2026-08-03) stamp, which now vouches for an enumeration re-verified against the live source. This is a distinct class from idx-26d's name drift and idx-26b's cross-attribution: unsourced SPECIFICITY under a verification marker, where the defect is the marker's reach rather than the sentence. idx-26d's resolution states explicitly that its widening of the stamp does not cover items 2, 4 and 5, so the stamp is currently honest only because that exclusion is written down - closing this entry is what would make it honest on its own terms. Item 4's description was checked in the same pass and is a recognisable paraphrase of the source, not added specificity, so it is named here as checked-and-clear rather than left ambiguous.",
      "evidence": "docs/r11-pilot-results.md §9.8; https://learn.microsoft.com/azure/machine-learning/how-to-responsible-ai-scorecard",
      "anchors": [
        "2. **Fairness insights**: Performance disparities across sensitive groups (gender, ethnicity, age)",
        "5. **Data analysis**: Dataset statistics, missing values, outlier analysis"
      ],
      "resolution": "Operator-ratified 2026-08-03, form (a): descriptions rewritten to the source's own wording, NOT surgical deletion of the named parentheticals. The source was re-fetched live before writing (how-to-responsible-ai-scorecard) and states only \"how well your model is satisfying the fairness target values you set for your desired sensitive groups\" and \"The data analysis segment shows you characteristics of your data\". Item 2 is now \"Hvor godt modellen moeter fairness-maalverdiene du har satt for de sensitive gruppene du velger\" and item 5 \"Karakteristikker ved dataene dine\" (both written with correct Norwegian diacritics in the corpus file). Deleting only the specificity this entry NAMED was rejected on two counts, each of which would have made the repair inherit the defect class it was raised against: it leaves item 5 as \"Dataset statistics\", which the source does not state either and which this entry did NOT adjudicate as checked-and-clear the way it did item 4; and it leaves item 2 as \"across sensitive groups\", dropping the you-choose-them agency and stranding item 2 in the pre-idx-26d dialect while items 1, 3, 6 and 7 carry \"du har satt\" - reopening the mixed-dialect defect idx-26d was booked under, in the file idx-26d had just canonicalised. Form (b) - narrowing the stamp's stated reach in the file instead - was put to the operator and declined: it is honest-by-annotation relocated from this queue's resolution field into the corpus, i.e. the same mechanism this entry exists to remove the need for. Item 4 was left untouched per this entry's own adjudication. Cross-file grep before editing: \"gender, ethnicity, age\", \"outlier analysis\" and \"Dataset statistics\" occurred nowhere else in the corpus. The enumeration was re-read whole after the edit for coherence, not just for the two edited strings. SUPERSEDES the closing clause of idx-26d's resolution: what the **Confidence:** Verified (MCP: microsoft-learn, 2026-08-03) stamp vouches for is now a seven-member enumeration whose names are all the source's own segment names, whose descriptions for items 2 and 5 were re-verified against the live source THIS session and whose descriptions for items 1, 3, 6 and 7 were verified against the live source under idx-26d earlier the same day - the same stamp date and the same page, but an inherited verification rather than one re-run here, stated separately so the artefact is honest about its own provenance, and whose item 4 description was adjudicated a recognisable paraphrase of the source's causal-insights passage. No exception is written down anywhere for the stamp to remain honest. POST-EDIT CORRECTION, same session: item 2 first landed as \"fairness-target values\", a hybrid compound that is neither language and that broke the very dialect consistency this repair was justified by - item 1 renders the same source concept as \"target-verdiene\". Corrected to \"fairness-maalverdiene\". The operator-ratified LABEL was \"kildens ordlyd i idx-26d-dialekten\"; the illustrative preview carried the defective form, and the label is the ratified object, so the correction needed no re-ratification. The coherence re-read after the first edit checked the enumeration for CONTENT alignment and passed it - it did not check compound forms, which is the axis that failed."
    },
    {
      "id": "idx-27c",
      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
      "class": "replacement",
      "status": "open",
      "raised": "2026-08-03",
      "summary": "Surfaced by the neighbourhood sweep for idx-27b and deliberately excluded from it. The Microsoft Foundry \"Agent transparency\" list asserts \"Disclosure widgets: \\\"This chatbot uses AI\\\" embeddable component\" - a named product artefact carrying a verbatim-looking user-facing string. Same class as idx-27 and idx-27b (a plausible disclosure phrasing asserted as a built-in surface), but a different platform section against a different source, so it cannot be repaired by copying the ratified Copilot Studio formulation. Needs its own live fetch against Foundry documentation to establish whether an embeddable disclosure widget exists and, if so, what string it actually carries. Repair is a replacement, outside the delete-only envelope.",
      "evidence": "docs/r11-pilot-results.md §9.10",
      "anchors": [
        "- Disclosure widgets: \"This chatbot uses AI\" embeddable component"
      ]
    },
    {
      "id": "idx-27d",
      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
      "class": "replacement",
      "status": "open",
      "raised": "2026-08-03",
      "summary": "Surfaced by the neighbourhood sweep for idx-27b and deliberately excluded from it. The scenario 1 tooling line names a \"Copilot Studio disclosure widget\", but this same file's Copilot Studio section documents a pre-built \"AI disclosure\" TOPIC in the generative AI toolkit - not a widget. This is intra-file name drift of the same shape as idx-26d, not a source-attribution error: the file contradicts itself about what the artefact is called. Note the context differs from idx-27/idx-27b - this line sits inside a worked scenario recommendation rather than a product-capability claim, so the repair should decide whether to name the toolkit topic or drop the artefact name, not merely restate a source. Repair is a replacement, outside the delete-only envelope.",
      "evidence": "docs/r11-pilot-results.md §9.10",
      "anchors": [
        "**Tooling:** Azure OpenAI Transparency Note + Copilot Studio disclosure widget"
      ]
    },
    {
      "id": "idx-26g",
      "file": "skills/ms-ai-governance/references/responsible-ai/stakeholder-communication-ai-decisions.md",
      "class": "multi-locator",
      "status": "resolved",
      "raised": "2026-08-04",
      "summary": "SEVERITY NOTE for triage: the Status: GA locator is a FALSE status claim, the same class as idx-26h's 'anbefalt for production use' and not merely a missing banner — both source pages state the scorecard is in public preview, provided without an SLA and not recommended for production workloads, while this file's header declares GA. Do not triage this entry below idx-26h on the assumption that it is citation hygiene. Surfaced while closing idx-26e and named in its resolution rather than folded in. Two provenance and status facts about §1 of this file, both now under the *Confidence: Verified (MCP microsoft-learn, 2026-08-04)* stamp idx-26e dated. First: both source pages carry an Important banner stating the Responsible AI scorecard is in public preview, provided without a service-level agreement and not recommended for production workloads. §1 says nothing about it, and the file header declares Status: GA. Second: the seven-member enumeration idx-26e wrote is grounded in how-to-responsible-ai-scorecard, which is not among the fifteen sources this file lists - Kilder #1 is the concept page, concept-responsible-ai-scorecard, which does not enumerate the segments. The Total kilder line was counted against the list before booking and is accurate as it stands (15 = 8 verified + 4 baseline + 3 code samples), so adding a source is a renumbering edit across entries 9-15 plus a counting claim - which is why it was not swept into idx-26e's ratified scope. Open choice for the reviewer: add the how-to page as a numbered source and renumber, add it as a second URL under Kilder #1 (no renumber, but 'Total kilder' then counts entries rather than URLs), or leave the citation as is and narrow what the file claims.",
      "evidence": "https://learn.microsoft.com/azure/machine-learning/how-to-responsible-ai-scorecard ; https://learn.microsoft.com/en-us/azure/machine-learning/concept-responsible-ai-scorecard?view=azureml-api-2 ; idx-26e resolution; docs/r11-pilot-results.md §9.11",
      "anchors": [
        "**Status:** GA",
        "**Total kilder**: 15 (8 verified fra MCP, 7 baseline/code samples)"
      ],
      "resolution": "Operator-ratified 2026-08-09, two decisions put separately because they are independent: the preview fact needed NO new citation (the Important banner is on the concept page, which is already Kilder #1 - verified by live fetch this session), so the a/b/c citation choice governed only the seven-segment enumeration. (1) HEADER: **Status:** GA -> **Status:** GA / Preview (Responsible AI scorecard). Ratified over the terser 'varies by feature' form because the parenthetical names WHAT is in preview, which is the semantics of all six corpus files in the X / Preview (Y) family (checked: none of them uses the parenthetical to name the GA surface). The file spans GA products (ML interpretability, Transparency Notes, Copilot Studio, Power Platform AI) and one preview component, so a bare GA or a bare Preview would both be false. (2) SECTION 1: added **Tilgjengelighet** in source wording, in the dialect idx-26h ratified in the sibling file ('leveres uten SLA, og Microsoft anbefaler den ikke for production workloads'). Both source pages carry the banner verbatim and both titles read '(preview)'. (3) STAMP RE-DATED 2026-08-04 -> 2026-08-09, deliberately and not as a side effect: the added sentence is text written today, and leaving it under a five-day-old verification date would have authored the exact idx-26h defect ('the stamp was FALSE WHEN SET, not stale'). Re-dating claims all of section 1, so all of it was re-measured against both live pages this session: the seven segments map 1:1 to how-to-responsible-ai-scorecard's 'How to read your scorecard'; 'Du konfigurerer' matches the concept page's 'target accuracy and target error rate'; the Formaal bullets match the concept page's three unaddressed-needs bullets; the Verdi bullets match 'building trust and gaining their approval for deployment' + 'use the scorecard in audit reviews'; the YAML workflow block is synthesis whose every step is grounded in the concept page's 'Who should use a Responsible AI scorecard?' section. (4) THIRD LOCATOR, not named by this entry - anchors are a LOWER bound (idx-26h lesson). Kilder #1 read 'Status: GA (public preview for some features)' two lines under its own title '...scorecard (preview)'. The banner covers the whole feature, so 'GA with some preview features' was false, not merely imprecise; corrected to the same source wording. (5) CITATION: how-to-responsible-ai-scorecard added as Verified source #9; old 9-15 renumbered 10-16; **Total kilder** 15 -> 16 (9 verified fra MCP, 7 baseline/code samples). Renumbering is mechanically safe: grep over lines 1-794 found ZERO prose cross-references to source numbers. The chosen form also PRESERVES the pre-existing referent of the counting claim - it keeps counting numbered entries (16 entries, 9 of which carry URLs), whereas the 'second URL under Kilder #1' form would have made the file hold 16 URLs against 15 entries and left the referent undefined, the very class idx-26j had just booked. EXPLICITLY NOT COVERED by this resolution: the footer line '**MCP calls gjennomført**: 5 (3 docs_search, 2 docs_fetch, 1 code_sample_search)', whose components sum to 6 - booked as idx-26k rather than repaired here, because idx-26j owns that form decision and its referent is undefined. **Last updated:** was left untouched, following the precedent of all eleven prior ratified corpus edits (verified: zero of them modified that field). 'Verifisert: 2026-02' on sources 1-8 left untouched - those pages were not re-fetched this session. STAMP ADJACENT TO THE CITATION EDITS, ADJUDICATED RATHER THAN LEFT AMBIGUOUS: *(Verified MCP 2026-04)* at line 795 does NOT reach the Kilder section, so the added source #9 (dated 2026-08-09), the corrected #1 Status line and the renumbering sat under no stamp at all. Measured, not assumed: every Confidence stamp in this file is section-terminal, sitting immediately before the next ## heading (six instances - 328 before ## Beslutningsveiledning, 659 before ## For arkitekten, 795 before ## Kilder og verifisering), so line 795 is terminal for 'For arkitekten (Cosmo)'. Corroborated independently: sources 1-8 carry 'Verifisert: 2026-02', which a stamp covering the Kilder section with a 2026-04 date would contradict. Also completing the renumbering verification end-to-end: the zero-cross-reference grep was re-run over lines 795-EOF (the footer prose after the numbered list, including the **Confidence vurdering** block) - zero hits there too, so the claim covers the whole file rather than only the window first checked."
    },
    {
      "id": "idx-26h",
      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
      "class": "multi-locator",
      "status": "resolved",
      "raised": "2026-08-04",
      "summary": "Surfaced while measuring idx-26e against the live sources, in the file idx-26d and idx-26f canonicalised. Two locators under the **Confidence:** Verified (MCP: microsoft-learn, 2026-08-03) stamp that idx-26 dated and idx-26d/26f widened. First, and the stronger of the two: the Status line reads 'Public preview (Azure ML) - anbefalt for production use med awareness om SLA-limitations', which contradicts both source pages rather than paraphrasing them. Both state: 'This preview version is provided without a service-level agreement, and we don't recommend it for production workloads.' The file recommends what the source explicitly does not recommend. Second: the Customization block lists 'Cohort analysis: Disaggregated performance for identified risk groups' and 'Narrative sections: Fritekst-forklaringer for decisions og mitigations'; neither source page states either, making both 26f-class unsourced specificity under the same stamp. This matters for an artefact claim, not only for the corpus: idx-26f's resolution states that no exception is written down anywhere for that stamp to remain honest. That is true of the seven-member enumeration 26f measured, and not of the Customization and Status lines the same stamp also closes, which 26f did not measure. Both entries verified the enumeration; neither read down to the end of the block the stamp reaches.",
      "evidence": "https://learn.microsoft.com/azure/machine-learning/how-to-responsible-ai-scorecard ; https://learn.microsoft.com/en-us/azure/machine-learning/concept-responsible-ai-scorecard?view=azureml-api-2 ; idx-26f resolution; docs/r11-pilot-results.md §9.11",
      "anchors": [
        "**Status:** Public preview (Azure ML) — anbefalt for production use med awareness om SLA-limitations.",
        "- Cohort analysis: Disaggregated performance for identified risk groups"
      ],
      "resolution": "Operator-ratified 2026-08-09, form: replacement with the source own wording, not deletion. Three pages were re-fetched live before writing: concept-responsible-ai-scorecard, how-to-responsible-ai-scorecard and how-to-responsible-ai-insights-ui.\n\nFINDING 1 CONFIRMED. All three pages carry the identical Important banner: \"This preview version is provided without a service-level agreement, and we do not recommend it for production workloads.\" The Status line recommended what the source explicitly does not recommend. It now reads \"Public preview (Azure ML) — leveres uten SLA, og Microsoft anbefaler den ikke for production workloads.\" Deleting the line was rejected: preview status is the one operationally decisive fact in the section and the section carries it nowhere else.\n\nFINDING 2 PARTLY FALSIFIED — this entry overstated its own coverage. It claims \"neither source page states either\". That holds for the two pages the entry measured and FAILS against a third, how-to-responsible-ai-insights-ui, which documents scorecard customisation directly: step 4 states the Data analysis section \"enables cohort analysis\" and that you select \"features of interest to identify your model performance on their underlying cohorts\", and step 1 offers \"an optional description about the model functionality, data it was trained and evaluated on, architecture type\". The bullets were therefore GROUNDED CONTENT WITH UNSOURCED PHRASING, not unsourced specificity. Deleting them would have been over-deletion of documented behaviour. Only \"identified risk groups\" (the source says features of interest; sensitive features belong to the separate Fairness assessment step) and \"decisions og mitigations\" (nowhere in any source) were unsourced. \"Narrative sections\" is not source vocabulary either and was renamed to the source step name, Scorecard summary — the same rename-to-source-segment-names rule idx-26d established. This is the idx-26e lesson repeating: the page a claim came from is a different object from the pages an entry happened to measure.\n\nSCOPE EXTENDED BEYOND THE TWO ANCHORS, each ratified separately, and forced by the stamp decision rather than chosen. Re-dating the stamp asserts the whole section is verified, so any measured-unsourced claim left under it would reproduce the idx-26f class knowingly. (a) The third Customization bullet, not named by this entry: \"max error rate per subgroup\" — targets are set on the metric, and fairness targets capture the difference or ratio ACROSS subgroups (max-min or max/min), never a per-subgroup maximum. Rewritten to the source: performance metrics you choose (up to three) with target values, plus a target value on the chosen fairness metric. (b) The role table row \"Compliance officers | Review for regulatory compliance (EU AI Act, sector-specific regler)\": neither the role name nor the parenthetical is in any source, which says \"share model and data insights with auditors and risk officers for auditability purposes, as required by AI regulations\". Rewritten to \"Risk officers | Dele modell- og data-innsikter for auditability, slik AI-regelverk krever\".\n\nTHE ADJACENT AUDITORS ROW WAS DELIBERATELY NOT TOUCHED. The ratified option PREVIEW showed a merged row folding Auditors into Risk officers; the option LABEL ratified \"rett raden\", singular. The label is the ratified object, the preview was wider than it, and the Auditors row (\"Arkiverte scorecards i Azure ML Run History for retrospective review\") is grounded verbatim in the concept page. Merging would have deleted correct content on the strength of an illustration.\n\nSTAMP. Re-dated 2026-08-03 to 2026-08-09. The old date was not stale, it was WRONG WHEN SET: the Status line was false on 2026-08-03, under a stamp idx-26d dated that same day. A stamp can be falsified by the content it closes at the moment it is applied, and neither idx-26d nor idx-26f detected it because both measured only the seven-member enumeration and neither read to the end of the block the stamp reaches.\n\nSOURCES. how-to-responsible-ai-insights-ui and how-to-responsible-ai-scorecard added as #11 and #12 inside the MCP-verified group; the former baseline entries 11-15 renumbered 13-17; the footer claim \"Unique sources: 15 URLs\" updated to 17. Verified by grep that no prose in the file cross-references a source by number, so the renumbering has no second surface.\n\nidx-26g IS NOT CLOSED BY THIS EDIT AND THE SESSION QUESTION THAT SAID IT WOULD BE WAS WRONG. idx-26g is booked against a DIFFERENT FILE, stakeholder-communication-ai-decisions.md, with its own fifteen-source list and its own \"Total kilder\" counting claim, plus a Status: GA header finding this edit does not touch. The operator ratified the source-list option under that false framing; the renumbering was correct on its own merits for THIS file, so the edit stands, but the entry it was said to also close does not.\n\nRESIDUAL BOOKED AS idx-26j: the footer provenance block of this same file, which no entry has ever measured."
    },
    {
      "id": "idx-26i",
      "file": "skills/ms-ai-governance/references/norwegian-public-sector-governance/public-sector-ai-ethics-framework.md",
      "class": "replacement",
      "status": "open",
      "raised": "2026-08-04",
      "summary": "Surfaced by the cross-file grep run while closing idx-26e, and it is as much a finding about the CHECK as about the corpus. idx-26f removed '(gender, ethnicity, age)' from the sibling's fairness insights description and recorded a cross-file grep for that string returning nothing elsewhere. That grep was dialect-blind: this file renders the same specificity in Norwegian - '**Fairness assessment** - evaluerer modellrettferdighet på tvers av sensitive grupper (kjønn, etnisitet, alder)' - under the heading '### Microsoft Foundry RAI-tools:'. Booked as an unmeasured CANDIDATE, not a confirmed defect: the attribution here is to Foundry RAI tooling rather than to a scorecard segment, and neither this file's stamp coverage nor its source page has been checked. What IS confirmed is the check gap - an English-only grep cannot see a bilingual corpus's Norwegian rendering of the same claim, so every cross-file sweep recorded in this queue that greped English strings alone has an unmeasured Norwegian half. Resolving this entry should decide the corpus question AND whether the sweep convention changes.",
      "evidence": "idx-26f resolution (cross-file grep clause); idx-26e cross-file grep; docs/r11-pilot-results.md §9.11",
      "anchors": [
        "- **Fairness assessment** — evaluerer modellrettferdighet på tvers av sensitive grupper (kjønn, etnisitet, alder)"
      ]
    },
    {
      "id": "idx-26j",
      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
      "class": "multi-locator",
      "status": "resolved",
      "raised": "2026-08-09",
      "summary": "Surfaced while closing idx-26h in this file; measured, not inferred. The footer provenance block makes three counting/provenance claims and no G7 entry has ever measured it. First: \"Total MCP calls: 5 (microsoft_docs_search: 3, microsoft_docs_fetch: 2, microsoft_code_sample_search: 1)\" — the enumerated components sum to 6, not 5. The line is internally inconsistent as written, independently of anything this session did. Second: the line has no defined referent. If it records the original generation run it is a historical fact that should not move, and if it describes the file current provenance it is now wrong, because idx-26h added two sources fetched live 2026-08-09. The file does not say which, so no reader and no check can adjudicate it. Third: \"Confidence: 80% Verified (MCP), 20% Baseline\" cannot be checked at all, and THAT is the defect rather than any particular mismatch. Read as list positions it is 10/5 before idx-26h and 12/5 after (67/33 and 71/29), matching neither — but that reading is an assumption, and the sibling file counts the same kind of claim differently (\"15 (8 verified fra MCP, 7 baseline/code samples)\" folds code samples into the baseline side and does not count list positions at all). Whether the percentages describe source counts, a different partition, or content proportion is undefined, so no denominator can be asserted. PRE-EXISTING, not created by idx-26h. Do not \"fix\" the percentages against an assumed denominator - decide the referent first. Note for the reviewer: this footer block form is likely replicated across the corpus, so the fix should be decided as a form, not as one file. FOURTH LOCATOR, introduced by idx-26h and named here rather than silently repaired: the section now spells the same compound two ways eight lines apart — line 101 \"model- og data-innsikter\" (pre-existing) against the rewritten role row \"modell- og data-innsikter\". The row spelling is the operator-ratified string, so it was NOT quietly aligned; the pair is the idx-26d mixed-dialect class reappearing, and which spelling wins is a form decision for the file, not a typo fix. The stamp is not falsified by it — the stamp claims verification against source, not orthographic consistency — which is exactly why no check will ever catch it. FIFTH LOCATOR, adjudicated as OUT OF SCOPE here rather than overlooked - recorded because idx-26g warns the next reviewer not to triage this class as citation hygiene. The header carries **Status:** GA at line 4. It is NOT falsified by idx-26h stamp: line 4 sits in the bold-label header block above the --- and ## Innhold, and the first Confidence stamp is at line 59, section-terminal for section 1, so no stamp in this file reaches line 4. But the field referent is undefined CORPUS-WIDE, which is the real finding: measured across skills/*/references/, **Status:** mixes two vocabularies that answer different questions - document maturity (Established Practice 43, Gjeldende 18, Reference 7, Komplett 2) and product availability (GA 252, Preview 2, \"GA - avvikles 31. mars 2029\" 2). This file covers Transparency Notes (GA), Model Cards (practice) and the scorecard (public preview) at once, and the corpus ALREADY carries the precedent form for exactly that case: \"GA / Preview (varies by feature)\", 2 files. So the question idx-26g raises for the sibling is not local to either file - it is a corpus-wide field-semantics decision, and fixing it one file at a time would set the convention by accident. CORRECTION AND RE-SCOPE OF THE FIFTH LOCATOR, 2026-08-09, after idx-26g closed. (a) THE MEASUREMENT ABOVE WAS TAKEN OVER THE WRONG POPULATION. It counted every **Status:** occurrence under skills/*/references/ (434), which mixes the line-4 header field with 47 SECTION-LEVEL **Status:** lines in file bodies - two different fields with different referents. Re-measured on the header field alone (FNR<=10): 387 occurrences over 389 files, 69 distinct values. Corrected counts: GA 249 (not 252), Preview 1 (not 2), Komplett 1 (not 2). Established Practice 43, Gjeldende 18, Reference 7 hold as stated. The two-vocabulary finding itself is CONFIRMED on the corrected population - document maturity and product availability really are mixed in one field. (b) BUT THE CONSEQUENCE CLAIM IS FALSE. 'Fixing it one file at a time would set the convention by accident' does not hold: the header field has 69 distinct values over 387 files, roughly 44 of them appearing exactly once, and 35+ are compound GA/Preview forms. There is no single convention available to set by accident; writing an accurate compound value JOINS an established practice. The defensible narrow claim is the one idx-26g acted on: a file that has already chosen the product-availability axis gets its chosen axis made truthful, which is not the same as choosing an axis for the corpus. (c) THE FORM IS NOW DECIDED BY PRECEDENT, so this locator is no longer blocked on a corpus-wide decision. Operator ratified 'GA / Preview (Responsible AI scorecard)' for the sibling file 2026-08-09, i.e. the X / Preview (Y) family with the parenthetical naming the preview surface. THIS file's header (**Status:** GA at line 4) covers Transparency Notes (GA), Model Cards (practice) and the scorecard (public preview) at once and is therefore false in the same way. Apply the ratified form here or diverge deliberately - but the divergence would now be introduced by this entry, not inherited. (d) THE FOOTER ARITHMETIC DEFECT IS CONFIRMED REPLICATED, not merely 'likely'. This entry predicted the footer form recurs corpus-wide; measured in the sibling stakeholder-communication-ai-decisions.md, whose footer reads '5 (3 docs_search, 2 docs_fetch, 1 code_sample_search)' - components summing to 6, same class, different wording and different field name. Booked as idx-26k. The form decision this entry owns therefore governs at least two files. (e) ANCHOR ADDED 2026-08-09, same day, because re-scoping locator five made it actionable without giving any check a grip on it. This entry's anchors were the three strings it was raised with; **Status:** GA was not among them, so check-g7-queue.mjs exit 0 and the 1047-test suite both passed while the locator existed only in this prose. A session could have closed this entry against its three anchored locators, written a resolution, and left line 4 reading GA - the 'finding is not closing' failure one hop downstream. Verified unique in the file (1 occurrence, line 4) before adding.",
      "evidence": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md footer; idx-26h resolution; docs/r11-pilot-results.md",
      "anchors": [
        "**Total MCP calls:** 5 (microsoft_docs_search: 3, microsoft_docs_fetch: 2, microsoft_code_sample_search: 1)",
        "**Confidence:** 80% Verified (MCP), 20% Baseline (established frameworks)",
        "| **Risk officers** | Dele modell- og data-innsikter for auditability, slik AI-regelverk krever |",
        "**Status:** GA"
      ],
      "resolution": "Operator-ratified 2026-08-09. Four anchored locators, closed on three different grounds, plus one adjacent defect measured during the edit and booked rather than repaired.\n(1) HEADER, by precedent, not by re-asking: **Status:** GA -> **Status:** GA / Preview (Responsible AI scorecard). The idx-26g ratification of 2026-08-09 settled the form (the X / Preview (Y) family, parenthetical naming the preview surface), so this locator was applied rather than re-opened. It needed no new citation and no body change: this file ALREADY carries the preview fact in its own body at line 129 ('**Status:** Public preview (Azure ML) - leveres uten SLA, og Microsoft anbefaler den ikke for production workloads'), under a section-3 stamp already dated 2026-08-09, and cites the two scorecard pages as sources 4 and 12. The header therefore contradicted the file's own measured body, which is the strongest form this defect can take. PARENTHETICAL COMPLETENESS VERIFIED rather than assumed - a parenthetical narrower than reality would be the idx-26h defect in a new costume: grepped every 'preview' occurrence in the file (7 hits: 56, 129, 504, 534, 735, 766, 768). Six are the scorecard. The seventh (line 56, 'Warnings om Computer Use preview security risks') is content INSIDE the Azure OpenAI Transparency Note example - it describes what that note warns about, not a product surface whose availability this file states. The scorecard is the only preview surface this file makes an availability claim about, so the parenthetical is complete.\n(2) DIALECT PAIR, ratified as a form decision, not a typo fix: line 101 'model- og data-innsikter' -> 'modell- og data-innsikter', aligning to the operator-ratified string in the role row at line 109. Corpus measured before deciding: 'modell- og' 4 occurrences, 'model- og' 2. The second 'model- og' (ai-red-team-operations-practical.md:87) was deliberately NOT touched - operator scoped this to the one file, and that occurrence is booked below in the METHOD note rather than silently swept.\n(3) FOOTER PROVENANCE BLOCK, referent decided as a FORM governing at least 23 files, not per file. The decisive evidence was measured, not inferred: 99675d5 (idx-26h, same day) changed '**Unique sources:** 15 URLs' -> '17 URLs' while leaving '**Total MCP calls:** 5' and '**Confidence:** 80%' untouched, so the block ALREADY carried a mixed referent - one field maintained as current provenance, two frozen - and it was mixed by a ratified G7 edit. Second measured fact: NO generation log exists anywhere in the repo (grepped scripts/ and docs/ for mcp_calls / MCP calls - only the queue and r11-pilot-results.md mention it, both as analysis, not as a run record). So '5' is unverifiable under BOTH readings of the referent, which removes '5 -> 6' from the option space under either branch rather than just under one. Third measured fact, corpus-wide: 23 such footer lines in 23 files, hand-classified (a regex pass produced three false positives and they were corrected by hand before the count entered the ratification label) - 10 internally consistent, 8 inconsistent, 1 ambiguous, 4 not checkable. ALL EIGHT inconsistencies run the same direction (stated total < sum of components), zero run the other way, which is evidence the number was never transcribed from an actual run.\nRATIFIED FORM: current provenance, one referent for the whole block. '**Total MCP calls:** 5 (...)' DELETED - unmeasurable, with no artifact that could ever adjudicate it. '**Unique sources:** 17 URLs' KEPT - verified true this session (17 numbered entries, 17 URLs, all distinct), and already on the current-provenance referent by idx-26h's precedent.\n(4) THE 80/20 LINE, closed in the same edit rather than separately, because it is the same block with the same undefined referent - splitting them would repeat the bundling error idx-26g caught. '**Confidence:** 80% Verified (MCP), 20% Baseline (established frameworks)' -> '**Confidence:** 17 kilder - 12 oppfoert under «Verified sources», 5 under «Baseline sources»'. An uncheckable percentage with no denominator becomes a structural count with a defined one. THE REPLACEMENT WORDING WAS ITSELF CORRECTED BEFORE COMMIT: the first draft read '12 av 17 kilder verifisert via MCP (nr. 1-12), 5 baseline (nr. 13-17)', which would have ASSERTED that source 7 is MCP-verified - and source 7 is self-labelled '(Status: Baseline ...)'. That draft would have authored the very defect class being closed. The shipped wording counts SECTION MEMBERSHIP only and asserts nothing about any individual source's status, which leaves locator (5) below genuinely open instead of quietly asserted over. The field label '**Confidence:**' was KEPT deliberately, not by oversight: renaming it would introduce a new field name into a form that stands in 23 files, which is wider than what was ratified.\n(5) ADJACENT DEFECT, MEASURED AND BOOKED, NOT REPAIRED - eleventh instance of 'the defect sits NEXT TO the edit'. The two source sections contradict themselves in exactly two places, in opposite directions: #7 (Microsoft Responsible AI Standard v2, line 747) sits under '**Verified sources (MCP: microsoft-learn):**' but is itself labelled '(Status: Baseline - ...)', and #17 (Developing Responsible Generative AI Applications, line 790) sits under '**Baseline sources (model knowledge + MCP-inferred):**' but is itself labelled '(Status: Verified 2026-02 - ...)'. Booked as idx-26s with both lines anchored. It does NOT invalidate the replacement written in (4): the count 12/5 is INVARIANT under either resolution - by section membership it is 12/5, and swapping both mislabelled sources gives verified {1-6,8-12,17} = 12 and baseline {7,13,14,15,16} = 5.\nNO RE-DATING DECISION WAS REQUIRED ANYWHERE IN THIS EDIT, and that was adjudicated before writing rather than discovered after, because idx-26g established that re-dating is a scope decision taken up front. Measured: every stamp in this file sits at lines 59, 95, 131, 160, 312, 378 - all section-terminal, and all before line 378. Nothing after 378 carries a stamp except the inline '*(Verified MCP 2026-06-19)*' on source 8, which is part of a source entry and not a section stamp. Consequences: line 4 sits ABOVE the first stamp (59, terminal for section 1 which opens at 39), so the header edit falsifies no stamp; the Kilder section and the whole footer sit under NO stamp, so the footer edits falsify none either; and line 101 sits under the section-3 stamp at 131, which is already dated 2026-08-09 AND claims verification against source rather than orthographic consistency - this entry says so itself - so an orthographic alignment neither falsifies it nor requires re-dating it.\n'**Last updated:** 2026-06-19' left untouched, following the precedent of all twelve prior ratified corpus edits.\nEXPLICITLY NOT COVERED: the 21 other files carrying this footer form. Operator ratified one queue entry per affected file rather than a single class-wide entry, precisely so no locator survives only in prose - the 795d494 failure. Booked as idx-26l through idx-26r (6 inconsistent files plus 1 ambiguous), each with a verbatim anchor verified unique in its file before being written.\nSCOPE ADDENDUM, 2026-08-09, same day, written because the resolution above understated what the ratified ground actually covers. THE GROUND IS UNVERIFIABILITY, NOT ARITHMETIC. The operator ratified deletion because the line is unmeasurable with no generation log to adjudicate it - a property that holds for ALL 23 lines, not only the 8 that also fail their own arithmetic. Internal inconsistency was the EVIDENCE that the number was never transcribed from a run; it was never the reason for deleting it. But the ratification question's own option text defined 'affected file' as the inconsistent set, so booking stopped at 7 - and no machine sees the framing of a question. That is the 'a ratification question can carry a false premise' class, this time in a question I wrote. CONSEQUENCE, STATED RATHER THAN LEFT IMPLIED: 14 files carry the condemned line with NO queue entry and, until this addendum, no stated reason - 10 internally consistent and 4 not checkable. They are NOT excluded on merit and NOT judged out of scope; they are unbooked because expanding past the ratified 7 is a scope decision belonging to the operator, not to the session that discovered the gap. Raised as open operator question #17 in STATE rather than resolved here. The 10 consistent: microsoft-graph-api-copilot-integration.md:544, rag-cost-optimization.md:558, translator-document-translation.md:402, agent-memory-and-context-management.md:535, foundry-workflows-visual-orchestration.md:651, multi-agent-orchestration-patterns.md:720, real-time-streaming-monitoring.md:560, continuous-improvement-feedback-loops.md:599, budget-forecasting-ai-projects.md:529, ai-security-scoring-framework.md:514. The 4 not checkable (a total with no per-tool numbers to sum, so the arithmetic test cannot even be applied - but the total is just as unverifiable): multi-turn-conversation-management.md:683, adaptive-cards-copilot-responses.md:517, ai-services-cost-optimization.md:396, ai-services-networking-security.md:620.\nTWO COUNTS THIS EDIT INVALIDATED, corrected in STATE in the same pass rather than left to a future session that would have built on them. (a) The footer population is now 21 lines, not 23 - this edit deleted two, both from the inconsistent bucket, so the corpus now carries 10 consistent / 6 inconsistent / 1 ambiguous / 4 not checkable. (b) The header **Status:** counts in STATE's binding Telling section were ALREADY stale before this session, and re-measuring proved it: they read GA 249 over 387 occurrences / 69 distinct, but that measurement was taken inside the idx-26g session BEFORE 96639f7 was applied. Ground truth now: 387 occurrences, 70 distinct, GA 247, and 'GA / Preview (Responsible AI scorecard)' at 2 occurrences. The chain is exact - 249 -> 248 (26g's edit) -> 247 (this one), and the distinct count rose 69 -> 70 when 26g first created that string, then held because this edit added a second instance of an existing value.\nANCHOR UNIQUENESS for idx-26s verified after the fact rather than before, and named as a lapse: the gate proves PRESENCE (text.includes), never uniqueness, so a non-unique anchor passes silently. All three occur exactly once in the file (grep -cF). The discipline this entry claims for idx-26l..26r had not been run on idx-26s when it was written."
    },
    {
      "id": "idx-26k",
      "file": "skills/ms-ai-governance/references/responsible-ai/stakeholder-communication-ai-decisions.md",
      "class": "replacement",
      "status": "resolved",
      "raised": "2026-08-09",
      "summary": "Surfaced while closing idx-26g in this file, measured rather than inferred, and deliberately NOT repaired in that edit. The footer provenance line reads '**MCP calls gjennomført**: 5 (3 docs_search, 2 docs_fetch, 1 code_sample_search)'. The enumerated components sum to 6, not 5, so the line is internally inconsistent as written, independently of anything any session did to this file. This is the same defect class as idx-26j's first locator in the sibling file transparency-documentation-standards.md ('Total MCP calls: 5 (…: 3, …: 2, …: 1)'), which confirms idx-26j's prediction that the footer form is replicated across the corpus - the wording and the field name differ, the defect does not. The referent is undefined in the same way, and that is why this must not be 'fixed' by changing 5 to 6: if the line records the original generation run it is a historical fact that should not move, and if it describes the file's current provenance it is now wrong for a second reason, because idx-26g added a source fetched live on 2026-08-09. The file does not say which, so neither a reader nor a check can adjudicate it. DECIDE THE REFERENT FIRST, AND AS A FORM, NOT PER FILE - idx-26j owns that decision and this entry is its second measured instance. Do not close this one in isolation.",
      "evidence": "skills/ms-ai-governance/references/responsible-ai/stakeholder-communication-ai-decisions.md footer; idx-26g resolution; idx-26j first locator; docs/r11-pilot-results.md",
      "anchors": [
        "**MCP calls gjennomført**: 5 (3 docs_search, 2 docs_fetch, 1 code_sample_search)"
      ],
      "resolution": "Operator-ratified 2026-08-09, closed together with idx-26j as that entry required ('DECIDE THE REFERENT FIRST, AND AS A FORM, NOT PER FILE - idx-26j owns that decision and this entry is its second measured instance. Do not close this one in isolation.'). The ratified form is current provenance with one referent for the whole footer block, so '**MCP calls gjennomfoert**: 5 (3 docs_search, 2 docs_fetch, 1 code_sample_search)' was DELETED rather than corrected to 6 - the same reasoning as idx-26j: no generation log exists in the repo, so the number is unverifiable under both readings of the referent and 5 -> 6 was never on the menu.\nNO OTHER EDIT WAS NEEDED IN THIS FILE, and that was verified rather than assumed. This file's remaining two footer fields are already on the current-provenance referent and already checkable: '**Total kilder**: 16 (9 verified fra MCP, 7 baseline/code samples)' was set by idx-26g earlier the same day and re-verified here by counting - 16 numbered entries, 9 carrying URLs; and '**Confidence vurdering**' is a qualitative per-topic list with banded ranges, not a percentage split of the file, so it carries no undefined denominator of the kind idx-26j's fourth locator was about. Deleting one line therefore leaves this footer whole rather than leaving a residue - the diff context was read before commit and the surrounding block still reads as one unit.\nSTAMP: no re-dating decision required. idx-26g already adjudicated that '*(Verified MCP 2026-04)*' at line 795 is section-terminal for 'For arkitekten (Cosmo)' and does not reach the Kilder section, so this footer sits under no stamp. '**Last updated:**' left untouched, per precedent."
    },
    {
      "id": "idx-26l",
      "file": "skills/ms-ai-engineering/references/mlops-genaiops/feedback-loops-continuous-improvement.md",
      "class": "replacement",
      "status": "resolved",
      "raised": "2026-08-09",
      "summary": "Booked 2026-08-09 as one of seven per-file entries, on operator ratification that the class finding gets a queue entry per affected file rather than a single class-wide entry - the queue schema carries one `file` per entry, and a class-wide entry would have left these files invisible to check-g7-queue.mjs, which is the 795d494 failure (a locator alive only in prose while both gates go green). MEASURED, not inferred: 23 footer provenance lines in 23 files under skills/*/references/ state a total number of MCP calls followed by an enumeration of per-tool counts. Hand-classified - a regex pass produced three false positives (translator-document-translation.md:402 and rag-cost-optimization.md:558 spell the arithmetic out explicitly and are correct; foundry-agent-service-ga.md:560 is ambiguous rather than wrong) and they were corrected by hand before the count was used: 10 internally consistent, 8 internally inconsistent, 1 ambiguous, 4 not checkable (no per-tool numbers). ALL EIGHT inconsistencies run the same direction, stated total < sum of components, and none run the other way, which is evidence the total was never transcribed from an actual run. THE REFERENT IS UNDEFINED AND THAT IS THE DEFECT: if the line records the original generation run it is a historical fact that must not move, and if it describes the file's current provenance it is wrong for a second reason after any live-fetched edit. No artifact in the repo can adjudicate it - grepped scripts/ and docs/ for a generation log recording MCP calls per file and there is none. DO NOT 'FIX' THIS BY CHANGING THE TOTAL TO THE SUM. The form was ratified on idx-26j 2026-08-09: current provenance, one referent for the whole footer block, and the unverifiable MCP-calls line is DELETED rather than corrected. Applied there and in idx-26k; apply the same form here. Counting claims in the same block that ARE checkable (source counts, URL counts) are kept and verified, not deleted with it.\nTHIS FILE: stated 6, components sum to 8 (3 + 3 + 2). Largest gap in the corpus.",
      "evidence": "footer provenance block in this file; idx-26j resolution (ratified form); idx-26k (second instance); docs/r11-pilot-results.md",
      "anchors": [
        "**MCP calls:** 6 (microsoft_docs_search: 3, microsoft_docs_fetch: 3, microsoft_code_sample_search: 2)"
      ],
      "resolution": "Operator-ratified form applied 2026-08-09, second batch. The form is idx-26j's: current provenance, one referent for the whole footer block, and the unverifiable MCP-calls line is DELETED rather than corrected to the sum. The ground is UNVERIFIABILITY, not arithmetic - re-verified independently this session rather than inherited: grepped scripts/, docs/ and tests/ for any generation log recording MCP calls per file, and the only two artifacts that mention the field are the queue itself and docs/r11-pilot-results.md, both analysis rather than a run record. So the number is unadjudicable under BOTH readings of the referent, in this file as in the two closed by 088cf06.\nDELETED: '**MCP calls:** 6 (microsoft_docs_search: 3, microsoft_docs_fetch: 3, microsoft_code_sample_search: 2)'. This is the only file of the seven where the line stood as its OWN PARAGRAPH (blank line above and below), so the deletion took the line AND one adjacent blank, exactly as 088cf06 did in stakeholder-communication-ai-decisions.md. The other six sit inside a tight block where the line alone goes. A deletion correct on the string and wrong on the whitespace would leave a broken paragraph, which is a defect the anchor check cannot see.\nWHAT REMAINS IN THE FOOTER WAS CHECKED, NOT ASSUMED: the block's only other field is '**Dato for siste verifikasjon:** 2026-04-10', which is a date, not a count - it carries no denominator and states nothing this session can falsify (the three MCP-verified source annotations in the same section all read 'Verified MCP 2026-04'). Nothing else in the block is a counting claim, so nothing was kept-and-verified here and nothing was left unmeasured.\nANCHOR UNIQUENESS verified with grep -cF before writing, not with the gate's text.includes - the gate proves PRESENCE, never uniqueness, and 26j named the omission of this check as an explicit lapse.\nNo re-dating decision required: the footer sits under no section stamp. '**Last updated:**' untouched, per the precedent of all thirteen prior ratified corpus edits."
    },
    {
      "id": "idx-26m",
      "file": "skills/ms-ai-engineering/references/rag-architecture/rag-caching-optimization.md",
      "class": "replacement",
      "status": "resolved",
      "raised": "2026-08-09",
      "summary": "Booked 2026-08-09 as one of seven per-file entries, on operator ratification that the class finding gets a queue entry per affected file rather than a single class-wide entry - the queue schema carries one `file` per entry, and a class-wide entry would have left these files invisible to check-g7-queue.mjs, which is the 795d494 failure (a locator alive only in prose while both gates go green). MEASURED, not inferred: 23 footer provenance lines in 23 files under skills/*/references/ state a total number of MCP calls followed by an enumeration of per-tool counts. Hand-classified - a regex pass produced three false positives (translator-document-translation.md:402 and rag-cost-optimization.md:558 spell the arithmetic out explicitly and are correct; foundry-agent-service-ga.md:560 is ambiguous rather than wrong) and they were corrected by hand before the count was used: 10 internally consistent, 8 internally inconsistent, 1 ambiguous, 4 not checkable (no per-tool numbers). ALL EIGHT inconsistencies run the same direction, stated total < sum of components, and none run the other way, which is evidence the total was never transcribed from an actual run. THE REFERENT IS UNDEFINED AND THAT IS THE DEFECT: if the line records the original generation run it is a historical fact that must not move, and if it describes the file's current provenance it is wrong for a second reason after any live-fetched edit. No artifact in the repo can adjudicate it - grepped scripts/ and docs/ for a generation log recording MCP calls per file and there is none. DO NOT 'FIX' THIS BY CHANGING THE TOTAL TO THE SUM. The form was ratified on idx-26j 2026-08-09: current provenance, one referent for the whole footer block, and the unverifiable MCP-calls line is DELETED rather than corrected. Applied there and in idx-26k; apply the same form here. Counting claims in the same block that ARE checkable (source counts, URL counts) are kept and verified, not deleted with it.\nTHIS FILE: stated 6, components sum to 7 (4 + 2 + 1). Note this file ALSO carries the open idx-18, which is a different defect in a different part of the file - closing one does not close the other.",
      "evidence": "footer provenance block in this file; idx-26j resolution (ratified form); idx-26k (second instance); docs/r11-pilot-results.md",
      "anchors": [
        "**MCP calls:** 6 (4 docs_search + 2 docs_fetch + 1 code_sample_search)"
      ],
      "resolution": "Operator-ratified form applied 2026-08-09, second batch. The form is idx-26j's: current provenance, one referent for the whole footer block, and the unverifiable MCP-calls line is DELETED rather than corrected to the sum. The ground is UNVERIFIABILITY, not arithmetic - re-verified independently this session rather than inherited: grepped scripts/, docs/ and tests/ for any generation log recording MCP calls per file, and the only two artifacts that mention the field are the queue itself and docs/r11-pilot-results.md, both analysis rather than a run record. So the number is unadjudicable under BOTH readings of the referent, in this file as in the two closed by 088cf06.\nDELETED: '**MCP calls:** 6 (4 docs_search + 2 docs_fetch + 1 code_sample_search)'. Tight block, line only.\nKEPT AND VERIFIED BY COUNTING, not assumed: '**Totalt antall kilder:** 9 unike Microsoft Learn URLer' is TRUE - the Kilder section carries 9 numbered entries and exactly 9 distinct URLs, every one on learn.microsoft.com, so both halves of the claim (the count and the 'Microsoft Learn' qualifier) hold. '**Sist verifisert:** 2026-06-19' is a date, not a count. Deleting one line leaves this three-line block as a coherent two-line block.\nANCHOR UNIQUENESS verified with grep -cF before writing, not with the gate's text.includes - the gate proves PRESENCE, never uniqueness, and 26j named the omission of this check as an explicit lapse.\nTHIS FILE ALSO CARRIES THE OPEN idx-18, a different defect in a different part of the file. Closing this entry does not close that one, and no edit outside the footer was made here."
    },
    {
      "id": "idx-26n",
      "file": "skills/ms-ai-engineering/references/agent-orchestration/agent-to-agent-a2a-protocol.md",
      "class": "replacement",
      "status": "resolved",
      "raised": "2026-08-09",
      "summary": "Booked 2026-08-09 as one of seven per-file entries, on operator ratification that the class finding gets a queue entry per affected file rather than a single class-wide entry - the queue schema carries one `file` per entry, and a class-wide entry would have left these files invisible to check-g7-queue.mjs, which is the 795d494 failure (a locator alive only in prose while both gates go green). MEASURED, not inferred: 23 footer provenance lines in 23 files under skills/*/references/ state a total number of MCP calls followed by an enumeration of per-tool counts. Hand-classified - a regex pass produced three false positives (translator-document-translation.md:402 and rag-cost-optimization.md:558 spell the arithmetic out explicitly and are correct; foundry-agent-service-ga.md:560 is ambiguous rather than wrong) and they were corrected by hand before the count was used: 10 internally consistent, 8 internally inconsistent, 1 ambiguous, 4 not checkable (no per-tool numbers). ALL EIGHT inconsistencies run the same direction, stated total < sum of components, and none run the other way, which is evidence the total was never transcribed from an actual run. THE REFERENT IS UNDEFINED AND THAT IS THE DEFECT: if the line records the original generation run it is a historical fact that must not move, and if it describes the file's current provenance it is wrong for a second reason after any live-fetched edit. No artifact in the repo can adjudicate it - grepped scripts/ and docs/ for a generation log recording MCP calls per file and there is none. DO NOT 'FIX' THIS BY CHANGING THE TOTAL TO THE SUM. The form was ratified on idx-26j 2026-08-09: current provenance, one referent for the whole footer block, and the unverifiable MCP-calls line is DELETED rather than corrected. Applied there and in idx-26k; apply the same form here. Counting claims in the same block that ARE checkable (source counts, URL counts) are kept and verified, not deleted with it.\nTHIS FILE: stated 4, components sum to 5 (3 + 2). Only two tools enumerated, so the gap cannot be explained by a missing third category.",
      "evidence": "footer provenance block in this file; idx-26j resolution (ratified form); idx-26k (second instance); docs/r11-pilot-results.md",
      "anchors": [
        "**MCP calls:** 4 (3x search, 2x fetch)"
      ],
      "resolution": "Operator-ratified form applied 2026-08-09, second batch. The form is idx-26j's: current provenance, one referent for the whole footer block, and the unverifiable MCP-calls line is DELETED rather than corrected to the sum. The ground is UNVERIFIABILITY, not arithmetic - re-verified independently this session rather than inherited: grepped scripts/, docs/ and tests/ for any generation log recording MCP calls per file, and the only two artifacts that mention the field are the queue itself and docs/r11-pilot-results.md, both analysis rather than a run record. So the number is unadjudicable under BOTH readings of the referent, in this file as in the two closed by 088cf06.\nDELETED: '**MCP calls:** 4 (3x search, 2x fetch)'. This was the file's LAST line; after deletion the file still ends with exactly one newline, verified rather than assumed.\nKEPT, AND THE VERIFICATION FAILED - BOOKED, NOT REPAIRED. '**Total sources cited:** 10 unike URLer fra MCP-research + tavily-research' does NOT verify: the Kilder section has 10 numbered entries but 11 distinct URLs, because entry 8 (A2A Protocol Specification) carries two - the spec page and the v1.0 announcement. The line is therefore true read as SOURCES and false read as URLs, and it says both words at once. That is the same undefined-referent defect as the line just deleted, surviving inside the line the form told us to keep. Booked as idx-26t with a verbatim anchor rather than repaired here, for two reasons: the ratified form covers the MCP-calls line and says kept counts are 'verified', which presumed they would pass and does not say what to do when one fails; and repairing it means choosing between 10 and 11, which is a referent decision belonging to the operator. NOTE THE DIRECTION: stated 10 < actual 11 runs the SAME way as all eight MCP-calls inconsistencies, zero the other way.\nANCHOR UNIQUENESS verified with grep -cF before writing, not with the gate's text.includes - the gate proves PRESENCE, never uniqueness, and 26j named the omission of this check as an explicit lapse."
    },
    {
      "id": "idx-26o",
      "file": "skills/ms-ai-engineering/references/agent-orchestration/agent-to-agent-communication.md",
      "class": "replacement",
      "status": "resolved",
      "raised": "2026-08-09",
      "summary": "Booked 2026-08-09 as one of seven per-file entries, on operator ratification that the class finding gets a queue entry per affected file rather than a single class-wide entry - the queue schema carries one `file` per entry, and a class-wide entry would have left these files invisible to check-g7-queue.mjs, which is the 795d494 failure (a locator alive only in prose while both gates go green). MEASURED, not inferred: 23 footer provenance lines in 23 files under skills/*/references/ state a total number of MCP calls followed by an enumeration of per-tool counts. Hand-classified - a regex pass produced three false positives (translator-document-translation.md:402 and rag-cost-optimization.md:558 spell the arithmetic out explicitly and are correct; foundry-agent-service-ga.md:560 is ambiguous rather than wrong) and they were corrected by hand before the count was used: 10 internally consistent, 8 internally inconsistent, 1 ambiguous, 4 not checkable (no per-tool numbers). ALL EIGHT inconsistencies run the same direction, stated total < sum of components, and none run the other way, which is evidence the total was never transcribed from an actual run. THE REFERENT IS UNDEFINED AND THAT IS THE DEFECT: if the line records the original generation run it is a historical fact that must not move, and if it describes the file's current provenance it is wrong for a second reason after any live-fetched edit. No artifact in the repo can adjudicate it - grepped scripts/ and docs/ for a generation log recording MCP calls per file and there is none. DO NOT 'FIX' THIS BY CHANGING THE TOTAL TO THE SUM. The form was ratified on idx-26j 2026-08-09: current provenance, one referent for the whole footer block, and the unverifiable MCP-calls line is DELETED rather than corrected. Applied there and in idx-26k; apply the same form here. Counting claims in the same block that ARE checkable (source counts, URL counts) are kept and verified, not deleted with it.\nTHIS FILE: stated 4, components sum to 6 (3 + 2 + 1). Field name uses the '**MCP calls**:' dialect (bold ends before the colon), one of four distinct field-name spellings measured across the 23 files.",
      "evidence": "footer provenance block in this file; idx-26j resolution (ratified form); idx-26k (second instance); docs/r11-pilot-results.md",
      "anchors": [
        "**MCP calls**: 4 (3x search, 2x fetch, 1x code samples)"
      ],
      "resolution": "Operator-ratified form applied 2026-08-09, second batch. The form is idx-26j's: current provenance, one referent for the whole footer block, and the unverifiable MCP-calls line is DELETED rather than corrected to the sum. The ground is UNVERIFIABILITY, not arithmetic - re-verified independently this session rather than inherited: grepped scripts/, docs/ and tests/ for any generation log recording MCP calls per file, and the only two artifacts that mention the field are the queue itself and docs/r11-pilot-results.md, both analysis rather than a run record. So the number is unadjudicable under BOTH readings of the referent, in this file as in the two closed by 088cf06.\nDELETED: '**MCP calls**: 4 (3x search, 2x fetch, 1x code samples)' - the '**MCP calls**:' dialect with the bold ending before the colon, one of four field-name spellings measured across the 23 files. Last line of the file; single trailing newline verified after the edit.\nKEPT AND VERIFIED AS A COUNT: '**Total sources cited**: 7 unique URLs fra MCP-research' - 7 numbered entries and exactly 7 distinct URLs, so the arithmetic holds.\nBUT THE PROVENANCE QUALIFIER DOES NOT, AND IT WAS MEASURED RATHER THAN PASSED OVER: only 5 of the 7 URLs are on learn.microsoft.com. Sources 6 (a2a-protocol.org) and 7 (jsonrpc.org) cannot have come from the microsoft-learn MCP server, which serves learn.microsoft.com and nothing else, so 'fra MCP-research' overclaims for 2 of 7. Booked as idx-26w rather than repaired - the same family as idx-26t, and the same reason: it is a provenance claim, and the form ratified so far governs counts. Contrast idx-26n's line, which names 'MCP-research + tavily-research' and so does cover its non-Learn sources.\nANCHOR UNIQUENESS verified with grep -cF before writing, not with the gate's text.includes - the gate proves PRESENCE, never uniqueness, and 26j named the omission of this check as an explicit lapse."
    },
    {
      "id": "idx-26p",
      "file": "skills/ms-ai-engineering/references/agent-orchestration/agent-365-governance-and-deployment.md",
      "class": "replacement",
      "status": "resolved",
      "raised": "2026-08-09",
      "summary": "Booked 2026-08-09 as one of seven per-file entries, on operator ratification that the class finding gets a queue entry per affected file rather than a single class-wide entry - the queue schema carries one `file` per entry, and a class-wide entry would have left these files invisible to check-g7-queue.mjs, which is the 795d494 failure (a locator alive only in prose while both gates go green). MEASURED, not inferred: 23 footer provenance lines in 23 files under skills/*/references/ state a total number of MCP calls followed by an enumeration of per-tool counts. Hand-classified - a regex pass produced three false positives (translator-document-translation.md:402 and rag-cost-optimization.md:558 spell the arithmetic out explicitly and are correct; foundry-agent-service-ga.md:560 is ambiguous rather than wrong) and they were corrected by hand before the count was used: 10 internally consistent, 8 internally inconsistent, 1 ambiguous, 4 not checkable (no per-tool numbers). ALL EIGHT inconsistencies run the same direction, stated total < sum of components, and none run the other way, which is evidence the total was never transcribed from an actual run. THE REFERENT IS UNDEFINED AND THAT IS THE DEFECT: if the line records the original generation run it is a historical fact that must not move, and if it describes the file's current provenance it is wrong for a second reason after any live-fetched edit. No artifact in the repo can adjudicate it - grepped scripts/ and docs/ for a generation log recording MCP calls per file and there is none. DO NOT 'FIX' THIS BY CHANGING THE TOTAL TO THE SUM. The form was ratified on idx-26j 2026-08-09: current provenance, one referent for the whole footer block, and the unverifiable MCP-calls line is DELETED rather than corrected. Applied there and in idx-26k; apply the same form here. Counting claims in the same block that ARE checkable (source counts, URL counts) are kept and verified, not deleted with it.\nTHIS FILE: stated 4, components sum to 7 (3 + 3 + 1).",
      "evidence": "footer provenance block in this file; idx-26j resolution (ratified form); idx-26k (second instance); docs/r11-pilot-results.md",
      "anchors": [
        "**Total MCP calls:** 4 (microsoft_docs_search x3, microsoft_docs_fetch x3, microsoft_code_sample_search x1)"
      ],
      "resolution": "Operator-ratified form applied 2026-08-09, second batch. The form is idx-26j's: current provenance, one referent for the whole footer block, and the unverifiable MCP-calls line is DELETED rather than corrected to the sum. The ground is UNVERIFIABILITY, not arithmetic - re-verified independently this session rather than inherited: grepped scripts/, docs/ and tests/ for any generation log recording MCP calls per file, and the only two artifacts that mention the field are the queue itself and docs/r11-pilot-results.md, both analysis rather than a run record. So the number is unadjudicable under BOTH readings of the referent, in this file as in the two closed by 088cf06.\nDELETED: '**Total MCP calls:** 4 (microsoft_docs_search x3, microsoft_docs_fetch x3, microsoft_code_sample_search x1)'. In this file the condemned line stood FIRST and the surviving count SECOND, the reverse of the other six - checked before editing, because deleting by position rather than by string would have taken the wrong line here.\nKEPT AND VERIFIED BY COUNTING: '**Unique URLs:** 7 Microsoft Learn-artikler' is TRUE - 7 distinct URLs in the Kilder section, all seven on learn.microsoft.com, so the count and the 'Microsoft Learn' qualifier both hold. This file lists its sources as bullets rather than numbered entries, so the entry-vs-URL divergence that sank idx-26n's line cannot arise here.\nANCHOR UNIQUENESS verified with grep -cF before writing, not with the gate's text.includes - the gate proves PRESENCE, never uniqueness, and 26j named the omission of this check as an explicit lapse."
    },
    {
      "id": "idx-26q",
      "file": "skills/ms-ai-security/references/cost-optimization/azure-cost-management-ai.md",
      "class": "replacement",
      "status": "resolved",
      "raised": "2026-08-09",
      "summary": "Booked 2026-08-09 as one of seven per-file entries, on operator ratification that the class finding gets a queue entry per affected file rather than a single class-wide entry - the queue schema carries one `file` per entry, and a class-wide entry would have left these files invisible to check-g7-queue.mjs, which is the 795d494 failure (a locator alive only in prose while both gates go green). MEASURED, not inferred: 23 footer provenance lines in 23 files under skills/*/references/ state a total number of MCP calls followed by an enumeration of per-tool counts. Hand-classified - a regex pass produced three false positives (translator-document-translation.md:402 and rag-cost-optimization.md:558 spell the arithmetic out explicitly and are correct; foundry-agent-service-ga.md:560 is ambiguous rather than wrong) and they were corrected by hand before the count was used: 10 internally consistent, 8 internally inconsistent, 1 ambiguous, 4 not checkable (no per-tool numbers). ALL EIGHT inconsistencies run the same direction, stated total < sum of components, and none run the other way, which is evidence the total was never transcribed from an actual run. THE REFERENT IS UNDEFINED AND THAT IS THE DEFECT: if the line records the original generation run it is a historical fact that must not move, and if it describes the file's current provenance it is wrong for a second reason after any live-fetched edit. No artifact in the repo can adjudicate it - grepped scripts/ and docs/ for a generation log recording MCP calls per file and there is none. DO NOT 'FIX' THIS BY CHANGING THE TOTAL TO THE SUM. The form was ratified on idx-26j 2026-08-09: current provenance, one referent for the whole footer block, and the unverifiable MCP-calls line is DELETED rather than corrected. Applied there and in idx-26k; apply the same form here. Counting claims in the same block that ARE checkable (source counts, URL counts) are kept and verified, not deleted with it.\nTHIS FILE: stated 4, components sum to 6 (3 + 2 + 1).",
      "evidence": "footer provenance block in this file; idx-26j resolution (ratified form); idx-26k (second instance); docs/r11-pilot-results.md",
      "anchors": [
        "**MCP calls:** 4 (3x search, 2x fetch, 1x code sample)"
      ],
      "resolution": "Operator-ratified form applied 2026-08-09, second batch. The form is idx-26j's: current provenance, one referent for the whole footer block, and the unverifiable MCP-calls line is DELETED rather than corrected to the sum. The ground is UNVERIFIABILITY, not arithmetic - re-verified independently this session rather than inherited: grepped scripts/, docs/ and tests/ for any generation log recording MCP calls per file, and the only two artifacts that mention the field are the queue itself and docs/r11-pilot-results.md, both analysis rather than a run record. So the number is unadjudicable under BOTH readings of the referent, in this file as in the two closed by 088cf06.\nDELETED: '**MCP calls:** 4 (3x search, 2x fetch, 1x code sample)'.\nKEPT AND VERIFIED BY COUNTING: '**Total sources:** 8 unique Microsoft Learn URLs' is TRUE - the URL table has 8 rows and 8 distinct URLs, all on learn.microsoft.com.\nTWO FURTHER FOOTER LINES MEASURED AND BOOKED, NOT REPAIRED - this footer is the only one of the seven that carries more than counts.\n(a) '**File size:** ~14 KB' is FALSE, and unlike the MCP-calls line it is falsifiable rather than merely unverifiable, because git IS the artifact that adjudicates it. Measured at every commit that ever touched this file: 17388 bytes (2026-04-08) -> 17388 -> 17963 -> 17965 -> 18554 bytes today, i.e. 16.9 KB rising to 18.1 KB. The claim was already wrong at the file's FIRST commit, with the line present in that same version, so it was never true at any point the repo can observe - it cannot be rescued as a stale-but-once-true generation-time fact. Booked as idx-26u. Worth stating for whoever adjudicates it: under the referent ratified on idx-26j - current provenance, one referent for the whole block - a generation-time file size is the same category as a generation-time call count, so deletion would be a one-step consequence of an existing ratification rather than a new form.\n(b) '**Verification status:** 80% Microsoft-verified, 20% domain-specific (Norwegian public sector)' is the idx-26j locator-4 class - an uncheckable percentage with no denominator. IT WAS NOT CLOSED IN THE SAME EDIT, AND THAT IS A DEPARTURE FROM 26j THAT WAS MEASURED BEFORE IT WAS DECIDED. 26j could replace its percentage with a structural count because that file HAD a partition to count (12 sources under 'Verified sources', 5 under 'Baseline sources'). This file has no such partition: all 8 rows of the URL table are marked Verified, and the per-section table splits 3 Verified / 3 non-Verified, which is 50/50 and not 80/20 under any reading. Re-expressing the percentage here would require INVENTING a denominator - which is precisely 'the replacement authors the defect class it closes', the error caught in 26j's own draft before commit. Booked as idx-26v instead, following the idx-26s precedent of booking rather than repairing when the adjacent defect needs a decision this session cannot take.\nANCHOR UNIQUENESS verified with grep -cF before writing, not with the gate's text.includes - the gate proves PRESENCE, never uniqueness, and 26j named the omission of this check as an explicit lapse."
    },
    {
      "id": "idx-26r",
      "file": "skills/ms-ai-engineering/references/agent-orchestration/foundry-agent-service-ga.md",
      "class": "replacement",
      "status": "resolved",
      "raised": "2026-08-09",
      "summary": "Booked 2026-08-09 as one of seven per-file entries, on operator ratification that the class finding gets a queue entry per affected file rather than a single class-wide entry - the queue schema carries one `file` per entry, and a class-wide entry would have left these files invisible to check-g7-queue.mjs, which is the 795d494 failure (a locator alive only in prose while both gates go green). MEASURED, not inferred: 23 footer provenance lines in 23 files under skills/*/references/ state a total number of MCP calls followed by an enumeration of per-tool counts. Hand-classified - a regex pass produced three false positives (translator-document-translation.md:402 and rag-cost-optimization.md:558 spell the arithmetic out explicitly and are correct; foundry-agent-service-ga.md:560 is ambiguous rather than wrong) and they were corrected by hand before the count was used: 10 internally consistent, 8 internally inconsistent, 1 ambiguous, 4 not checkable (no per-tool numbers). ALL EIGHT inconsistencies run the same direction, stated total < sum of components, and none run the other way, which is evidence the total was never transcribed from an actual run. THE REFERENT IS UNDEFINED AND THAT IS THE DEFECT: if the line records the original generation run it is a historical fact that must not move, and if it describes the file's current provenance it is wrong for a second reason after any live-fetched edit. No artifact in the repo can adjudicate it - grepped scripts/ and docs/ for a generation log recording MCP calls per file and there is none. DO NOT 'FIX' THIS BY CHANGING THE TOTAL TO THE SUM. The form was ratified on idx-26j 2026-08-09: current provenance, one referent for the whole footer block, and the unverifiable MCP-calls line is DELETED rather than corrected. Applied there and in idx-26k; apply the same form here. Counting claims in the same block that ARE checkable (source counts, URL counts) are kept and verified, not deleted with it.\nTHIS FILE IS THE AMBIGUOUS CASE, booked in its own right rather than counted as consistent, because its reading IS the question the class raises. Read as rounds, 2 + 2 = 4 and the line is consistent; read as calls - which is what the field name says - 2 rounds of 4 parallel calls plus 2 fetches is 10, and the stated 4 is wrong. The line cannot be adjudicated without deciding whether the field counts calls or rounds, which is the same undefined-referent defect wearing different clothes. A regex classifier scored this as inconsistent and a generous reading scores it as consistent; neither is right, which is why it is here.",
      "evidence": "footer provenance block in this file; idx-26j resolution (ratified form); idx-26k (second instance); docs/r11-pilot-results.md",
      "anchors": [
        "**MCP calls:** 4 (2x search-rounds med 4 parallelle kall, 2x fetch)"
      ],
      "resolution": "Operator-ratified form applied 2026-08-09, second batch. The form is idx-26j's: current provenance, one referent for the whole footer block, and the unverifiable MCP-calls line is DELETED rather than corrected to the sum. The ground is UNVERIFIABILITY, not arithmetic - re-verified independently this session rather than inherited: grepped scripts/, docs/ and tests/ for any generation log recording MCP calls per file, and the only two artifacts that mention the field are the queue itself and docs/r11-pilot-results.md, both analysis rather than a run record. So the number is unadjudicable under BOTH readings of the referent, in this file as in the two closed by 088cf06.\nDELETED: '**MCP calls:** 4 (2x search-rounds med 4 parallelle kall, 2x fetch)'. Last line of the file; single trailing newline verified after the edit.\nTHE AMBIGUITY THIS ENTRY WAS BOOKED FOR DID NOT HAVE TO BE RESOLVED, AND THAT IS THE POINT. The entry says the line 'cannot be adjudicated without deciding whether the field counts calls or rounds' - read as rounds, 2 + 2 = 4 and it is consistent; read as calls, 2 rounds of 4 parallel calls plus 2 fetches is 10 and the stated 4 is wrong. Both readings are about whether the NUMBER IS CORRECT. Under a form that deletes rather than corrects, correctness is not in the option space: the line goes because it is unverifiable, and it is unverifiable under BOTH readings, since no generation log exists to adjudicate either. So open question #15 is MOOT FOR THE DELETION and stays live only for anything that would need the number's value - and nothing does, now that the line is gone. This is the same shape as the fact that closed 26j: an ABSENCE settling a choice that neither branch could settle.\nWHY THIS WAS NOT A NEW FORM DECISION, CHECKED RATHER THAN ASSERTED: idx-26k carries an explicit close-blocking clause ('Do not close this one in isolation'), and idx-26r carries none. The 2026-08-09 scope addendum to idx-26j states the ratified ground is unverifiability, 'a property that holds for ALL 23 lines' - which includes this one. STATE's warning that this file 'is not mechanical' carried forward the framing of the entry text, which was written at 088cf06 (14:11), ten minutes BEFORE the addendum (da16608, 14:21) that dissolved it. The entry's framing outlived the addendum that answered it.\nKEPT AND VERIFIED BY COUNTING: '**Total sources cited:** 9 primærkilder fra MCP-research' is TRUE - 9 numbered entries, 9 distinct URLs, all on learn.microsoft.com, so the provenance qualifier holds here as well (contrast idx-26o, where it did not).\nANCHOR UNIQUENESS verified with grep -cF before writing, not with the gate's text.includes - the gate proves PRESENCE, never uniqueness, and 26j named the omission of this check as an explicit lapse."
    },
    {
      "id": "idx-26s",
      "file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
      "class": "replacement",
      "status": "open",
      "raised": "2026-08-09",
      "summary": "Surfaced while closing idx-26j in this file, measured rather than inferred, and deliberately NOT repaired in that edit - the eleventh instance of the 'defect sits NEXT TO the edit' pattern. The Kilder section splits its 17 sources into two labelled blocks, '**Verified sources (MCP: microsoft-learn):**' (line 719, entries 1-12) and '**Baseline sources (model knowledge + MCP-inferred):**' (line 770, entries 13-17). Two entries contradict the block they sit in, and they contradict it in OPPOSITE directions. Source 7, 'Microsoft Responsible AI Standard v2', sits under Verified but carries '(Status: Baseline - Impact Assessment framework, June 2022)'. Source 17, 'Developing Responsible Generative AI Applications (Windows)', sits under Baseline but carries '(Status: Verified 2026-02 - Model Cards reference, red teaming, governance processes)'. WHY IT WAS NOT FIXED IN THE SAME EDIT: the fix is a replacement whose direction is undecided. Either the block membership is authoritative and the two per-source Status labels are wrong, or the per-source labels are authoritative and the two entries are filed in the wrong block - and resolving it the second way means moving entries, which renumbers the list and touches every claim that counts it. Neither direction is derivable from the file. Note also that the per-source Status labels do not form a complete second vocabulary to adjudicate against: only 14 of the 17 sources carry a Status line at all (13, 14 and 16 have none, and 15 reads '(Status: Adopted 2024 - ...)', which is neither Verified nor Baseline), so a rule of 'trust the per-source label' has no value to read for three of them. WHAT IS ALREADY SAFE: idx-26j's footer replacement was written to survive this entry either way rather than to assert over it. It counts BLOCK MEMBERSHIP only ('17 kilder - 12 oppfoert under Verified sources, 5 under Baseline sources') and makes no claim about any individual source's status. The count is invariant under both resolutions: by block membership it is 12/5, and swapping both mislabelled entries gives verified {1-6, 8-12, 17} = 12 and baseline {7, 13, 14, 15, 16} = 5. An earlier draft of that line read '12 av 17 kilder verifisert via MCP (nr. 1-12)', which WOULD have asserted source 7 is MCP-verified and would have authored this defect into the fix; it was caught and rewritten before commit.",
      "evidence": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md lines 719, 747, 750, 770, 790; idx-26j resolution; docs/r11-pilot-results.md",
      "anchors": [
        "7. **Microsoft Responsible AI Standard v2**",
        "(Status: Baseline — Impact Assessment framework, June 2022)",
        "17. **Developing Responsible Generative AI Applications (Windows)**"
      ]
    },
    {
      "id": "idx-26t",
      "file": "skills/ms-ai-engineering/references/agent-orchestration/agent-to-agent-a2a-protocol.md",
      "class": "replacement",
      "status": "open",
      "raised": "2026-08-09",
      "summary": "Booked while closing idx-26n, from the check the ratified form requires on what REMAINS in a footer after the MCP-calls line is deleted - the defect sits next to the edit, now for the twelfth time. '**Total sources cited:** 10 unike URLer fra MCP-research + tavily-research' states both a source count and a URL count in one line, and they differ. MEASURED, not inferred: the Kilder section carries 10 numbered entries but 11 distinct URLs, because entry 8 (A2A Protocol Specification) lists two - https://a2a-protocol.org/latest/specification/ and https://a2a-protocol.org/latest/announcing-1.0/. So the line is TRUE read as 'sources cited' and FALSE read as 'unike URLer', and it says both. This is the undefined-referent defect the whole footer class is about, surviving INSIDE the line the ratified form told us to keep and verify - the form presumed kept counts would pass and does not say what to do when one fails. DIRECTION MATTERS AND WAS CHECKED: stated 10 < actual 11 runs the same way as all eight MCP-calls inconsistencies measured corpus-wide, with zero running the other way. DO NOT REPAIR BY PICKING A NUMBER: 10 and 11 are each correct under one reading, so choosing is a referent decision, not arithmetic - the same decision the operator took for the MCP-calls line, and it has not been taken for this field. Two candidate forms, neither ratified: drop the URL wording so the field counts sources only, or keep URLs and restate as 11. Raised as an open operator question in STATE.",
      "evidence": "footer of this file (last line after the idx-26n deletion); Kilder section entries 1-10, entry 8 carrying two URLs; idx-26n resolution; idx-26j scope addendum 2026-08-09",
      "anchors": [
        "**Total sources cited:** 10 unike URLer fra MCP-research + tavily-research"
      ]
    },
    {
      "id": "idx-26u",
      "file": "skills/ms-ai-security/references/cost-optimization/azure-cost-management-ai.md",
      "class": "replacement",
      "status": "open",
      "raised": "2026-08-09",
      "summary": "Booked while closing idx-26q. '**File size:** ~14 KB' is FALSE, and - unlike the MCP-calls line deleted in the same footer - it is FALSIFIABLE rather than merely unverifiable, because git is an artifact that adjudicates it. MEASURED at every commit that has ever touched this file: baa2d02 2026-04-08 = 17388 bytes (16.9 KB), 781d98f 2026-05-03 = 17388, 41b390b 2026-06-19 = 17963, 03d596e 2026-06-23 = 17965, ddce43d 2026-07-04 = 18554 bytes (18.1 KB), and the working tree today is 18554. The line is present verbatim in the EARLIEST of those versions, so the claim was already wrong when the file first entered the repo and has never been true at any point the repo can observe. It therefore cannot be defended as a stale-but-once-true generation-time fact, which is the defence available to the MCP-calls numbers. NOT REPAIRED HERE because the choice is a form decision: delete it as the same category as the call count, or restate it as a current measurement that every future edit invalidates - a field that is wrong again the moment anyone touches the file. ONE STEP WORTH STATING FOR WHOEVER ADJUDICATES: under the referent ratified on idx-26j - current provenance, one referent for the whole footer block - a generation-time file size is the same category as a generation-time call count, so deletion follows from an existing ratification rather than requiring a new one. Raised as an open operator question in STATE.",
      "evidence": "footer of this file; git size history baa2d02..ddce43d; git show baa2d02:<file> showing the line present at 17388 bytes; idx-26j ratified form + 2026-08-09 scope addendum",
      "anchors": [
        "**File size:** ~14 KB"
      ]
    },
    {
      "id": "idx-26v",
      "file": "skills/ms-ai-security/references/cost-optimization/azure-cost-management-ai.md",
      "class": "replacement",
      "status": "open",
      "raised": "2026-08-09",
      "summary": "Booked while closing idx-26q. '**Verification status:** 80% Microsoft-verified, 20% domain-specific (Norwegian public sector)' is the idx-26j locator-4 class: an uncheckable percentage with no stated denominator. 26j closed its own instance IN THE SAME EDIT, on the reasoning that splitting a block with one undefined referent repeats the bundling error idx-26g caught - so departing from that precedent here needs a reason, and the reason was MEASURED BEFORE IT WAS DECIDED rather than asserted. 26j could replace its percentage with a structural count because that file HAD a partition to count: 12 sources under 'Verified sources', 5 under 'Baseline sources'. THIS FILE HAS NO SUCH PARTITION. All 8 rows of the 'Microsoft Learn-ressurser (MCP-verified)' table are marked Verified, and the 'Konfidensgradering per seksjon' table splits 3 Verified / 3 non-Verified (Baseline + Domain Expertise, Domain Expertise, Baseline + Best Practices), which is 50/50 - not 80/20 under any reading, and measured over sections rather than sources in any case. The percentage maps onto nothing structural in the file. Re-expressing it would require INVENTING a denominator, which is exactly 'the replacement authors the defect class it closes' - the error caught in 26j's own draft before commit, where the first wording would have asserted that source 7 was MCP-verified. Booked rather than repaired, following idx-26s. Candidate resolutions, neither ratified: delete as unverifiable under the ratified footer form, or replace with the section-level count 3 of 6 - which is a different claim from the one the line makes, since it measures sections and the line reads as coverage. Raised as an open operator question in STATE.",
      "evidence": "footer of this file; the 8-row Microsoft Learn URL table (all Verified); the 6-row Konfidensgradering per seksjon table (3 Verified / 3 non-Verified); idx-26j locator 4 and its pre-commit correction; idx-26s (book-rather-than-repair precedent)",
      "anchors": [
        "**Verification status:** 80% Microsoft-verified, 20% domain-specific (Norwegian public sector)"
      ]
    },
    {
      "id": "idx-26w",
      "file": "skills/ms-ai-engineering/references/agent-orchestration/agent-to-agent-communication.md",
      "class": "replacement",
      "status": "open",
      "raised": "2026-08-09",
      "summary": "Booked while closing idx-26o, from the same what-remains check that produced idx-26t. '**Total sources cited**: 7 unique URLs fra MCP-research' passes as ARITHMETIC and fails as PROVENANCE - measured, not inferred. The count is right: 7 numbered entries, 7 distinct URLs. But only 5 of those URLs are on learn.microsoft.com; source 6 is https://a2a-protocol.org/latest/specification/ and source 7 is https://www.jsonrpc.org/specification. The microsoft-learn MCP server serves learn.microsoft.com and nothing else, so 2 of the 7 cannot have come from MCP research, and the qualifier 'fra MCP-research' overclaims for them. This is the counting class's provenance sibling: the defect is not in the number but in what the number is asserted to be a count OF. The contrast inside the same batch makes the shape visible - idx-26n's line on the neighbouring file names 'MCP-research + tavily-research' and so does cover its non-Learn sources, while this one names MCP alone and does not. NOT REPAIRED: the ratified footer form governs counts and their referent, and it has never been extended to provenance qualifiers - doing so unasked would widen a form that stands in 21 files. Candidate resolutions, neither ratified: name the actual provenance mix, or drop the provenance qualifier and let the line be a pure count. Raised as an open operator question in STATE.",
      "evidence": "footer of this file (last line after the idx-26o deletion); Kilder section sources 1-7, of which 6 (a2a-protocol.org) and 7 (jsonrpc.org) are not learn.microsoft.com; idx-26o resolution; idx-26t (sibling finding, same batch)",
      "anchors": [
        "**Total sources cited**: 7 unique URLs fra MCP-research"
      ]
    }
  ]
}