Proactive distribution

Executive thesis

Bedömning per 2026-08-23: Dataheart bör inte primärt distribuera dashboards. Det bör distribuera auktoriserade, versionsbundna kunskapsresultat och handlingsförslag som kan renderas i många kanaler utan att affärsbetydelse, säkerhetsbeslut eller evidens tappas.

Den arkitektoniska kärnan är därför:

1. Ett kanalneutralt semantiskt kontrakt.
2. En gemensam fråge- och beslutsmotor.
3. Ett maskinläsbart kontext- och evidenskuvert runt varje resultat.
4. Tunna kanaladaptrar för SQL, API, event, embedded UI, Excel, rapporter, notifieringar och agenter.
5. Ett separat, kontrollerat protokoll för handlingar.

“Samma kunskap överallt” bör betyda ekvivalens i metric_id, semantisk version, dataversion, filter, tidszon, enhet, identitet, policybeslut och evidens — inte pixelidentiska visualiseringar.

Statusmarkeringar nedan:

• Etablerat: brett implementerat och stabila tekniska kontrakt.
• Framväxande: praktiskt användbart men ofullständig interoperabilitet eller drifterfarenhet.
• Hypotes: rimlig riktning som måste verifieras.
• Leverantörspåstående: påstådd kapacitet utan tillräcklig oberoende interoperabilitetsevidens.

State of the art 2024-2026

Etablerat

• Headless analytics har blivit en etablerad arkitektur, där en semantisk frågetjänst skiljs från visualiseringen och exponeras genom flera protokoll. Cube dokumenterar samma semantiska lager via SQL, DAX, REST och GraphQL, med gemensamma säkerhetskontexter. Samma dokumentation visar dock att hierarkier, format och autentiseringsmetoder inte stöds likvärdigt i alla protokoll. Detta är både evidens för mönstret och motbevis mot full kanalparitet. Cube Core Data APIs

• Autentiserad embedded analytics är etablerad praxis. Både Microsoft och självhostade BI-plattformar använder kortlivade embed-/guest-token, originbegränsningar och radbaserad filtrering. Det kritiska är att token skapas server-side och binds till mottagare, resurs och säkerhetskontext. I Power BI påverkar vanliga rolltilldelningar inte RLS/OLS i “app owns data”; den effektiva identiteten måste ingå korrekt i embed-flödet. Microsoft Power BI Embedded security

• Liveanslutna kalkylblad är en viktig distributionsyta. Power BI–Excel kan bevara RLS/OLS och föra över känslighetsetiketter till arbetsboken. Begränsningarna är betydande: externa tenant-användare kan inte använda liveanslutningen, Direct Lake/DirectQuery bevarar inte modellhierarkier, och “app owns data” stöds inte för Analyze in Excel. Microsoft: refreshable Power BI data in Excel

• Eventuella notifieringar måste antas vara minst-en-gång och oordnade. Azure Event Grid dokumenterar dubletter, icke-deterministiska retries och att dead-lettering inte är påslaget som standard. CloudEvents ger ett portabelt eventkuvert och CESQL ger standardiserad filtrering, men löser inte transaktionell leverans eller exakt-en-gång-semantik. CloudEvents, Azure Event Grid delivery

• Tillgänglighet är en kanalövergripande kvalitetsdimension. WCAG 2.2 är en W3C-rekommendation med testbara, teknikneutrala kriterier. EU:s tillgänglighetsakt gäller för avgränsade konsumentprodukter och tjänster efter 28 juni 2025; den gör inte automatiskt alla interna B2B-analysytor lagreglerade, men är en stark design- och upphandlingsbaslinje. WCAG 2.2, Directive (EU) 2019/882

Framväxande

• Portabel semantisk metadata tog ett viktigt steg 2025–2026. Open Semantic Interchange blev Apache Ossie (incubating) i juli 2026 och försöker standardisera datasets, dimensioner, relationer, metrics och AI-kontext. Projektets inkubatorstatus och unga konformitetsekosystem innebär att det bör användas som export-/interchangeformat, inte ännu som Datahearts enda interna sanningsmodell. Påståendet “write once, query anywhere” är tills vidare ett leverantörs-/projektpåstående. Apache Ossie

• Kontinuerlig auktoriseringssynkronisering över produkter har fått en leverantörsneutral standardbas genom OpenID Shared Signals Framework och CAEP, fastställda som Final Specifications i september 2025. Standarderna kan signalera att en session, användare, enhet eller applikation ska få minskad åtkomst. Att varje BI-, agent- och rapportyta verkligen tillämpar signalerna korrekt är fortfarande en implementeringsfråga. OpenID Shared Signals/CAEP final

