Editorial research feed

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.

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.

Datahearts mest bärkraftiga roll är inte att bli ännu en workflowmotor, agentplattform eller reverse-ETL-produkt. Det bör vara kundens styrande kontrollplan för en obruten verksamhetskedja:

Den vendor-neutrala kärnan bör vara ett kundägt action episode: ett versionsbeständigt ärende som binder samman trigger, evidens, beslut, behörighet, mänskligt ställningstagande, exekveringsförsök, faktisk effekt, kompensation och utfall. Microsoft- respektive self-hostedprofilen realiserar samma kontrakt med olika produkter.

Fyra slutsatser är särskilt viktiga:

Viktiga förändringar under perioden:

Research cut-off: 2026-08-23. Scope is restricted to source contracts and rapid, trustworthy onboarding.

Maturity labels:

Dataheart should define ultra-fast onboarding as time to first trustworthy, replayable and policy-correct dataset, not time to first successful connection.

The architectural unit should be a customer-owned source contract bundle:

As of 2026-08-23, no mature vendor-neutral specification guarantees that a metric expressed once will retain identical meaning and numerical behavior across Power BI/DAX, SQL metric engines, notebooks, BI tools and AI agents.

Dataheart should therefore own a vendor-neutral semantic control plane, not adopt one vendor’s “universal semantic layer” as its foundation. That control plane should contain customer-owned concept identities, metric contracts, versions, policy references, provenance and conformance tests, then compile or project a bounded portable subset into:

“Same metric everywhere” must be treated as a tested property:

result = evaluate(metric-version, query-scope, principal/policy-version, source-snapshot, engine-version)

Dataheart should treat trust as a verifiable chain of typed artifacts, not as a catalog badge or one aggregate “quality score.”

The state of the art supports a layered design:

No single standard covers this stack. DCAT, DQV, PROV, OpenLineage, data contracts, semantic layers, tracing, and attestation formats are complementary. Dataheart’s defensible differentiation is therefore a customer-owned canonical trust kernel that preserves these vendor-neutral invariants while mapping them to either Microsoft-native or self-hosted infrastructure.

Status labels below mean:

Dataheart bör inte bli en ny identitetsleverantör eller lova att ett enda policyspråk kan exekveras identiskt i API:er, databaser, Power BI/Fabric, sökindex och agentverktyg. Det hållbara målet är i stället en vendor-neutral authorization consistency layer:

Detta ligger nära NIST:s resursorienterade Zero Trust-modell, men går längre genom att göra tenant-noninterference, delegationskedjan och tvärkanalig beslutsekvivalens till explicit produktkontrakt.

Den viktigaste produktinsikten är:

Dataheart bör vara referensplanet för “vem eller vad agerade, för vems räkning, i vilken kundkontext, mot vilken resurs, enligt vilken policyversion, med vilket resultat”—inte den universella exekveringsmotorn för varje underliggande system.

Valid as of 2026-08-23.

Dataheart should treat the model as an untrusted, nondeterministic proposal engine—not as an authorization authority, transaction coordinator, identity provider, memory curator, or audit system.

The durable product boundary is therefore a vendor-neutral governance envelope around every agent run:

MCP and A2A materially reduce integration lock-in, but neither is a security model. MCP standardizes tool/context exchange; A2A standardizes agent-to-agent exchange. Identity, authorization, information-flow control, transaction semantics, evidence, memory governance, and human oversight remain Dataheart responsibilities. The NSA’s May 2026 assessment similarly concludes that MCP’s security posture remains uneven and implementation-dependent, despite calling it a de facto integration standard. NSA, MCP Security Design Considerations

Research valid as of 2026-08-23. “Resonansia” is treated as a proposed Dataheart component because no independent technical specification was supplied.

Dataheart should not be designed as one universal enterprise graph. It should be a customer-owned semantic and evidentiary contract that can be compiled into several operational representations:

The canonical unit should be a claim, not a naked triple. A claim must retain:

The strongest durable standards boundary is presently RDF 1.1/JSON-LD 1.1, lightweight OWL 2 profiles, SHACL, PROV-O, and canonical RDF exports. RDF 1.2 adds useful statement-level terms, but as of the cutoff it remains a Candidate Recommendation, while SPARQL 1.2 is still a Working Draft. ISO GQL is now a published property-graph query standard, but query syntax portability does not make RDF and labeled property graphs semantically equivalent. RDF 1.2, SPARQL 1.2, ISO GQL.

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:

“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:

As of 2026-08-23, the state of the art is not “portable software” but a portable, testable operating capability.

Dataheart should define portability as:

A customer can restore a named knowledge-and-action domain under a different operator and infrastructure while preserving data, business meaning, authorization outcomes, evidence, pending actions, and security properties within a measured RTO, RPO, cost, and loss budget.

This is stronger than container portability, data export, or source access. OCI images do not carry state or IAM semantics; open table formats do not carry the full business glossary or authorization model; SBOMs do not prove software safety; confidential computing does not remove jurisdictional, availability, or supply-chain dependencies.

Evidence labels: Established practice = supported by standards/repeated research; Emerging practice = visible across several current programs but not yet mature; Hypothesis = a Dataheart design proposition requiring validation; Vendor claim = first-party assertion without an adequate public counterfactual.

The durable FDE moat is not embedded headcount, bespoke code, or switching friction. It is the rate at which Kugghuset can convert privileged field learning into:

The proposed flywheel is:

customer problem → production outcome → measured evidence → generalized pattern → core/pack promotion → faster next deployment