Vad krävs för att Dataheart verkligen ska vara portabelt?

Forskningsfrågan

Under vilka villkor kan Dataheart flyttas, återskapas, drivas och vidareutvecklas av ett nytt team i en ny miljö med bevarad betydelse, säkerhet, styrning, funktion och kundnytta?

Vi valde den starkaste tolkningen av frågan. En flytt räknas först när en ny operatör kan fortsätta arbetet. Källkod, containerbilder och dataexport är viktiga delar, men de är inte själva målet.

Domslutet

verified Den breda hypotesen är falsifierad i nuläget.

Dataheart kan ännu inte lämnas över till ett nytt team och återställas i valfri miljö med bevarad betydelse, mandat och kundnytta.

verified En smalare och värdefull tes håller.

En kunnig operatör med omfattande Microsoft-behörigheter har kunnat driftsätta och verifiera Datahearts rapportdistributionslösning i ytterligare en Microsoft-tenant. Två öppna delsystem kunde dessutom byggas och testas från en ren källkopia.

Det betyder att Dataheart är partiellt portabelt. Microsoft-profilen har kommit långt. Full tenant-bootstrap, oberoende teamöverlämning, komplett restore, bevarad verksamhetsbetydelse och en andra konformant runtimeprofil återstår att bevisa.

Så genomfördes undersökningen

Tre oberoende agenter arbetade parallellt.

1. Den tekniska arkeologen följde kod, IaC, identiteter, verktyg, hemligheter, databaser, deployment och restore.
2. Betydelseforskaren följde verksamhetsregler, mandat, språk, evidens, licenser, FDE-överlämning och kundägande.
3. Den adversariala experimentledaren antog nytt team, ny GitHub-organisation, ny tenant och ny värd och försökte hitta den första blockeraren.

Huvudagenten var ensam sammanställare. Dokumentation behandlades som specified, inte som bevis. Kod märktes implemented, test och readback verified, levande resurser deployed och effekter utanför systemets egen status observed_outcome.

Ett eget clean-room-prov genomfördes för Research Atlas och bidragstjänsten. Endast källkod, forskningspaket och låsfiler kopierades till en ny katalog. Gamla beroenden, dist-mappar och cache följde inte med.

Berättelse 1: Från Power Apps till en fristående Microsoft-app

Dataheart började som en Power Apps Code App med custom connector och särskilda Power Platform-beteenden. Mobil Safari, inloggningsredirects och connectoranslutningar gjorde själva skalet till en del av problemet.

Den aktiva lösningen flyttades till Static Web Apps, Azure Functions, Entra och Power BI Embedded. Resterna av det äldre flödet arkiverades. Den nya sandboxens webbapp svarar och den skyddade Function-ytan nekar anonym åtkomst.

deployed En verklig plattformslåsning har tagits bort.

verified Flytten bevisar fortfarande Microsoft-native portabilitet, inte leverantörsoberoende. Identitet, API, SQL, rapportering och katalogintegration är fortsatt nära kopplade till Entra, Azure och Fabric.

Berättelsens värde är konkret. Dataheart har redan överlevt ett byte av presentations- och integrationsyta utan att produktidén försvann.

Berättelse 2: En oförberedd tenant blev en fungerande sandbox

Den första inventeringen av Studio L'Narte-tenanten saknade flera av de förutsättningar som lösningen behövde. Senare fanns Azure SQL, Function App, Static Web App, managed identities, Key Vault, lagring, observability, Fabric-anslutningar, semantisk modell och tre rapporter.

Preflight hittade inga blockerare i de granskade kärndelarna. Managed identity nådde SQL och verifierade utvalda procedurer. Anonym API-åtkomst nekades som avsett.

deployed och verified Detta är forskningsmaterialets starkaste portabilitetsberättelse.

Begränsningen är lika viktig. Samma centrala person bar både historik, behörigheter och genomförande. Fabric-kapacitet, workspace och semantisk modell var delvis förutsättningar eller identifierade resurser. Testet visar återdriftsättning i en andra Microsoft-tenant. Det visar ännu inte kunskapsoberoende överlämning.

Berättelse 3: Den gröna pipelinen skickade noll mejl

En Fabric-körning rapporterade Completed efter ungefär trettio sekunder. Inga mejl hade skickats. Parametrarna hade tappats på vägen genom ett felaktigt API-format.

Efter korrigering beskriver projektets historik tre livekörningar och sex leveranser verifierade i Exchange. Skillnaden mellan de två tillstånden är kärnan i Dataheart.

implemented Plattformens interna status var grön.

specified Den externa leveransen var först noll och blev senare verifierad.

Berättelsen falsifierar tanken att deploymentstatus eller pipelineutfall räcker som kundutfall. En portabel Dataheart-kedja måste följa signalen hela vägen till auktoritativ readback hos mottagande system.

Berättelse 4: En liten join kunde blanda två mottagare

Planeringen kopplade samman data med en nyckel som inte var unik. Två mottagares parametrar kunde hamna i samma Power BI-rendering.