• Agentytor standardiseras runt resurser och verktyg. MCP-revisionen 2025-11-25 separerar resurser, prompts och exekverbara verktyg, och kräver audience-bundna token för HTTP-auktorisering. Specifikationen varnar uttryckligen för token passthrough och confused-deputy-problem. Protokollet transporterar dock verktygsbeskrivningar; det bevisar inte att beskrivningen är sann, säker eller policygodkänd. MCP specification 2025-11-25

• En primär empirisk studie av 1 899 öppna MCP-servrar rapporterade allmänna sårbarheter i 7,2 procent och MCP-specifik tool poisoning i 5,5 procent. Resultatet är motbevis mot att protokollstandardisering i sig ger säker agentdistribution. Studien är ung och den dynamiska delanalysen lyckades bara för 60 av 83 utvalda servrar, vilket begränsar generaliserbarheten. Hasan et al., 2025-06-16

Hypoteser och leverantörspåståenden

• Hypotes: Ett gemensamt semantiskt mellanformat kan ge praktisk ekvivalens över DAX, SQL, GraphQL, kalkylblad och LLM-agenter. Detta är möjligt för en kontrollerad kärna av metrics och filter, men inte bevisat för samtliga språkfunktioner, hierarkier, lokaliseringar och klientberäkningar.

• Leverantörspåstående: Ett headless-lager eliminerar metric drift. Det minskar drift men eliminerar den inte; lokala Excel-formler, rapportmått, cached snapshots, API-konsumenters efterbearbetning och agentsammanfattningar kan fortfarande ändra betydelsen.

• Hypotes: Samma auktorisering kan “följa med” ett resultat. Säkrare formulering: samma policy kan omvärderas vid varje åtkomst, medan ett verifierbart policybesluts-ID följer med resultatet. En bearer token ska inte skickas vidare mellan ytor eller audiences.

Load-bearing concepts

Koncept	Kanalneutral invariant	Varför det är lastbärande
Semantiskt ID	Stabilt ID och version för metric, dimension, relation och åtgärd	Namn som “Revenue” räcker inte för ekvivalens
Query context	Filter, grain, tidszon, valuta, enheter, locale och kanonisk query-hash	Förhindrar att samma siffra betyder olika saker
Data context	Snapshot-/commit-ID, data_as_of, freshness och källversioner	Gör livevärden och statiska rapporter jämförbara
Security context	Aktör, delegeringskedja, tenant, audience och policybesluts-ID	Säkerheten måste kunna verifieras utan att råa token sprids
Evidence context	Källor, transformversion, modellversion, query-ID, resultat-hash och trace-ID	Gör resultat reproducerbara och granskningsbara
Presentation contract	Typ, precision, sortering, textalternativ, tabellalternativ och drill-länk	Gör kontexten begriplig i både visuella och icke-visuella ytor
Delivery context	Event-ID, schema, sequence/version, TTL, retry- och dedupe-nyckel	Behövs eftersom notifieringar kan dupliceras eller komma ur ordning
Action context	Intent, förväntad effekt, idempotency key, godkännande och utföranderesultat	Skiljer rekommendation från auktoriserad handling

W3C PROV-O:s modell med Entity, Activity, Agent och derivationsrelationer är en stabil bas för evidensutbyte, men behöver kompletteras med Dataheart-specifika fält för policybeslut, semantiska versioner och datatidslinjer. W3C PROV-O

Ett minimalt Dataheart-kuvert bör exempelvis innehålla:

{
  "result_id": "stable-result-id",
  "semantic_model": {"id": "sales", "version": "42"},
  "metrics": ["net-revenue"],
  "query_hash": "canonical-query-hash",
  "filters": {"period": "2026-Q2", "region": "se"},
  "locale": "sv-SE",
  "timezone": "Europe/Stockholm",
  "data_as_of": "2026-08-23T08:00:00Z",
  "snapshot_id": "source-snapshot-id",
  "policy_decision_id": "authorization-decision-id",
  "evidence_bundle_id": "provenance-bundle-id",
  "traceparent": "w3c-trace-context",
  "classification": "internal",
  "expires_at": "2026-08-24T08:00:00Z",
  "canonical_url": "authenticated-live-resource"
}

Kuvertet bör uttryckligen inte innehålla bearer-token, klienthemligheter eller onödiga personuppgifter.

