open/ms-ai-architect
1
0
Fork 0
Code Issues Releases 1 Activity

feat(ms-ai-architect): #31 ratifisert — kanalen adjudiserer, og entryens eget utsettelses-premiss var usant [skip-docs]

Browse source 
idx-26s anvendt: nr. 7 og nr. 17 flyttet mellom kildeblokkene i
transparency-documentation-standards.md, lista renummerert.

ENTRYEN VAR UTSATT PAA TO PREMISSER. BEGGE MAALT USANNE.

(1) «Neither direction is derivable from the file.» Verified-blokka definerer
seg KANAL-spesifikt («MCP: microsoft-learn»), og kanalen er lesbar per kilde
fra URL-en. 11 av 12 Verified-kilder er learn.microsoft.com — eneste unntak er
nr. 7 (blogs.microsoft.com, PDF fra juni 2022). 0 av 5 Baseline-kilder er
learn.microsoft.com — eneste unntak er nr. 17 (learn.microsoft.com). Kanal-
avvikene ER status-avvikene. Merkene stemmer med kanalen i begge tilfeller;
plasseringen er gal i begge. Motsatt retning ville forfattet to USANNE
paastander: at en blogs.microsoft.com-PDF er hentet via MCP microsoft-learn,
og at en learn.microsoft.com-side er ren modellkunnskap.

(2) «Moving entries renumbers the list and touches every claim that counts it.»
Maalt usant. INGENTING refererer en kilde ved nummer — verken i fila eller
korpus-bredt. De to eneste tellende paastandene (:792 «17 URLs», :793 «12
oppfoert under Verified sources, 5 under Baseline sources») teller BLOKK-
MEDLEMSKAP og er invariante under det symmetriske byttet. idx-26j skrev den
footeren bevisst slik at den skulle overleve denne entryen uansett utfall; den
framsyntheten er grunnen til at editen kostet null nedstroems.