Felet rättades med ett stabilt rad-ID, unikhetsregler och ett omfattande SQL-testpaket.

implemented Säkerheten låg först i en lokal SQL-förutsättning.

implemented Korrigeringen gjorde mottagarscope explicit och testbart.

Detta är en viktig portabilitetsberättelse eftersom den visar att semantik också är säkerhet. Ett system kan flytta alla tabeller korrekt och ändå förlora betydelsen av vilken rad som tillhör vilken mottagare. Mottagaravgränsning, scope och parameterursprung behöver bli portabla kontrakt.

Berättelse 5: Nitton manuella steg blev början till en plattform

En tidig portabilitetsinsats centraliserade GUID:er, flyttade klartextshemligheter ur notebooks och gjorde SQL-bootstrap mer idempotent. Samma arbete dokumenterade ungefär nitton manuella steg, fyra API-återvändsgränder och två kommersiella grindar.

implemented Ett stort antal spridda inställningar blev deklarativ konfiguration och automation.

verified Automationen kunde ändå inte trolla bort administratörssamtycke, licenser eller plattformars ofullständiga API-stöd.

Berättelsen är inte ett misslyckande. Den visar hur verklig portabilitet växer fram. Varje manuellt steg måste antingen automatiseras, göras till en uttrycklig mänsklig gate med readback eller deklareras som en extern förutsättning.

Berättelse 6: Microsoft 365-katalogen stoppade maskinen

Azure-, SQL-, Fabric-, Function- och webbdelar kunde driftsättas. Microsoft 365-publiceringen gav 403 Forbidden.

Den aktuella Microsoft Graph-operationen för Teams-katalogpublicering stöder delegerade behörigheter och saknar stöd för application permission i den aktuella operationen. En obemannad OIDC-identitet med bred application permission är därför inte samma sak som en stödd katalogpublicerare.

verified Tenantbehörigheter är en del av produkten, inte bakgrundsadministration.

specified M365-publicering behöver beskrivas som delegerad mänsklig gate eller submit-and-review-process tills motsatsen är bevisad.

Berättelse 7: Research Atlas lämnade Microsoftvärlden

Research Atlas körs som statisk Astro-webb, TypeScript-tjänst, Postgres, systemd och Caddy. Webb och API installeras som immutabla versionskataloger med atomisk current-länk. Bidragsdatabasen är privat och kan hanteras separat från den publika forskningen.

I clean-room-provet installerades 342 paket utan rapporterade npm-sårbarheter. Webbplatsen byggde 88 sidor på 3,23 sekunder. Sexton webb- och forskningstester passerade. Bidragstjänsten kompilerade och dess fem tester passerade. Hela försöket tog 45,8 sekunder på den använda maskinen.

verified Två avgränsade öppna delsystem kan reproduceras från källan.

implemented Produktionsinstallationen förutsätter fortfarande Linux, /srv, Docker, systemd, Caddy, materialiserade hemlighetsfiler och överförda releasearkiv. Postgresbilden är taggad men inte digestpinnad.

Berättelsen visar både förmåga och återstående arbete. Självhostad drift finns på riktigt för Atlas, men den är ännu inte en självhostad profil av hela Dataheart.

Berättelse 8: Schemat bevarade formen men inte hela betydelsen

Research Atlas har stabila ID:n, tidsmetadata, stödjande och utmanande evidens, falsifieringskriterier, mänsklig attest och innehållshash. Tio forskningskörningar och trettio kurerade påståenden publiceras.

Samtidigt innehåller de engelska falsifieringsfälten fortfarande en platshållare från granskningsflödet. En lokaliseringsfallback kan dölja att en översättning saknar motsvarande betydelse.

implemented Maskinläsbar form och revisionskedja överlevde publiceringen.

verified Semantisk ekvivalens mellan språken gjorde det inte fullt ut.

Berättelsen är ett koncentrerat exempel på hela forskningsfrågan. Ett validerat kontrakt kan bära rätt struktur och ändå lämna en människa med fel eller ofullständig förståelse.

Vad clean-room-provet faktiskt bevisade

Påstående	Status	Bedömning
Atlasens publika projektion kan byggas från källan	verified	Ja
Bidragstjänsten kan kompileras och testas från källan	verified	Ja
Låsfiler räcker för de två Node-delsystemen	verified	Ja, på den använda plattformen och dagen
Produktionshemligheter kan återskapas från Git	verified	Nej, och de ska inte finnas där
Hemlighetsnamn, ägare och materialisering är en komplett exekverbar kedja	specified	Delvis dokumenterat, inte fullständigt bevisat
Hela Dataheart kan köras självhostat	specified	Hypotes
En ny operatör kan återställa produktionsdata	specified	Obevisat
En ny operatör kan bevara kundens betydelser och mandat	specified	Obevisat

Vad som faktiskt är byggt