Reference patterns

1. Live pull

Använd för API, SQL, embedded analytics, drill-down, kalkylblad och agentresurser.

1. Kanalen skickar en identitets- och audience-bunden fråga.
2. Dataheart normaliserar frågan till ett kanoniskt semantiskt uttryck.
3. Policybeslut tas för aktör, tenant, metric, dimension, grain och exportnivå.
4. Frågemotorn producerar resultat och evidenskuvert.
5. Adaptern renderar resultatet utan att ändra affärslogiken.

Detta är förstahandsmönstret för känslig eller snabbt föränderlig kunskap.

2. Signal then pull

Använd för Teams-/chatkort, e-post, pushnotiser och event subscriptions.

Notifikationen innehåller:

• Minimal, klassificerad sammanfattning.
• Resultat- eller rekommendations-ID.
• data_as_of och eventuell expiry.
• Autentiserad djuplänk.
• Inga fullständiga känsliga tabeller.
• Ingen delegerad bearer-token.

Vid klick eller agentuppföljning laddas aktuell kunskap och auktoriseringen omvärderas. Microsoft Graph stöder webhooks, Event Hubs och Event Grid men har resursberoende livslängder, kvoter och krav på förnyelse; rika notifieringar har kortare prenumerationslivslängd. Microsoft Graph change notifications

3. Statiskt evidensbundet artefakt

Använd för signerade rapporter, regulatoriska paket och offline-behov.

Artefakten måste bära:

• Tydlig snapshot- och modellversion.
• Filter, locale, tidszon och enheter.
• Utfärdandetid och data_as_of.
• Klassificering, mottagarbegränsning och retention.
• Resultat-hash och länk till evidenspaket.
• Tydlig märkning “statiskt — omvärderas inte automatiskt”.

Statiska PDF-, PNG-, CSV- och e-postbilder kan aldrig erbjuda samma fortlöpande auktorisering som en liveyta.

4. Recommend–approve–execute–attest

För agent- och proaktiva ytor:

1. Recommend: skapa ett icke-bindande förslag med evidens.
2. Plan: visa avsedda parametrar, omfattning och förväntad effekt.
3. Approve: omvärdera policy och begär lämpligt mänskligt eller maskinellt godkännande.
4. Execute: använd separat audience-bunden credential och idempotency key.
5. Attest: lagra vad som faktiskt utfördes, av vilket system, med vilket policybeslut och vilket utfall.

Läsverktyg och skrivverktyg ska vara separata. Ett chattsvar får inte implicit bli ett exekveringsgodkännande.

Vendor-neutral invariants vs deployment-profile choices

Område	Vendor-neutral invariant	Microsoft-native profile	Self-hosted/open profile
Identitet	OIDC/OAuth-principer, audience binding, delegeringskedja	Entra ID, Conditional Access, workload identities	Självhostad OIDC-provider, exempelvis Keycloak, plus policy engine
Kontinuerlig åtkomst	Revocation-/riskhändelser och omvärdering	Entra-/Microsoft 365-native CAE där resursen stöder det	OpenID SSF/CAEP-kompatibel signalkedja
Semantik	Stabilt Dataheart-ID, version och kanonisk querymodell	Fabric/Power BI semantic models, DAX/XMLA/SQL-adaptrar	Apache Ossie som interchange; Cube/MetricFlow eller egen semantisk runtime
Embedded	Servermintad kortlivad token, audience, origin, RLS/CLS	Power BI Embedded och egna Microsoft-webbkomponenter	Superset, Metabase eller egna tillgängliga webbkomponenter
Kalkylblad	Liveanslutning föredras; export måste versionsmärkas	Excel live connection/connected tables	SQL/ODBC/JDBC/API-baserad refresh eller självhostad webbtabell
Samarbetsyta	Minimal notifiering plus säker djuplänk	Teams, Outlook, SharePoint och Microsoft Graph	Matrix/Mattermost/e-post/webhooks
Events	CloudEvents-liknande kuvert, dedupe, idempotens, DLQ	Event Grid, Event Hubs, Service Bus, Graph notifications	Kafka, NATS eller Knative Eventing
Agent	Resurser skilda från verktyg; separat action approval	Microsoft-agentytor mot Dataheart-API:er	Självhostad MCP-server och agentvärd
Rapporter	Snapshot, expiry, mottagare, evidens och klassificering	Power BI/paginated reports och Purview-skydd	Superset reporting och kundägd objektlagring
Proveniens	Kanalneutral evidensmodell och exporterbart register	Azure Monitor/Fabric/Purview-adaptrar	OpenTelemetry/OpenLineage/W3C PROV-adaptrar
Tillgänglighet	WCAG 2.2 AA-testad semantik och alternativ representation	Testade Teams-/Power BI-/webbytor	Testade Superset-/egna webbkomponenter

