|
|
|
|
@ -261,85 +261,92 @@
|
|
|
|
|
"id": "idx-26l",
|
|
|
|
|
"file": "skills/ms-ai-engineering/references/mlops-genaiops/feedback-loops-continuous-improvement.md",
|
|
|
|
|
"class": "replacement",
|
|
|
|
|
"status": "open",
|
|
|
|
|
"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": "open",
|
|
|
|
|
"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": "open",
|
|
|
|
|
"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": "open",
|
|
|
|
|
"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": "open",
|
|
|
|
|
"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": "open",
|
|
|
|
|
"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": "open",
|
|
|
|
|
"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",
|
|
|
|
|
@ -354,6 +361,54 @@
|
|
|
|
|
"(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"
|
|
|
|
|
]
|
|
|
|
|
}
|
|
|
|
|
]
|
|
|
|
|
}
|
|
|
|
|
|
