What would make Dataheart genuinely portable?

Research question

Under what conditions can Dataheart be moved, recreated, operated and evolved by a new team in a new environment while preserving meaning, security, governance, function and customer value?

We used the strongest interpretation. A move counts only when a new operator can continue the work. Source code, container images and data exports matter, but they are not the outcome.

Verdict

verified The broad hypothesis is currently falsified.

Dataheart cannot yet be handed to a new team and restored in an arbitrary environment with preserved meaning, authority and customer value.

verified A narrower and valuable thesis holds.

A knowledgeable operator with extensive Microsoft permissions has deployed and verified Dataheart's report-distribution solution in another Microsoft tenant. Two open subsystems were also built and tested from a clean source copy.

Dataheart is therefore partially portable. The Microsoft profile is advanced. Complete tenant bootstrap, independent handover, complete restore, preserved business meaning and a second conformant runtime profile remain unproven.

Method

Three independent agents worked in parallel.

1. A technical archaeologist traced code, infrastructure as code, identity, tools, secrets, databases, deployment and restore.
2. A meaning and governance researcher traced business rules, authority, language, evidence, licensing, FDE handover and customer ownership.
3. An adversarial experiment lead assumed a new team, GitHub organisation, tenant and host, then searched for the first blocker.

The lead agent was the sole synthesizer. Documentation counted as specified, code as implemented, tests and readback as verified, live resources as deployed, and effects beyond internal system status as observed_outcome.

A separate clean-room build was run for Research Atlas and the contribution service. Only source, research packages and lockfiles entered the new directory. Existing dependencies, dist directories and caches were excluded.

Story 1: From Power Apps to a standalone Microsoft app

Dataheart began as a Power Apps Code App with a custom connector and Power Platform-specific behavior. Mobile Safari, authentication redirects and connector connections made the shell part of the problem.

The active solution moved to Static Web Apps, Azure Functions, Entra and Power BI Embedded. The old path was archived. The sandbox web app responds and the protected Function surface rejects anonymous access.

deployed A real platform dependency was removed.

verified The change still demonstrates Microsoft-native portability, not vendor independence. Identity, API, SQL, reporting and catalog integration remain closely tied to Entra, Azure and Fabric.

Story 2: An unprepared tenant became a working sandbox

The first inventory of the Studio L'Narte tenant lacked several prerequisites. Later it contained Azure SQL, a Function App, Static Web App, managed identities, Key Vault, storage, observability, Fabric connections, a semantic model and three reports.

Preflight found no blockers in the reviewed core. Managed identity reached SQL and verified selected procedures. Anonymous API access was denied as intended.

deployed and verified This is the strongest portability story in the evidence.

The limitation matters equally. The same central person carried history, permissions and execution. Fabric capacity, workspace and semantic model were partly prerequisites or existing resources. The experiment demonstrates redeployment in a second Microsoft tenant, not knowledge-independent handover.

Story 3: The green pipeline sent no email

A Fabric run reported Completed after roughly thirty seconds. No email had been delivered because parameters were lost through an incorrect API shape.

After correction, project history describes three live runs and six deliveries verified through Exchange.

implemented Internal platform status was green.

specified External delivery was first zero and later verified.

The story falsifies the idea that pipeline state is a customer outcome. A portable Dataheart chain must continue to authoritative readback in the receiving system.

Story 4: One small join could mix two recipients

Planning joined data on a key that was not unique. Parameters from two recipients could enter the same Power BI rendering.

The problem was fixed with a stable row ID, uniqueness rules and a substantial SQL test suite.

implemented Security initially depended on a local SQL assumption.

implemented The correction made recipient scope explicit and testable.

This shows that semantics are also security. Moving every table correctly can still lose the meaning of which row belongs to which recipient. Recipient boundaries, scope and parameter provenance need portable contracts.

Story 5: Nineteen manual steps became the beginning of a platform

An early portability effort centralized GUIDs, removed plaintext secrets from notebooks and made SQL bootstrap more idempotent. It also recorded around nineteen manual steps, four API dead ends and two commercial gates.

implemented Scattered settings became declared configuration and automation.

verified Automation could not remove administrator consent, licensing or incomplete platform APIs.

Each manual step must be automated, converted into an explicit human gate with readback, or declared as an external prerequisite.