Den Microsoft-native profilen har den starkaste färdiga integrationen med Teams, Excel, identitet och informationsskydd, men också den största risken för tenant-, kapacitets-, DAX/XMLA-, PBIX- och licenslåsning.

Den öppna profilen ger bättre drift- och dataägande men kräver mer integrations-, uppgraderings-, säkerhets- och tillgänglighetsarbete. Vissa “open core”-produkter placerar avancerad SSO, embedding eller rad-/kolumnsäkerhet i kommersiella versioner; licens och faktisk self-host-kapacitet måste därför verifieras komponent för komponent.

Failure modes and counter-evidence

Felbild	Motbevis/begränsning	Kontroll och kostnad
“Ett semantiskt lager ger samma svar överallt”	Cube dokumenterar delvis protokollstöd; Excel och Power BI bevarar inte alla hierarkier eller lokala mått	Golden-query-matris över samtliga ytor; ökad test- och releasekostnad
Embed-token utan korrekt slutanvändaridentitet	Power BI-roller appliceras annorlunda i app-owns-data; gästinbäddning kan luta på manuella filter	Negativa tenant-/RLS-tester och kort token-TTL
Dold UI-komponent behandlas som säkerhetskontroll	Klienten kan ofta anropa underliggande API direkt	Auktorisera varje API- och queryoperation server-side
Token passthrough mellan agent och downstream-API	MCP förbjuder detta eftersom audience och confused-deputy-gränser bryts	Token exchange eller separat downstream-auktorisering; mer identitetsinfrastruktur
Stale snapshot tolkas som livekunskap	PDF, e-postbild och statisk Excel-data omvärderar varken data eller policy	Watermark, expiry, snapshot-ID och säker live-länk
Notifiering behandlas som leveransgaranti	Event Grid kan duplicera, kasta, dead-lettera eller leverera ur ordning	Dedupe, idempotenta consumers, DLQ och reconciliation-jobb
Prenumeration löper ut tyst	Graph-prenumerationer har resursberoende livslängd och livscykelhändelser	Renewal controller, delta-recovery och prenumerations-SLO
Full data i pushpreview	Notifieringsyta kan visas på låsskärm eller efter kontextförändring	“Signal then pull”; inga känsliga värden i preview
RLS- eller cache-nyckel saknar tenant/policyversion	Delad cache kan returnera annan kunds resultat	Cache partitionerad på tenant, subject class, policyversion och query-hash
Högkardinal pre-aggregation	Kombinationer av tenant, roll, filter och freshness kan explodera lagring och refresharbete	Budget per modell, cache-admission och query-cost controls
SQL/API möjliggör kostnadsamplifiering	Semantiskt tillåtna frågor kan ändå skapa dyra joins eller breda exportjobb	Rad-/scan-/timeoutgränser, asynkrona exportköer och kostnadsattribution
Agent tror på verktygsbeskrivning	MCP-studien fann tool poisoning och traditionella sårbarheter	Signerade/pinnade verktygsmanifest, allowlist, sandbox och human approval
Iframe-/cookieberoende SSO	Webbläsarnas cross-site- och privacyregler kan bryta sessioner	Same-site-hosting eller tokenbaserad embedding; fler browserkonformitetstester
Rapportering underskattas operativt	Superset kräver bland annat scheduler, Celery workers, Redis/Postgres och headless browser; dokumentationen varnar för CPU-/minneskostnad	Separata rapportworkers, kögränser, observability och kapacitetsbudget
Accessibility testas bara i huvudappen	Embedded charts, e-post, Excel och agenttext kan tappa rubriker, fokusordning och textalternativ	Automatisk och manuell WCAG-testning per kanal och hjälpmedel
“Öppen profil” antas vara låsningsfri	Dashboarddefinitioner, DSL:er, cacheformat och enterprise-funktioner kan skapa ny låsning	Kundägt mellanformat, exporttest och återställningsövning utan originalprodukten

Apache Supersets embedded SDK kräver server-side hämtning av guest-token, har fem minuters standardlivslängd och varnar för att en tom allowed-domain-lista tillåter alla origins. Detta är bra förstapartsmotbevis mot att “självhostat” automatiskt betyder säkert. Superset embedding

