feat(ms-ai-architect): idx-33b-klassen maalt korpus-bredt - 2 bekreftede medlemmer, og det tredje funnet peker motsatt vei [skip-docs]

idx-33b krevde at klassen "under-paastand under verifiseringsstempel" ble
maalt FOER en form foreslaas (#29). Maalingen er kjort; ingen KB-fil er
rort.

NEVNER: 283 "Verified MCP"-stempler / 89 filer. Minus stempler i
kildeseksjon (37) og stempler som ER lenkeoppforinger (20) = 226 stemplede
paastands-passasjer. STATE bar 281/211; 283/246 er hva en ny kjoring maaler,
og 211 lot seg ikke reprodusere fordi nettene som ga tallet laa i en
scratchpad som er borte. 211 er dermed ureproduserbart, ikke galt.

TO ULIKT BLINDE NETT (#33-laerdommen om at ett nett beviser ingenting):
Net E leser PAASTANDS-siden (30 container-ord, 15 preposisjoner, 8 limitere)
-> 47 flagg (20,8 %). Net F leser KILDE-siden (breddemarkorer i kildens
lenketekst/URL som paastanden selv ikke baerer) -> 12 flagg (5,3 %).
Union 56, overlapp 3. Net F FEILET sin egen kjent-positiv-kontroll ved
forste kjoring - 'across' laa i breddelista, og 'across Azure subscriptions'
er en INNSNEVRING, ikke en breddeerklaering. Lista ble delt og kontrollen
kjort paa nytt FOR noe flagg ble lest.

STEGE 1 (offline, bevisbart): 8 produktnavn-kollisjoner ("for Cloud" inne i
"Defender for Cloud"), 6 F-only-passasjer uten skope-uttrykk i det hele
tatt, 16 med container-skope, 26 med limiter uten container.

STEGE 2 (mot levende kilde, 5 av de 16 - haandplukket, IKKE tilfeldig, og
baerer derfor ingen rate): 2 ekte under-paastander, 2 kildetro naer ordrett,
1 defekt av en annen klasse.

TO NYE ENTRIES:
- idx-33c: digital-accessibility-action-plan.md:161 navngir 3 av 5 roller
  modulsida lister (dropper Higher Education Educator og Data Engineer) -
  andre bekreftede medlem av idx-33b-klassen. Maalingen ligger i sin helhet
  i denne entryens summary.
- idx-33d: data-residency-audit-monitoring.md:81 utelater hva flex
  routing-checkboxen GJOR (LLM-inferens ut av EU Data Boundary, paa som
  standard for tenants opprettet etter 2026-03-25). Passasjen leser TRYGGERE
  enn kilden, ikke smalere - egen klasse, derfor egen entry.

De 11 uadjudiserte container-kandidatene og alle 26 limiter-kandidatene er
UMAALT, ikke rene. Ingen form foreslaas; #29 gir den beslutningen til
operatoren. Ko: 62 entries, 6 aapne. check-g7-queue 0 drift. Suite 1052/1052.
This commit is contained in:
Kjell Tore Guttormsen 2026-08-18 21:03:26 +02:00
commit 25b1252b3f

View file

@ -1048,6 +1048,30 @@
"anchors": [
"- Automated detection of AI workloads across Azure subscriptions"
]
},
{
"id": "idx-33c",
"file": "skills/ms-ai-governance/references/norwegian-public-sector-governance/digital-accessibility-action-plan.md",
"class": "replacement",
"status": "open",
"raised": "2026-08-18",
"summary": "Second confirmed member of the under-claim-under-a-verification-stamp class idx-33b named, found by the corpus-wide measurement that entry required. The stamped line reads \"**Microsoft Learn - Use AI tools to create an inclusive learning environment *(Verified MCP 2026-04)*:**\" and the sentence under it scopes the module to three audiences: \"K-12 laerere, bedriftsbrukere og utdanningsinstitusjonell ledelse\". The live module page (learn.microsoft.com/training/modules/use-ai-tools-to-create-inclusive-learning-environment/, microsoft-learn MCP 2026-08-18) lists FIVE roles: K-12 Educator, Business User, Higher Education Educator, Data Engineer, School Leader. The file names 3 of 5 and drops Higher Education Educator and Data Engineer. Same shape as idx-33b: every named audience is TRUE, the enumeration is just narrower than the source it is stamped against. The dropped role matters for this file specifically - it is a Norwegian-public-sector accessibility action plan, and higher education is squarely inside that sector, so the omission removes the reader most likely to be looking. The three learning objectives quoted under the same stamp ARE faithful to the source, so the defect is the audience sentence alone, not the block. NOT repaired here: no form governs this class yet, and #29 says the class is measured before a form is proposed. MEASUREMENT THAT idx-33b ASKED FOR (run 2026-08-18, this repo, no writes to the corpus). Population: \"Verified MCP\" stamps = 283 lines / 89 files. Removing stamps inside a source-list section (37) and stamps that ARE link entries (20) leaves 226 stamped CLAIM passages - the denominator. NOTE the divergence from the number STATE carried: STATE said 281 stamps / 211 in file bodies; 283/246 is what a re-run measures, and the 211 could not be reproduced because the nets that produced it were in a scratchpad that no longer exists. Treat 211 as unreproducible, not as wrong. Two DIFFERENTLY BLIND nets over those 226 (the #33 lesson that one net proves nothing): Net E reads the CLAIM side (bounded-scope vocabulary: 30 container nouns, 15 prepositions, 8 limiters) -> 47 flags (20.8 %). Net F reads the SOURCE side (breadth markers in the cited source's link text/URL that the claim itself does not carry) -> 12 flags (5.3 %). Union 56, overlap 3. Net F FAILED its own known-positive control on the first run (it filtered out stride.md:210 because 'across' sat in its own breadth list, and 'across Azure subscriptions' is a NARROWING, not a breadth declaration); the list was split and the control re-run before any flag was read. Stage-1 adjudication of the union, offline and provable: 8 are product-name collisions (\"for Cloud\" inside \"Defender for Cloud\"), 6 are Net-F-only passages carrying no scope expression at all, 16 carry a container scope where narrowing is even POSSIBLE, 26 carry a limiter without a container. Stage-2 adjudication against live sources covered 5 of the 16 (a hand-picked, NOT random, sample - it is biased upward and cannot carry a rate): 2 are genuine under-claims (stride.md:210 = idx-33b, and this entry), 2 are faithful to their source near-verbatim (data-residency 73/530 vs manage-data-boundary; agent-365 215 vs agent-actions), 1 is a different defect entirely (idx-33d). So the class has 2 CONFIRMED members after the same kind of sweep that found idx-33a's class had 2. The 11 unadjudicated container candidates and all 26 limiter candidates are UNMEASURED, not clean - saying otherwise would be the ansikt-4 error this program exists to avoid.",
"evidence": "microsoft-learn MCP search 2026-08-18 (module page role list: K-12 Educator, Business User, Higher Education Educator, Data Engineer, School Leader); this file 160-161; idx-33b (first member of the class); nets and per-flag data measured 2026-08-18",
"anchors": [
"Modul tilgjengelig for K-12 lærere, bedriftsbrukere og utdanningsinstitusjonell ledelse. Læringsmål:"
]
},
{
"id": "idx-33d",
"file": "skills/ms-ai-governance/references/monitoring-observability/data-residency-audit-monitoring.md",
"class": "replacement",
"status": "open",
"raised": "2026-08-18",
"summary": "Surfaced by the idx-33b class measurement (2026-08-18) and booked separately because it is NOT that class - it points the other way. The stamped line says that for EU environments inside the EU Data Boundary an Azure OpenAI endpoint inside the same boundary is used, that the \"Allow flex routing during periods of peak load\" checkbox is available for EU environments, and that Bing Search data is processed in the USA. Checked against the cited source (power-platform/admin/geographical-availability-copilot, microsoft-learn MCP 2026-08-18): all three statements are TRUE. What the passage omits is what the checkbox DOES - the source states that flex routing \"allows LLM inferencing and the storage of associated pseudonymized data to occur outside the EU Data Boundary during periods of peak demand\", and that \"flex routing is on by default for eligible tenants that were created after March 25, 2026\". The file therefore mentions the control while leaving out the exception it opens, so the passage reads SAFER than its own source rather than narrower - an omitted source-stated exception, not an under-claim. That distinction is the reason this is a separate entry: a form that widens under-claims would not touch this, and a reader of a data-residency file for Norwegian public sector is exactly the reader the omission misleads. NOT repaired here; no form governs it, and the file also carries a separate stamped statement that Microsoft 365 EU Data Boundary is automatic for EU/EFTA sign-up tenants, which a repair must not disturb.",
"evidence": "microsoft-learn MCP search 2026-08-18 (geographical-availability-copilot: flex routing definition, default-on after 2026-03-25; region table Europe -> Azure OpenAI in EUDB, Bing Search United States); copilot-flex-routing; this file 81; raised during the idx-33b class measurement recorded in idx-33c",
"anchors": [
"- **Copilot/generative AI (2026-04):** For EU-miljøer i EU Data Boundary brukes Azure OpenAI-endepunkt innenfor samme boundary. \"Allow flex routing during periods of peak load\"-checkbox tilgjengelig for EU-miljøer. Bing Search-data prosesseres i USA selv ved EU-residency. *(Verified MCP 2026-04)*"
]
}
]
}