Story 6: The Microsoft 365 catalog stopped the machine

Azure, SQL, Fabric, Function and web components could deploy. Microsoft 365 publication returned 403 Forbidden.

The current Microsoft Graph operation for Teams catalog publication supports delegated permissions and does not support application permission for that operation. An unattended OIDC identity is therefore not equivalent to a supported catalog publisher.

verified Tenant permissions are part of the product, not background administration.

specified M365 publication needs a delegated human gate or submit-and-review flow until another path is demonstrated.

Story 7: Research Atlas left the Microsoft world

Research Atlas runs as a static Astro site, TypeScript service, Postgres, systemd and Caddy. Web and API install into immutable release directories with an atomic current link. The private contribution database is separate from public research.

The clean-room build installed 342 packages with no reported npm vulnerabilities. The website built 88 pages in 3.23 seconds and passed 16 tests. The contribution service compiled and passed five tests. The complete experiment took 45.8 seconds on the machine used.

verified Two bounded open subsystems reproduce from source.

implemented Production installation still assumes Linux, /srv, Docker, systemd, Caddy, materialized secret files and transferred release archives. The Postgres image uses a tag rather than a digest.

Self-hosting is real for Atlas, but Atlas is not yet a self-hosted profile for all of Dataheart.

Story 8: The schema preserved shape but not all meaning

Research Atlas has stable identifiers, temporal metadata, supporting and challenging evidence, falsification criteria, human attestation and content hashes. Ten runs and thirty curated claims are public.

The English falsification fields still contain a review placeholder. Localization fallback can hide that a translation lacks equivalent meaning.

implemented Machine-readable shape and revision history survived publication.

verified Full semantic equivalence across languages did not.

This is the entire research question in miniature. A validated contract can carry the correct structure while leaving a person with incomplete understanding.

What the clean-room build demonstrated

Claim	Status	Assessment
Public Atlas projections build from source	verified	Yes
The contribution service compiles and tests from source	verified	Yes
Lockfiles suffice for the two Node subsystems	verified	Yes, on the platform and date tested
Production secrets can be recreated from Git	verified	No, and they should not be stored there
Secret naming, ownership and materialization form a complete executable chain	specified	Partly documented, not fully demonstrated
All of Dataheart can operate self-hosted	specified	Hypothesis
A new operator can restore production data	specified	Unproven
A new operator can preserve customer meaning and authority	specified	Unproven

The portability chain

Portability is no stronger than the weakest transition between:

artifact
-> identity
-> data
-> meaning
-> policy and authority
-> evidence
-> controlled action
-> authoritative readback
-> observed outcome
-> learning

The EU Data Act also distinguishes export from functional equivalence. OCI makes software artifacts interoperable. Power Platform ALM and environment variables separate a solution from target configuration. None of these layers alone preserves the customer's business meaning or external outcomes.

The decisive next experiment

First create a clean, reviewed and signed release. Give a new team only:

• release and source hash
• contracts and schemas
• permission matrix
• secret names and owners
• restore material
• a generic customer package
• scenarios and accepted outcomes

Use a new GitHub organisation, tenant, subscription, DNS and identities. Konrad may observe but not execute or explain.

The experiment succeeds when the team:

1. orients within four hours
2. produces a valid plan within one workday
3. creates the core within two workdays
4. reaches a first trusted external outcome within five workdays
5. reproduces at least 90 percent of selected business concepts correctly
6. restores data within the agreed RTO and RPO
7. executes a revoked-authority case and a negative security scenario
8. makes a small domain change and rollback without oral help

Research verdict

Dataheart is beyond an ordinary prototype. It has real operations, a second tenant, machine identities, reports, databases, readback, a working open research platform and valuable failure stories.

The strongest conclusion is neither that Dataheart is portable nor that it lacks portability.

Dataheart has shown that parts of the heart keep beating after an environment change. The next task is to prove that meaning, responsibility and value travel when both people and platform change.

Sources

• 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

Transparency

Three specialist AI agents and one synthesizing lead agent produced this report. Konrad initiated the research assignment and approved it on 24 August 2026 for publication as AI-produced research material after editorial review. The review receipt records human presence, agent autonomy and verification depth. The conclusions remain open to testing and falsification.