• implemented Bicep för stora delar av Azure-resursgrunden.
• implemented Tenantmanifest, Graph- och Entra-automation, SQL-migreringar, API, frontend, rapporter och preflight.
• deployed En andra Microsoft-sandbox med centrala resurser.
• verified Readback för utvalda SQL-, Fabric-, rapport- och säkerhetsdelar.
• implemented Action episodes med planhash, mänskligt godkännande, reauktorisering, verkställighet och readback för ett smalt driftområde.
• deployed Självhostad Research Atlas och privat bidragskö.
• verified Ren build för Atlas och bidragstjänst.

Vad som fortfarande är målbild

• specified Den fulla kedjan SourceContract -> ChangeEnvelope -> MeaningContract -> PolicyDecision -> EvidenceEnvelope -> Recommendation -> ActionIntent -> ActionReceipt -> OutcomeObservation -> Learning.
• specified En komplett självhostad eller öppen runtimeprofil med samma konformitet som Microsoft-profilen.
• specified Signerade releaseartefakter, SBOM och provenance i aktiv leveranskedja.
• specified Full backup, export, restore och mätt RTO/RPO.
• specified Oberoende teamöverlämning.
• specified Observerat kundutfall efter profil- eller operatörsbyte.

Den farligaste sammanblandningen

Dataheart, Microsoft-profilen och DNB-implementationen är ännu inte rena lager.

DNB-specifika rapporter, SQL-antaganden, parametrar och texter finns fortfarande i aktiv runtime. Azure Functions, Easy Auth, Azure SQL och Fabric importeras direkt i plattformskoden. Den neutrala kontraktsryggraden finns främst i forskning och målarkitektur.

Det betyder inte att vi ska kasta bort den Microsoft-native produkten. Det betyder att vi måste beskriva den ärligt:

1. Dataheart-kärnan är det som ska bevara identitet, betydelse, policy, evidens, rekommendation, handling och utfall.
2. Microsoft-profilen implementerar kärnan med Entra, Azure, SQL, Fabric, Power BI, Graph och M365.
3. DNB-paketet innehåller kundens rapporter, varumärke, parametrar, verksamhetsregler och distributionskonfiguration.
4. Miljötillstånd innehåller tenant-, subscription-, workspace-, capacity-, app- och connection-ID:n samt samtycken och hemligheter.

Forskningen visar att denna separation är specified och delvis implemented, men ännu inte verifierad som fysisk produktgräns.

Den gemensamma principen

Portabilitet är en kedjeegenskap.

Den är inte starkare än den svagaste övergången mellan:

artefakt
-> identitet
-> data
-> betydelse
-> policy och mandat
-> evidens
-> kontrollerad handling
-> auktoritativ readback
-> observerat utfall
-> lärande

EU Data Act skiljer också mellan att exportera data och att återfå funktionell likvärdighet. OCI gör programartefakter interoperabla. Power Platform ALM och miljövariabler separerar lösning från målmiljö. Inget av dessa lager bevarar ensamt kundens verksamhetsbetydelse eller externa utfall.

Det avgörande nästa experimentet

Skapa först en ren, granskad och signerad release. Ge sedan ett nytt team endast:

• release och källhash
• kontrakt och scheman
• rättighetsmatris
• namn på hemligheter och deras ägare
• restoreunderlag
• ett generiskt kundpaket
• testscenarier och accepterade utfall

Använd ny GitHub-organisation, tenant, prenumeration, DNS och identiteter. Konrad får observera men inte utföra eller förklara.

Försöket godkänns när teamet:

1. orienterar sig på högst fyra timmar
2. producerar en giltig plan på en arbetsdag
3. skapar kärnan på två arbetsdagar
4. når ett första betrott externt utfall på fem arbetsdagar
5. återger minst 90 procent av valda verksamhetsbegrepp korrekt
6. återställer data inom beslutad RTO och RPO
7. genomför ett återkallat mandat och ett negativt säkerhetsscenario
8. gör en liten domänändring och rollback utan muntlig hjälp

Forskningsdom

Dataheart har kommit längre än en vanlig prototyp. Det finns verklig drift, en andra tenant, maskinidentiteter, rapporter, databaser, readback, en fungerande öppen forskningsplattform och mycket värdefulla felberättelser.

Den starkaste slutsatsen är därför varken att Dataheart är portabelt eller att det saknar portabilitet.

Dataheart har bevisat att delar av hjärtat kan fortsätta slå efter ett miljöbyte. Nästa uppgift är att bevisa att betydelsen, ansvaret och nyttan följer med när även människorna och plattformen byts ut.

Källor

• Dataheart repository
• Dataheart Research Atlas
• EU Data Act
• OCI Image Specification
• Power Platform environment variables
• Power Apps code apps ALM
• Microsoft Graph: publish teamsApp
• SLSA specification

Transparens

Rapporten har tagits fram av tre specialiserade AI-agenter och en syntetiserande huvudagent. Konrad initierade forskningsuppdraget och godkände det den 24 augusti 2026 för publicering som AI-framtaget forskningsmaterial efter redaktionell granskning. Granskningskvittot redovisar mänsklig närvaro, agentautonomi och verifieringsdjup. Slutsatserna ska fortsatt prövas och falsifieras.