KLASSEN ER MAALT FOER SPOERSMAALET BLE STILT (#29/#30-disiplinen): 389 ref-filer,
31 kandidatfiler med baade verified- og baseline-blokk, BEGGE markoer-dialekter
(«(Status: X …)» og bar/kursiv «(X …)»), stramme blokkgrenser. 3 konflikter i 2
filer. Én haandverifisert som FALSK POSITIV og eksplisitt utenfor formen:
language-services-question-answering.md:646 leser «(verifisert via Microsoft
Trust Center)» — en ANNEN kanal enn den fila's Verified-blokk er definert av.
Klassen er 1 fil / 2 instanser.

ET NETT SOM FEILET FOERST, ført i formen fordi feilen er den gjenbrukbare
delen: foerste klassifiserer leste proveniens-ord HVOR SOM HELST i overskriften
og ga MIX for «Baseline sources (model knowledge + MCP-inferred)», som baerer
BAADE «Baseline» og «MCP». Fila med det KJENTE tilfellet ble dermed stille
filtrert bort, og sveipet rapporterte 0 konflikter over 27 filer. Ledende-token-
presedens rettet det; kandidatmengden vokste til 31. Et nett som ikke kan
reprodusere sitt eget kjente tilfelle maaler ingenting — og «0 funnet» fra et
slikt nett leser som «klassen er lukket».

VERIFISERT ETTER EDIT, ikke paastaatt: nummerering sammenhengende 1..17;
blokk-telling 12/5; begge tellende paastander lest om og fortsatt sanne;
URL-mengden byte-identisk med HEAD (ingen tapt, ingen lagt til); filen fortsatt
797 linjer; hver Verified-kilde na learn.microsoft.com, hver Baseline-kilde
ikke; korpus-sveipet kjoert om og nede paa det ene falske positive.
Alle 11 formers GOVERNS-pekere oppløser mot eksisterende, resolvede entries.

FOERSTE AV SIN OPERASJON: ingen tidligere entry har FLYTTET innhold mellom
blokker — presedensen er sletting og in-place-erstatning.

Koe: 57 entries (8 aapne, 49 resolved). Suite 1052/1052.

[skip-docs]: ingen doc-impact — ref-docs uendret paa 389, ingen fil lagt til
eller fjernet.
This commit is contained in:
Kjell Tore Guttormsen 2026-08-12 22:48:00 +02:00
commit b290022c59
2 changed files with 19 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

8
scripts/kb-eval/data/g7-review-queue.json
View file

@ -17,7 +17,8 @@
"#27": "A REFERENT WORD THE FIELD NAME ALREADY CARRIES. Ratified 2026-08-12.\nTHE FORM: where a count line names a referent in its VALUE that contradicts the count, while the FIELD NAME already states the correct referent, delete the contiguous referent words from the value and leave the rest byte-identical. The count is untouched.\nTHE INSTANCE, agent-to-agent-a2a-protocol.md:732. \"**Total sources cited:** 10 unike URLer fra MCP-research + tavily-research\" -> \"**Total sources cited:** 10 fra MCP-research + tavily-research\". Deleted: \" unike URLer\", 12 contiguous characters. The three #25 conditions all hold and were measured, not assumed: the remainder is grammatical; 10 is grounded in the 10 numbered entries the file lists; zero words are authored.\nWHY IT IS NOT #25, which is the reason this needed its own ratification rather than inheritance: #25 removes a DELETE-CLASS count restated in-line. Nothing removed here is a count at all, and nothing in the line has the generation as its referent. The conditions transfer; the scope does not.\nWHY IT IS NOT #21, and this is where the session that arrived here was wrong on a premise rather than on a judgement. STATE asserted this line was word-for-word idx-26w and therefore already governed. MEASURED FALSE: idx-26w reads \"fra MCP-research\" alone, this line reads \"fra MCP-research + tavily-research\". #21 fires only on an OVERCLAIMING provenance qualifier, and this qualifier does not overclaim - it names the web-research leg covering exactly the four non-Learn URLs (a2a-protocol.org x2, linuxfoundation.org, developers.googleblog.com). idx-26w own summary had already said so in writing. The provenance is sound here; the defect is the referent of the count.\nTHE MEASUREMENT THAT MADE IT A DELETION: 10 numbered source entries, 11 distinct URLs, because entry 8 carries two. So \"10\" is true as sources and false as unique URLs, and the line asserted both. Correcting 10 to 11 was available and was NOT taken - deletion of the wrong referent costs nothing, because the field name \"Total sources cited\" already says which one is meant.\nGOVERNS: idx-26t.",
"#28": "A KEEP-CLASS COUNT WHOSE TRUE HALF IS BOTH TRUE AND UNIQUE. Ratified 2026-08-12. This is the residual case #23 explicitly declined to ratify and sent back as a new question; this is its first instance, and it is decided rather than inherited.\nTHE FORM: where a keep-class line carries several counts, some measured FALSE and at least one measured TRUE, and that true part is NOT restated anywhere else in the file, CORRECT the false numbers to their measured values. Do not delete the line.\nTHIS IS THE PROGRAMME FIRST AUTHORED NUMBER, and the operator decided it deliberately on 2026-08-12. Until now every resolution deleted, on the idx-26v ground that a repair must not author the defect class it closes. That ground still holds where deletion is FREE - which is why idx-26t, decided in the same session, deletes. It stops holding where deletion destroys a true and unique claim, because then silence is not the cheap option, it is a second defect.\nTHE INSTANCE, rag-document-preprocessing.md:791 (the entry evidence and STATE both said :792 - off by one; the anchor is verbatim text, so nothing depended on it). \"8 Microsoft Learn-artikler + 4 GitHub-repos = **12 kilder**\" -> \"8 Microsoft Learn-artikler + 2 GitHub-repos = **10 kilder**\".\nMEASURED, and the population was re-checked after the edit rather than assumed: 8 distinct learn.microsoft.com articles after /en-us normalisation (TRUE as written), 2 distinct github.com URLs (NOT 4), therefore 10 named source URLs (NOT 12). The three azure.microsoft.com pricing URLs are excluded because the line states its own referent - Learn articles plus GitHub repos - and never claimed to cover them.\nTHE POPULATION CHECK THAT COULD HAVE INVALIDATED THIS: the file does not end at the footer - a further section runs :795-803 - so the footer might have been a section total measured over the wrong span. Measured: ZERO Learn or GitHub URLs occur after :791. All 11 occurrences precede it. The count covers what it claims.\nTHE LIMIT: this form applies only where the true part is BOTH true AND unique. Where the true part is restated elsewhere, deletion remains free and #23 governs. Where every part is false, #24 governs. A keep-class count that is merely unverifiable, rather than measurably wrong, is not reached by this form at all - that is still the idx-26j class.\nGOVERNS: idx-26at.",
"#29": "A FILE-PROPERTY FIELD THAT NO EDIT CAN KEEP TRUE. Ratified 2026-08-12.\nSCOPE FIRST, and the scope was MEASURED BEFORE THE QUESTION WAS PUT rather than after - the discipline idx-26j's scope addendum named after booking stopped at 7 of 21. Only idx-26u was booked, but \"**File size:**\" occurs in THREE files corpus-wide, and the operator ratified the form over all three in one decision instead of over the one that happened to be on the queue.\nTHE FORM: where a footer or metadata field states a physical property of the file itself - its byte size - DELETE THE LINE. Nothing is authored and nothing is renamed.\nTHE GROUND, and it is NOT #22's ground. #22 deletes because nothing can adjudicate the claim; git adjudicates this one exactly, which is why the form needed its own ratification and why idx-26u's own inheritance argument (\"deletion follows from idx-26j rather than requiring a new ratification\") was NOT accepted - the same premise type this programme falsified twice on 2026-08-12. Three grounds, each measured:\n (1) EVERY PART IS FALSE, so there is no true half to preserve. #28 sends this case onward in its own words: \"Where every part is false, #24 governs.\"\n (2) DELETION COSTS NO TRUE INFORMATION. A byte size has no use in a knowledge-base reference file and is trivially measurable by anyone who wants it. STATE's rule - delete where deletion is free, correct where deletion costs true and unique information - lands on delete.\n (3) THE ONLY AVAILABLE REPAIR IS SELF-INVALIDATING. Restating \"~18 KB\" writes a line that the very next edit to the file makes false again. That is not a repair; it is authoring a future instance of the defect class being closed - the idx-26v hazard in a new costume.\nMEASURED, all three, against the working tree: azure-cost-management-ai.md:295 claimed ~14 KB against 18499 bytes (18.0 KB, 29% off); budget-forecasting-ai-projects.md:530 claimed ~14 KB against 20001 bytes (19.5 KB, 39% off); agent-evaluation-testing-frameworks.md:565 claimed ~29 KB against 27864 bytes (27.2 KB, 6.6% off - defensible under the tilde, and deleted anyway BECAUSE THE GROUND IS THE FIELD TYPE, NOT THE SIZE OF THE ERROR). idx-26u's git history is the strongest form of ground (1): the line read ~14 KB in the EARLIEST version the repo can observe (baa2d02, 17388 bytes) and at every commit since, so it was never true at any observable point.\nONE CORRECTION TO idx-26u's OWN EVIDENCE, made before the form was applied: the entry recorded \"the working tree today is 18554\". It is 18499 - commit 30d4340 touched the file after the entry was written. The conclusion is unchanged; the number was re-measured rather than carried forward.\nEXPLICITLY NOT COVERED, booked rather than swept: \"- **Word count:** ~3200 ord\" at agent-evaluation-testing-frameworks.md:564 sits DIRECTLY ABOVE one of the deleted lines and is arguably the same self-invalidating class (measured: ~3200 against 3374 actual, 5.2% off). It was NOT in the ratification question, so extending this form to it would be the silent widening #22 refused and #26 refused after it. Booked as idx-26aw, open. It is the only word-count field in the corpus.\nTHE SURVIVING KEEP-CLASS NEIGHBOURS WERE MEASURED, NOT ASSUMED, since a deletion that leaves a false line behind is the residue class G7 exists for. All three are TRUE under the /en-us/ normalisation #28 established: \"**Total sources:** 8 unique Microsoft Learn URLs\" (8 distinct articles, 9 raw strings - the header **Source:** at :7 repeats tutorial-acm-create-budgets without the locale), \"**Unique sources:** 8 Microsoft Learn URLs\" (8 of 9), \"- **Unique sources:** 10 Microsoft Learn URLs\" (10 of 11). Nothing was booked against them.\nTHE LABEL \"**Document metadata:**\" IS KEPT UNCHANGED, per #22's label rule: its words name content, not the generation, so it is the \"Research Coverage\" case rather than the \"MCP Calls\" case. It still labels two surviving lines.\nGOVERNS: idx-26u, idx-26au, idx-26av.",
"#30": "A MEASURABLE FILE PROPERTY THAT NO MECHANISM MAINTAINS. Ratified 2026-08-13. This is the widening of #29's ground that #29 itself refused to take silently, and it was put as its own question.\nTHE FORM: where a footer or metadata field states a MEASURABLE PROPERTY OF THE FILE ITSELF - its byte size, its word count - and no mechanism in this repository keeps that value true, DELETE THE LINE. Nothing is authored and nothing is renamed. #29 is the byte-size instance of this form; #30 is the ground stated at the width the evidence supports.\nTHE BOUNDARY, MEASURED BEFORE THE QUESTION WAS PUT, because the widest reading of \"self-invalidating\" is far larger than the class and would have swept the corpus. \"**Last updated:**\" occurs in 385 files and a later edit falsifies it exactly as it falsifies a word count - it is NOT reached by this form, on two measured grounds: it is contract-mandated (buildHeader emits it; validateKbFile requires it) and it is actively re-stamped by /architect:kb-update on every refresh (commands/kb-update.md:24, :192). It has a maintaining mechanism; a word count and a byte size have none. \"**Document version:** 1.0\" is likewise outside: a version string is a process assertion, not a property measurable against the file. ONE CANDIDATE BOUNDARY WAS TESTED AND DISCARDED rather than carried: backfill-last-updated.mjs was first taken to be the maintaining mechanism, and is not - it is a ONE-FILE backfill (decision-trees.md). The boundary rests on the header contract and the refresh path instead.\nTHE CLASS WAS MEASURED WITH THREE INDEPENDENT NETS, not with the one word the entry happened to use: (1) named variants (\"**Word count\", \"**Ordtelling\", \"**Antall ord\", \"**Words\", \"**Ordantall\", \"**Lengde\"); (2) case-insensitive \"word count\"; (3) a full enumeration of EVERY bold-label field carrying a numeric value across all 394 skills/**/*.md, grouped by label. The third net is the one that can see a field whose name nobody guessed: it returned no line count, no character count, no page count, no section count, no reading time. The class is ONE under every net.\nTHE INSTANCE, agent-evaluation-testing-frameworks.md:564: \"- **Word count:** ~3200 ord\" against a measured 3369 words (5.3% off). All three of #29's grounds hold here: (1) no part is true, so #28 sends the case onward in its own words; (2) deletion costs no true information - a word count has no use in a knowledge-base reference file and wc -w answers it in a second; (3) the only available repair is self-invalidating.\nGROUND (3) IS NO LONGER AN ARGUMENT, IT IS AN OBSERVATION, and that is what this ratification adds to #29. The entry and STATE both recorded wc -w = 3374. It is 3369. The five-word difference is the \"- **File size:** ~29 KB\" line that #29 DELETED FROM THIS SAME FILE the previous session (35ac933). The programme falsified its own freshly-measured word count inside one day, by doing the very work the form governs. A corrected \"~3370\" would have been false again at the next edit - authoring a future instance of the defect class being closed, the idx-26v hazard #29 named.\nWHAT WAS RE-MEASURED RATHER THAN INHERITED, since a deletion that leaves a false line behind is the residue class G7 exists for: \"- **Unique sources:** 10 Microsoft Learn URLs\" is TRUE - 10 distinct learn.microsoft.com URLs after /en-us normalisation (11 raw occurrences; one repeat). THE LABEL \"**Document metadata:**\" IS KEPT UNCHANGED per #22's label rule, and #22's PROMOTE CLAUSE DOES NOT FIRE: it is conditioned on the label itself being deleted, and this label is keep-class. It now heads a single surviving line, which no ratified form treats as a defect.\nGOVERNS: idx-26aw."
"#30": "A MEASURABLE FILE PROPERTY THAT NO MECHANISM MAINTAINS. Ratified 2026-08-13. This is the widening of #29's ground that #29 itself refused to take silently, and it was put as its own question.\nTHE FORM: where a footer or metadata field states a MEASURABLE PROPERTY OF THE FILE ITSELF - its byte size, its word count - and no mechanism in this repository keeps that value true, DELETE THE LINE. Nothing is authored and nothing is renamed. #29 is the byte-size instance of this form; #30 is the ground stated at the width the evidence supports.\nTHE BOUNDARY, MEASURED BEFORE THE QUESTION WAS PUT, because the widest reading of \"self-invalidating\" is far larger than the class and would have swept the corpus. \"**Last updated:**\" occurs in 385 files and a later edit falsifies it exactly as it falsifies a word count - it is NOT reached by this form, on two measured grounds: it is contract-mandated (buildHeader emits it; validateKbFile requires it) and it is actively re-stamped by /architect:kb-update on every refresh (commands/kb-update.md:24, :192). It has a maintaining mechanism; a word count and a byte size have none. \"**Document version:** 1.0\" is likewise outside: a version string is a process assertion, not a property measurable against the file. ONE CANDIDATE BOUNDARY WAS TESTED AND DISCARDED rather than carried: backfill-last-updated.mjs was first taken to be the maintaining mechanism, and is not - it is a ONE-FILE backfill (decision-trees.md). The boundary rests on the header contract and the refresh path instead.\nTHE CLASS WAS MEASURED WITH THREE INDEPENDENT NETS, not with the one word the entry happened to use: (1) named variants (\"**Word count\", \"**Ordtelling\", \"**Antall ord\", \"**Words\", \"**Ordantall\", \"**Lengde\"); (2) case-insensitive \"word count\"; (3) a full enumeration of EVERY bold-label field carrying a numeric value across all 394 skills/**/*.md, grouped by label. The third net is the one that can see a field whose name nobody guessed: it returned no line count, no character count, no page count, no section count, no reading time. The class is ONE under every net.\nTHE INSTANCE, agent-evaluation-testing-frameworks.md:564: \"- **Word count:** ~3200 ord\" against a measured 3369 words (5.3% off). All three of #29's grounds hold here: (1) no part is true, so #28 sends the case onward in its own words; (2) deletion costs no true information - a word count has no use in a knowledge-base reference file and wc -w answers it in a second; (3) the only available repair is self-invalidating.\nGROUND (3) IS NO LONGER AN ARGUMENT, IT IS AN OBSERVATION, and that is what this ratification adds to #29. The entry and STATE both recorded wc -w = 3374. It is 3369. The five-word difference is the \"- **File size:** ~29 KB\" line that #29 DELETED FROM THIS SAME FILE the previous session (35ac933). The programme falsified its own freshly-measured word count inside one day, by doing the very work the form governs. A corrected \"~3370\" would have been false again at the next edit - authoring a future instance of the defect class being closed, the idx-26v hazard #29 named.\nWHAT WAS RE-MEASURED RATHER THAN INHERITED, since a deletion that leaves a false line behind is the residue class G7 exists for: \"- **Unique sources:** 10 Microsoft Learn URLs\" is TRUE - 10 distinct learn.microsoft.com URLs after /en-us normalisation (11 raw occurrences; one repeat). THE LABEL \"**Document metadata:**\" IS KEPT UNCHANGED per #22's label rule, and #22's PROMOTE CLAUSE DOES NOT FIRE: it is conditioned on the label itself being deleted, and this label is keep-class. It now heads a single surviving line, which no ratified form treats as a defect.\nGOVERNS: idx-26aw.",
"#31": "A CHANNEL-DEFINED SOURCE BLOCK: THE CHANNEL ADJUDICATES, NOT THE PLACEMENT. Ratified 2026-08-13.\nTHE FORM: where a source list is partitioned into blocks whose OWN HEADER names the verification channel (\"Verified sources (MCP: microsoft-learn)\"), and a source's block membership conflicts with its per-source status label, the source's ACTUAL channel decides - read from its URL and compared against the channel the block header names. MOVE the source into the block its channel puts it in. Do NOT rewrite the label to match the placement.\nTHE GROUND, and it is not a preference between two defensible readings. idx-26s was deferred on the stated premise that \"neither direction is derivable from the file\". That premise was FALSIFIED by a measurement the entry never ran: the block header names a channel, and the channel is readable per source. In transparency-documentation-standards.md, 11 of the 12 Verified-block sources are learn.microsoft.com and the single exception is nr. 7 (blogs.microsoft.com, a June 2022 PDF); 0 of the 5 Baseline-block sources are learn.microsoft.com and the single exception is nr. 17 (learn.microsoft.com). The two channel outliers are EXACTLY the two status outliers. The labels agree with the channel in both cases; the placement disagrees in both. The opposite direction - rewriting the two labels to match their blocks - would AUTHOR two false claims: that a blogs.microsoft.com PDF was fetched via MCP microsoft-learn, and that a learn.microsoft.com page is mere model knowledge.\nTHE BOUNDARY, MEASURED BEFORE THE QUESTION WAS PUT. The form reaches ONLY blocks whose own header names the channel. 389 reference files swept; 31 carry both a verified-kind and a baseline-kind source block; both per-source marker dialects were run - \"(Status: X ...)\" and the bare/italic \"(X ...)\" - with block bounds tightened to the contiguous list. Exactly 3 conflicts surfaced across 2 files. One was HAND-VERIFIED AS A FALSE POSITIVE and is explicitly outside the form: language-services-question-answering.md:646 reads \"(verifisert via Microsoft Trust Center)\" under \"**Baseline (modellkunnskap):**\", naming a channel OTHER than the one that file's Verified block is defined by (\"**Verified (fra MCP microsoft-learn):**\"). Model knowledge cross-checked against a non-MCP source belongs in Baseline exactly where it sits; the word \"verifisert\" collides lexically, not semantically. THE CLASS IS THEREFORE 1 FILE / 2 INSTANCES.\nTHE INCOMPLETE LABEL VOCABULARY DOES NOT BLOCK THE FORM, and this had to be measured because the entry raised it as an obstacle. Only 14 of the 17 sources carry \"(Status: ...)\" at all - 13, 14 and 16 carry none, and 15 reads \"(Status: Adopted 2024 ...)\", outside the {Verified, Baseline} vocabulary. All four unadjudicable sources sit in the Baseline block and all four are non-learn.microsoft.com, so the channel decides precisely where the label is silent. A rule cannot be authoritative where it says nothing; the channel is not silent anywhere.\nA NET THAT FAILED FIRST, recorded because the failure is the reusable part. The first classifier read provenance tokens ANYWHERE in the header and returned MIX for \"Baseline sources (model knowledge + MCP-inferred)\", which carries BOTH \"Baseline\" and \"MCP\" - so the one file holding the known instance was silently filtered out and the sweep reported 0 conflicts over 27 candidate files. Leading-token precedence fixed it and the candidate set grew to 31. A net that cannot reproduce its own known instance is measuring nothing, and \"0 found\" from such a net reads as \"class closed\".\nGOVERNS: idx-26s."
}
},
"entries": [
@ -365,7 +366,7 @@
"id": "idx-26s",
"file": "skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md",
"class": "replacement",
"status": "open",
"status": "resolved",
"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",
@ -373,7 +374,8 @@
"7. **Microsoft Responsible AI Standard v2**",
"(Status: Baseline — Impact Assessment framework, June 2022)",
"17. **Developing Responsible Generative AI Applications (Windows)**"
]
],
"resolution": "Operator-ratified 2026-08-13 as #31, and the ratification REMOVED the choice the entry was deferred for rather than settling it by preference. Both entries MOVED; the list renumbered.\nTHE ENTRY'S OWN DEFERRAL PREMISE WAS FALSIFIED ON TWO COUNTS, both by measurement rather than argument. (1) \"Neither direction is derivable from the file\" - the Verified block header defines itself by CHANNEL (\"MCP: microsoft-learn\"), and the channel is readable per source from its URL. 11/12 Verified-block sources are learn.microsoft.com, the lone exception being nr. 7 (blogs.microsoft.com); 0/5 Baseline-block sources are learn.microsoft.com, the lone exception being nr. 17. The channel outliers ARE the status outliers, so the labels are authoritative and the placements are wrong. (2) \"Moving entries renumbers the list and touches every claim that counts it\" - measured false. NOTHING references a source by number, in this file or anywhere in the corpus. The only two claims that count sources (:792 \"**Unique sources:** 17 URLs\" and :793 \"**Confidence:** 17 kilder - 12 oppfoert under Verified sources, 5 under Baseline sources\") count BLOCK MEMBERSHIP and are invariant under the symmetric swap - which idx-26j's footer was deliberately written to be, and that foresight is what made this edit cost nothing downstream.\nWHAT WAS DONE: nr. 7 (Microsoft Responsible AI Standard v2, blogs.microsoft.com, Status: Baseline) moved to the Baseline block as the new nr. 17; nr. 17 (Developing Responsible Generative AI Applications (Windows), learn.microsoft.com, Status: Verified 2026-02) moved to the Verified block as the new nr. 12. Old 8-12 renumbered to 7-11, with continuation indentation corrected from 4 to 3 spaces where a two-digit number became one-digit.\nVERIFIED AFTER THE EDIT, not asserted: numbering contiguous 1..17; block counts 12/5 unchanged; both counting claims re-read and still true; the URL set byte-identical to HEAD (nothing lost, nothing added); file length unchanged at 797 lines; every Verified-block source now learn.microsoft.com with a Verified label, every Baseline-block source non-learn.microsoft.com; the corpus-wide conflict sweep re-run and down to the single hand-verified false positive.\nFIRST OF ITS OPERATION. No prior entry in this queue MOVED content between blocks - the applied precedent is deletion and in-place replacement. The operation was defined here, and its cost was measured before it was defined rather than after."
},
{
"id": "idx-26t",

28
skills/ms-ai-governance/references/responsible-ai/transparency-documentation-standards.md
View file

@ -742,31 +742,31 @@ Return on investment: Transparency er billigere enn cleanup. Skal vi prioritere
https://learn.microsoft.com/en-us/azure/machine-learning/concept-responsible-ai
(Status: Verified 2026-02 — Six principles: fairness, reliability, privacy, inclusiveness, transparency, accountability)
7. **Microsoft Responsible AI Standard v2**
https://blogs.microsoft.com/wp-content/uploads/prod/sites/5/2022/06/Microsoft-Responsible-AI-Standard-v2-General-Requirements-3.pdf
(Status: Baseline — Impact Assessment framework, June 2022)
8. **ISO/IEC 42001:2023 overview** *(Verified MCP 2026-06-19)*
7. **ISO/IEC 42001:2023 overview** *(Verified MCP 2026-06-19)*
https://learn.microsoft.com/en-us/compliance/regulatory/offering-iso-42001
Microsoft-sertifisering dekker nå: GitHub Copilot, M365 Copilot, Copilot Health, Copilot Studio, Dragon Copilot, Dragon Copilot (Radiologist), Microsoft Foundry og Security Copilot (utvidet fra kun M365 Copilot).
(Status: Verified 2026-06-19 — AI management system standard)
9. **Govern AI (Cloud Adoption Framework)**
8. **Govern AI (Cloud Adoption Framework)**
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/ai/govern
(Status: Verified 2026-02 — AI governance policy examples, documentation requirements)
10. **Establishing responsible AI policies (Cloud Adoption Framework)**
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/responsible-ai-across-organization
(Status: Verified 2026-02 — Cross-functional governance, auditing, transparency mechanisms)
9. **Establishing responsible AI policies (Cloud Adoption Framework)**
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/responsible-ai-across-organization
(Status: Verified 2026-02 — Cross-functional governance, auditing, transparency mechanisms)
11. **Generate Responsible AI insights in the studio UI**
10. **Generate Responsible AI insights in the studio UI**
https://learn.microsoft.com/en-us/azure/machine-learning/how-to-responsible-ai-insights-ui
(Status: Verified 2026-08-09 — Scorecard-konfigurasjon: målverdier, cohort analysis i Data analysis-seksjonen, fritekstbeskrivelse i scorecard summary)
12. **Use Responsible AI scorecard (preview) in Azure Machine Learning**
11. **Use Responsible AI scorecard (preview) in Azure Machine Learning**
https://learn.microsoft.com/en-us/azure/machine-learning/how-to-responsible-ai-scorecard
(Status: Verified 2026-08-09 — De sju scorecard-segmentene; preview uten SLA, ikke anbefalt for production workloads)
12. **Developing Responsible Generative AI Applications (Windows)**
https://learn.microsoft.com/en-us/windows/ai/rai
(Status: Verified 2026-02 — Model Cards reference, red teaming, governance processes)
**Baseline sources (model knowledge + MCP-inferred):**
13. **Model Cards for Model Reporting** (Mitchell et al., 2019)
@ -785,9 +785,9 @@ Return on investment: Transparency er billigere enn cleanup. Skal vi prioritere
https://www.nist.gov/itl/ai-risk-management-framework
(US standard for AI governance)
17. **Developing Responsible Generative AI Applications (Windows)**
https://learn.microsoft.com/en-us/windows/ai/rai
(Status: Verified 2026-02 — Model Cards reference, red teaming, governance processes)
17. **Microsoft Responsible AI Standard v2**
https://blogs.microsoft.com/wp-content/uploads/prod/sites/5/2022/06/Microsoft-Responsible-AI-Standard-v2-General-Requirements-3.pdf
(Status: Baseline — Impact Assessment framework, June 2022)
**Unique sources:** 17 URLs
**Confidence:** 17 kilder — 12 oppført under «Verified sources», 5 under «Baseline sources»