Supersets rapporteringsdokumentation visar också den konkreta driftkostnaden: scheduler, Redis, PostgreSQL, Celery beat/workers, headless browser samt möjliga läckta browserprocesser och hög CPU-/minnesanvändning. Superset alerts and reports

Implications for Dataheart

1. Gör kontextkuvertet till en förstaklassprodukt. Varje API-svar, event, rapport, agentresurs och embedded query ska kunna returnera samma maskinläsbara metadata.

2. Ha en kanonisk intern representation som Dataheart äger. Apache Ossie kan vara import-/exportformat, men dess inkubatorstatus gör det olämpligt som enda interna kontrakt 2026.

3. Gör semantiska ID:n oberoende av deploymentprofilen. Power BI GUID, DAX-namn, Cube member names och Superset chart IDs ska vara mappningar, aldrig Datahearts kanoniska identitet.

4. Separera kunskap, presentation och transport. En metric definieras en gång; varje adapter anger vad den kan representera och måste neka eller degradera explicit när funktionen saknas.

5. Skapa en capability negotiation-modell. Exempel: supports_hierarchy, supports_live_rls, supports_protected_export, supports_drill, supports_action_confirmation och supports_accessible_table.

6. Behandla kalkylblad som programmerbara klienter. Liveanslutning bör vara standard. Lokala formler ska märkas som härledd, kundskapad logik och får inte automatiskt registreras som Dataheart-metric.

7. Notifiera förändring, inte hela kunskapen. Den säkraste notifieringen säger att något relevant har ändrats och länkar till en ny, auktoriserad utvärdering.

8. Låt agenter använda samma semantiska frågetjänst som BI. Undvik en separat “AI-databas” med kopierade metric-definitioner. Agentresurser ska referera samma metric- och snapshot-ID:n som SQL/API/rapport.

9. Inför action gateway. Alla skrivande verktyg ska passera policy, riskklassning, idempotens, godkännande och attestering. MCP eller annan agenttransport får inte vara själva säkerhetsgränsen.

10. Definiera profilparitet som konformitet, inte funktionsidentitet. Microsoft- och open-profilen är likvärdiga om de klarar samma semantik-, isolerings-, evidens-, tillgänglighets- och actiontester.

11. Gör kundägande verifierbart. Kunden ska kunna exportera semantiska modeller, policybundles, evidensregister, kanaldefinitioner, testfixtures och actionhistorik i dokumenterade format och återläsa dem utan den ursprungliga driftprofilen.

12. Budgetera dual-profile som en testmatris. Kostnaden är ungefär proportionell mot profiler × ytor × säkerhetsklasser × representationsformer, inte bara antalet integrationer. Forward deployed engineers bör utveckla adapters och konformitetsfixtures tillsammans med kunderna, men kärnkontrakten ska vara gemensamma.

Connections to other domains

• Kompilatorteknik: Den semantiska modellen fungerar som ett mellanformat; SQL, DAX, REST, Excel, rapport och agenttext är olika backends. En compiler-liknande arkitektur gör ofullständig feature mapping explicit.

• CQRS och event sourcing: Livefrågor är read-side, medan kontrollerade actions är command-side. Evidensregistret ger en händelsekedja utan att kräva att all analys lagras som events.

• Zero trust: Säkerhet “följer” inte resultatet genom en återanvänd bearer-token. Identitet och policy omvärderas vid varje trust boundary; resultatet bär referens till beslutet.

• SRE: Freshness, query latency, subscription renewal, dead-letter backlog, cache isolation och adapterparitet är mätbara SLO:er, inte bara BI-funktioner.

• Supply-chain security: Semantiska modeller, kanaladaptrar och agentverktygsmanifest behöver versionspinning, signering, provenance och kontrollerad promotion mellan miljöer.

• Digital tillgänglighet: Ett textalternativ eller en korrekt tabell är inte en sekundär fallback; den avslöjar om resultatets semantik faktiskt är komplett och kanaloberoende.

• Dokument- och records management: Statiska rapporter är records med snapshot, klassificering, retention och mottagare — inte bara exporterade skärmbilder.

Recommended experiments and conformance tests

1. Golden semantic parity

   Kör minst 100 referensfrågor via SQL, REST, embedded UI, Excel, rapport och agent. Kräv samma metric-ID, grain, filter, enhet, snapshot och numeriskt resultat inom deklarerad tolerans.

2. Unsupported-feature honesty

   Testa hierarkier, tidsintelligens, distinct counts, many-to-many, valutor och lokala format. En adapter ska antingen producera korrekt resultat eller returnera ett strukturerat “unsupported”; aldrig tyst approximera.

3. Cross-tenant isolation

   Generera token och queries för två tenants med överlappande primärnycklar. Testa API, embed, cache, export, agent, rapportworker och notifiering. Noll främmande rader eller metadata får exponeras.

4. Revocation propagation

   Återkalla användare, grupp, device/session eller workload identity under en aktiv session. Mät tid tills API, embed, kalkylblad, agent och djuplänk nekar åtkomst. Dokumentera ytor som inte kan uppfylla samma SLO.

5. Event chaos

   Duplicera, kasta, fördröj och omsortera events. Kräv idempotent slutläge, fungerande DLQ, återspelning och reconciliation mot källan.

6. Subscription lifecycle

   Låt Graph-/webhook-prenumerationer närma sig expiry, ta bort callback endpoint och återkalla appbehörighet. Kräv larm, automatisk förnyelse och delta-recovery utan permanent kunskapslucka.

7. Static-artifact leakage

   Exportera PDF, PNG, CSV, Excel och e-postrapport. Verifiera etikett/skydd, mottagare, watermark, metadata, expiry, offlinebeteende och att råa token aldrig bäddas in.

8. Embed adversarial test

   Manipulera iframe-URL, filter, origin, token audience, tenant-attribut och expired token. Försök anropa underliggande API direkt. Döljande av UI får inte påverka auktoriseringsresultatet.

9. MCP/tool-poisoning test

   Ändra verktygsbeskrivning efter godkännande, injicera instruktioner i datakällor och försök få agenten att använda ett skrivverktyg efter en läsfråga. Kräv manifeständringslarm och nytt godkännande.

10. Action idempotency

    Leverera samma action request flera gånger, avbryt efter timeout och återuppta. Exakt en avsedd affärseffekt ska uppstå, med full attestering för alla försök.

11. Accessibility matrix

    Testa tangentbord, skärmläsare, zoom, hög kontrast, focus order, tabellalternativ, statusmeddelanden och icke-färgburen betydelse på web, embed, rapport, chatkort och agentresultat mot WCAG 2.2 AA.

12. Portability exercise

    Exportera en verklig kundmodell från Microsoft-profilen och kör den i open-profilen, och vice versa. Mät andel metrics som är identiska, manuella översättningar, förlorade funktioner och återstående leverantörsextensioner.

13. Cost and load test

    Mät p95/p99-latens, warehouse scan, cache hit rate, pre-aggregationstorlek, rapportworker-minne, event backlog och kostnad per tenant/metric/channel. Inför budgetar och avvisning innan produktion.

14. Evidence replay

    Välj ett historiskt Excel-värde, chatkort, PDF och agentsvar. Kräv att det går att identifiera modell, query, snapshot, policybeslut och källor och att resultatet kan reproduceras eller att icke-reproducerbarhet förklaras maskinläsbart.

Sources

1. CloudEvents och CESQL — CloudEvents 1.0.2: 2022-02-05; CESQL 1.0 godkänd 2024-06-13.
2. Apache Ossie (incubating) — accepterat i Apache Incubator 2026-07-10; läst 2026-08-23.
3. Cube Core Data APIs — aktuell dokumentation läst 2026-08-23.
4. Model Context Protocol specification — protokollrevision 2025-11-25.
5. Hasan et al., “MCP at First Glance” — 2025-06-16.
6. OpenID Shared Signals, CAEP och RISC Final Specifications — 2025-09-02.
7. Microsoft: refreshable Power BI data in Excel — uppdaterad 2026-04-01.
8. Microsoft: Power BI Embedded security — uppdaterad 2025-12-15.
9. Microsoft Graph change notifications — uppdaterad 2025-03-05.
10. Azure Event Grid delivery and retry — uppdaterad 2026-02-12.
11. Apache Superset embedding — uppdaterad 2026-08-22.
12. Apache Superset alerts and reports — aktuell dokumentation läst 2026-08-23.
13. WCAG 2.2 — W3C Recommendation 2024-12-12.
14. Directive (EU) 2019/882 — antagen 2019-04-17; relevanta tjänstekrav gäller från 2025-06-28.
15. W3C PROV-O — W3C Recommendation 2013-04-30.