Executive thesis

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.

The recommended architecture is one portable Dataheart kernel plus replaceable deployment adapters:

• The kernel owns vendor-neutral semantic, policy-decision, evidence, action, and export contracts.
• Each customer owns its identity trust, encryption roots, policy approval, audit evidence, backups, and deployment boundary.
• The Microsoft-native profile uses Microsoft implementations without making their representations canonical.
• The self-hosted/open profile operates without Microsoft or public-cloud dependencies, including offline build, registry, update, recovery, and attestation paths.
• Conformance tests—not architectural diagrams—define whether the profiles are equivalent.

Sovereignty should be treated as a vector, not a badge. The European Commission’s 2026 framework assesses strategic, jurisdictional, data/AI, operational, supply-chain, technological, security, and environmental sovereignty. It explicitly distinguishes data sovereignty from technological and full sovereignty. Residency alone is therefore insufficient. European Commission, 1 June 2026

State of the art 2024-2026

Labels used below: Established, Emerging, Hypothesis, and Vendor claim.

Established

• EU switching rights are now operational. The Data Act has applied since 12 September 2025. It requires contractual exit support, machine-readable export, open interfaces for non-IaaS services, a default 30-day transition, continuity during switching, and eventual erasure. Reduced switching charges may still apply until 12 January 2027. Crucially, it does not require a provider to rebuild its PaaS/SaaS elsewhere, and export may exclude provider IP, trade secrets, and some security information. EU Data Act, 13 December 2023

• Supply-chain evidence is becoming normal product infrastructure. SPDX 3.0 is the current version of an ISO-backed SBOM standard; SLSA 1.2, released in November 2025, adds an approved Source Track alongside build provenance. CISA’s 2025 SBOM minimum elements add component hashes, licences, generation context, tool identity, validation, known unknowns, and SaaS/AI considerations. SPDX, SLSA 1.2, CISA SBOM minimum elements

• EU product-security obligations are moving from policy to operations. Under the Cyber Resilience Act, vulnerability and incident reporting starts on 11 September 2026; the broader regime applies from 11 December 2027. The act requires vulnerability handling, support-period documentation, technical documentation, and machine-readable SBOM generation, although SBOMs are not necessarily public. Cyber Resilience Act, 23 October 2024

• Artifact and workload packaging is mature but bounded. OCI Image and Distribution 1.1 support typed artifacts and associations to signatures, attestations, and SBOMs. This is a sound delivery boundary for Dataheart components. It says little about databases, networks, IAM, accelerators, managed services, or control-plane behavior. OCI 1.1, 13 March 2024

• Open analytical tables are a credible data-exit substrate. Apache Iceberg versions 1–3 are adopted; the format carries schemas, snapshots, row lineage, and evolution over Parquet/Avro/ORC. Version 4 remains under development and explicitly tackles relocatable paths—evidence that apparently open tables can still be location-bound. Apache Iceberg specification

• “Open source” has a precise meaning. Source inspection alone does not provide the right to modify, redistribute, fork, or continue operations. A “fully open” profile therefore requires OSI-approved licensing for every load-bearing runtime component. Otherwise the accurate term is “self-hosted, source-available” or “open-standards based.” OSI Open Source Definition, modified 16 February 2024

Emerging

• Sovereignty is becoming an assessable procurement property. The Commission’s completed 2026 procurement introduced SEAL levels and 48 criteria. This is important emerging practice, but not yet a universal certification or proof that any particular service satisfies Dataheart’s threat model.

• Confidential computing is moving from specialized enclaves to rehostable confidential VMs. IETF RATS provides a vendor-neutral model of attester, evidence, verifier, reference values, appraisal policy, and relying party. It is informational architecture, not an interoperable security product by itself. RFC 9334, January 2023

• Disconnected Microsoft control planes are becoming real deployment options. Microsoft documents Azure Local disconnected operation with a local control plane, offline servicing, local identity/monitoring, AKS, registry, Key Vault, and selected AI services. It remains a subset, needs supported customer-owned hardware, capacity planning, a management cluster, an eligible agreement, and a validated use case. Microsoft, updated 14 May 2026

• Policy and semantic portability remain under-standardized. OIDC, OAuth, Kubernetes, OpenAPI, OpenTelemetry, OpenLineage, and policy engines cover pieces, but there is no broadly adopted standard that guarantees identical business authorization, obligations, evidence, and controlled-action semantics across Entra/Purview/Fabric and a self-hosted stack.

Hypothesis

A canonical, vendor-neutral intermediate representation for:

• principals and resources;
• business concepts and relationships;
• policy inputs, decisions, reasons, and obligations;
• recommendation and action lifecycles;
• evidence references and signed receipts;

will produce more durable portability than attempting to restrict both profiles to their lowest common implementation feature set.

This needs experimental validation. Policy compilers and adapters can themselves become opaque lock-in points unless their schemas, test vectors, and decision traces are customer-readable.

Vendor claim

Microsoft states that Azure Arc can manage any CNCF-certified Kubernetes cluster across other clouds and on-premises environments. Arc agents normally establish an outbound connection to Azure, so Arc portability is not the same as control-plane independence. Microsoft Azure Arc

Microsoft also describes confidential VMs as creating a hardware-enforced boundary from the host. Its documentation simultaneously records regional and OS restrictions, specialized hardware, increased disk cost, offline-only key rotation, and missing features including Azure Backup, Site Recovery, live migration, and accelerated networking. Microsoft, updated 5 February 2026

Load-bearing concepts

1. Customer-owned security domain

For each customer, ownership must include more than a cloud subscription:

• Root identity and federation configuration.
• Encryption and signing keys, HSM administration, rotation, and recovery quorum.
• Policy approval and break-glass authority.
• Authoritative audit/evidence storage.
• Backups and recovery credentials in a separately administered failure domain.
• Artifact allowlists and deployment trust roots.
• The right and tooling to revoke Kugghuset support access.

Kugghuset FDE access should be customer-approved, just-in-time, time-limited, attributable, and unable to cross customer domains. No Kugghuset-wide credential, signing key, or control plane should be capable of decrypting customer data or silently authorizing customer actions.

2. Portability strata

Dataheart should measure these separately:

1. Artifact portability: binaries, OCI images, models, policies, configuration.
2. State portability: tables, objects, graph state, indexes, queues, pending workflows.
3. Semantic portability: definitions, identifiers, mappings, units, taxonomies, provenance.
4. Authorization portability: subjects, resources, conditions, decisions, obligations, delegation.
5. Action portability: approvals, idempotency keys, execution state, compensation and receipts.
6. Evidence portability: signed, ordered, independently verifiable evidence chains.
7. Operational portability: installation, upgrades, monitoring, incident response and recovery.
8. Legal portability: licences, support rights, export rights, subcontractors and jurisdiction.

A product should not be called portable without stating which strata passed.

3. Open product boundaries

Each load-bearing boundary should have:

• A versioned protocol and machine-readable schema.
• Stable identifiers independent of cloud resource IDs.
• Compatibility and deprecation rules.
• An independent consumer/provider conformance suite.
• Bulk export and incremental change feed.
• No requirement for vendor consoles to interpret exported state.
• Signed artifacts and declared licence terms.
• Separate-process or container extensions with explicit capabilities.

Customer extensions should live in customer-controlled repositories and signing domains. Generic FDE improvements should flow upstream through documented extension points, not permanent customer forks.

4. Portable evidence envelope

Every recommendation and controlled action should produce an exportable receipt containing at least:

• customer and security-domain ID;
• actor/workload identity and authentication context;
• input and output artifact hashes;
• business-object and semantic-version IDs;
• policy version/hash, decision, reason and obligations;
• model, prompt/template, tool and connector versions where relevant;
• approval and separation-of-duties evidence;
• requested, authorized, started and completed timestamps;
• external system receipt;
• result, retry, compensation and exception state;
• links to data lineage and software provenance;
• cryptographic signature and previous-receipt hash.

The receipt—not a vendor dashboard—must be the audit source of record.

5. Exit as an operating mode

An exit plan is only credible when exercised. Backups, offline registries, source escrow, licences, documentation and migration scripts that have not been used are inventory, not capability.

6. Confidential computing as conditional key release

The portable abstraction is not “run on SEV-SNP” or “use Azure Attestation.” It is:

Release this key only when fresh evidence, reference values, endorsement state and customer appraisal policy establish an approved workload and TCB.

RATS supplies the conceptual roles. Each profile may use different attestation formats and hardware, but the customer must control the appraisal policy and retain verification evidence.

Reference patterns

flowchart LR
    S["Business surfaces and agents"] --> API["Versioned Dataheart contracts"]
    API --> K["Portable semantic, policy and action kernel"]
    IAM["Customer identity domain"] --> K
    KMS["Customer key and signing domain"] --> K
    K --> P["Deployment-profile adapters"]
    P --> M["Microsoft-native services"]
    P --> O["Self-hosted/open services"]
    K --> E["Customer-owned evidence and export plane"]
    M --> E
    O --> E
    T["Conformance and exit suite"] --> K
    T --> M
    T --> O

Pattern A: portable kernel, native adapters

Keep the following out of the kernel:

• Azure resource IDs and Entra object IDs as primary identifiers.
• Direct dependencies on cloud SDKs.
• Provider-specific policy syntax.
• Provider workflow instance IDs as authoritative action state.
• Provider telemetry schemas as the only evidence representation.

Adapters translate between the canonical contracts and the profile’s native implementation.

Pattern B: exportable state plane

Maintain a continuously exportable corpus containing:

• Iceberg/Parquet or another declared open tabular representation.
• Object content with checksums and content types.
• Semantic model, glossary and identifier mappings.
• Policy source plus compiled target artifacts.
• Identity mapping records without exporting credentials.
• Action ledger and pending-workflow state.
• Evidence receipts, lineage and referenced software/model artifacts.
• Deployment configuration and secrets manifest, excluding secret values.

Prefer relative, remappable locations. Test that the catalog, namespace, authorization metadata, and table history—not merely Parquet files—survive relocation.

Pattern C: verifiable offline delivery

A release bundle should contain:

• Digest-pinned OCI artifacts.
• Signed SPDX SBOM and SLSA provenance.
• Vulnerability and VEX material.
• Deployment manifests for both profiles.
• Required firmware/driver compatibility declarations.
• Offline documentation and migration tools.
• A trusted-root rotation procedure.
• Reproducible or independently rebuildable source for load-bearing components.

Pattern D: sovereign confidential zone

Use confidential computing only for specifically classified workloads. Keep the TCB small, make key release attestation-bound, archive the appraisal evidence, and provide a non-confidential recovery path for availability emergencies where policy permits.

AMD’s 2025 bulletin for CVE-2024-56161 shows why attestation must check patched microcode and firmware: a privileged local attacker could otherwise compromise SEV-SNP guest confidentiality and integrity. AMD-SB-3019, updated 10 June 2025

Vendor-neutral invariants and profile choices

Concern	Vendor-neutral invariant	Microsoft-native profile	Self-hosted/open profile
Compute	OCI artifacts; declarative health, resource and lifecycle contract	AKS, Azure Local/Arc, ACR	Conformant Kubernetes/containerd, self-hosted OCI registry
Data	Versioned schemas, checksums, open bulk format, relocatable catalog	ADLS/OneLake/Fabric with tested Iceberg/Parquet export	Customer object store/Ceph, Iceberg REST catalog, PostgreSQL where relational
Identity	Internal stable subject IDs; OIDC/OAuth claim mapping; no provider ID as business key	Entra ID, managed identities, PIM	Self-hosted OIDC provider, workload identity/SPIFFE
Authorization	Canonical decision input/output, obligations and policy test corpus	Entra/Azure RBAC and service-specific enforcement adapters	Customer PDP such as OPA-compatible enforcement
Keys	Customer-controlled roots, quorum recovery, crypto-agility, attestable release	Managed HSM/Key Vault or customer HSM	PKCS#11 HSM or customer-operated KMS
Evidence	Signed portable receipts, trace correlation, lineage and WORM retention	Azure Monitor/Sentinel/Purview adapters	OpenTelemetry collectors and customer-operated immutable store
Actions	Idempotency, approvals, deadlines, compensation and external receipt	Logic Apps/Durable Functions or native service adapters	Kubernetes-native or self-hosted workflow engine
Delivery	Signed OCI, SPDX, SLSA, offline mirror and revocation	Azure DevOps/GitHub plus ACR and Bicep/ARM	Self-hosted CI, registry, OpenTofu/Ansible/Helm
Operations	Same SLOs, runbook semantics and conformance evidence	Azure Policy/Monitor/Arc or disconnected Azure Local	GitOps, Prometheus-compatible monitoring and local policy enforcement
Exit	Full-domain restore with semantic and authorization equivalence	Exporter and target-independent backup	Importer and standalone bootstrap kit

These choices need not be configuration-identical. They must be behaviorally equivalent at the Dataheart contract.

Failure modes and counter-evidence

Failure mode	Counter-evidence or limitation	Required control
“Our data is in the EU, therefore sovereign”	The Commission separates data, jurisdictional, operational, technological and supply-chain sovereignty.	Score each dimension independently; record residual foreign dependencies.
Provider-managed encryption presented as customer control	The EDPB found transport and at-rest encryption insufficient when the importer holds keys or processing requires cleartext. EDPB, 18 June 2021	Customer-held roots, confidential processing where justified, legal transfer assessment, privileged-access controls.
Open files mistaken for portable data	Absolute paths, proprietary catalogs, hidden metadata, unsupported table features and IAM can prevent usable restoration.	Relocation test including catalog, snapshots, schemas, policies, lineage and queries.
Kubernetes mistaken for complete cloud portability	Storage classes, ingress, load balancers, GPU scheduling, identity, backup and managed databases leak provider semantics.	Restrict the portable kernel to conformance-tested APIs; inventory every profile escape hatch.
SBOM treated as proof of security	SBOMs can be stale, shallow, ambiguous, unsigned or omit dynamic/SaaS dependencies; CISA explicitly includes known unknowns and validation.	Generate at build and deploy time; sign, validate, diff and connect to vulnerability response.
SLSA provenance treated as code assurance	Provenance supports tracing and tamper resistance; it does not prove correct or vulnerability-free behavior.	Combine provenance with review, testing, scanning, runtime policy and incident response.
Source-visible product described as open	OSI rights include modification and redistribution. Source availability, escrow and audit rights are different properties.	Publish precise licence classifications and fork/continuity rights.
Confidential computing presented as absolute isolation	Hardware, firmware, verifier, reference values and key brokers remain trust dependencies; Azure CVMs also sacrifice recovery and mobility features.	Patch-aware appraisal policy, verifier separation, fallback recovery design and DoS assumptions.
Microsoft disconnected profile assumed to equal public Azure	Microsoft documents only a service subset, dedicated management capacity, hardware and eligibility constraints.	Maintain a published capability matrix and reject workloads outside the disconnected envelope.
Azure Arc treated as sovereign control-plane independence	Standard Arc agents connect outward to Azure.	Use disconnected Azure Local or a separate self-hosted control plane where loss of Azure must be tolerated.
One global support plane	Compromise can cross customers and bypass local sovereignty.	Per-customer trust roots and JIT delegation; no global decryption or action authority.
Backup stored under the primary identity/provider	A tenant compromise, sanction, billing dispute or provider failure can remove production and recovery simultaneously.	Immutable backup under separate identity, keys, account and preferably operator/provider.
Dual-profile feature drift	The less-used profile becomes nominally supported but operationally untested.	Every product increment must pass both profiles before release.
Self-hosting assumed automatically safer	Customer teams inherit patching, HSM, availability, physical security, dependency monitoring and on-call duties.	Operational-readiness gate and managed-support option that preserves customer authority.
Exit contract treated as exit capability	The Data Act does not require PaaS/SaaS reconstruction or perfect functional equivalence.	Technical exit SLO, tested importer and budget—not legal language alone.

Operational cost

The two profiles exchange different costs:

• Microsoft-native: lower control-plane and managed-service toil, but consumption/licensing charges, specialized disconnected hardware, provider-specific skills, service-subset constraints, and continued dependence on Microsoft servicing and product lifecycle.

• Self-hosted/open: avoids a hyperscaler control plane but requires capacity engineering, patch and vulnerability operations, multi-site resilience, registry and update infrastructure, HSM administration, observability, database maintenance, 24/7 incident response, and usually more idle capacity.

• Confidential computing: adds hardware scarcity, image qualification, firmware tracking, attestation operations, slower or restricted recovery, and sometimes higher storage or compute pricing.

• Dual profile: the largest durable cost is the conformance matrix—versions, storage drivers, identity systems, accelerators, network modes, disconnected updates, migrations and disaster recovery. Unbounded profile-specific features will turn this into two products.

Implications for Dataheart

Product definition

Dataheart should be sold and governed as a customer-owned capability with explicit conformance grades:

• P0 — exportable: documented bulk export.
• P1 — restorable: automated clean-site restore on the same profile.
• P2 — cross-profile portable: restore to the other profile with stated semantic exceptions.
• P3 — operator-independent: customer or third party can operate from offline artifacts and documentation.
• P4 — fork-continuable: load-bearing code and dependencies can legally and technically be rebuilt and maintained.

Do not use “fully open” unless P4 rights are present under OSI-approved licensing. “Fully self-hosted and open-standards based” is a legitimate but different promise.

Product and licensing boundary

A defensible strategy is:

• Publish interchange schemas, conformance fixtures, SDKs and reference adapters under an OSI-approved permissive licence.
• Keep customer data, policies, semantic models and extensions in customer-owned repositories.
• If the kernel remains proprietary, provide deployed-version source escrow, a perpetual continuity licence triggered by defined events, offline build instructions, dependency mirrors, signing transition, and periodic rebuild tests.
• Separate trademark and managed-service rights from runtime continuation rights.
• Record FDE contributions with explicit customer/generic classification and provenance.
• Avoid mandatory network licence checks in the self-hosted profile.

Architecture constraints

• No provider resource ID may be a primary business identifier.
• No platform policy representation may be the sole policy source.
• No vendor audit log may be the sole evidence store.
• No action may exist only as state inside a workflow provider.
• No supported capability may lack export/import and degradation semantics.
• Public-cloud loss must not silently convert an authorized action into an uncontrolled retry.
• Every adapter must declare data flows, privileges, jurisdiction, licences, dependencies and exit behavior.

Security model

Customer sovereignty requires separation of powers:

• The customer authorizes.
• Dataheart evaluates and orchestrates.
• Connectors execute narrowly scoped capabilities.
• The evidence plane records independently.
• Kugghuset supports through delegated access.
• A separate verifier can validate receipts, supply-chain provenance and attestation without trusting the running system.

Connections to other domains

• Financial options: portability is a real option. Its value depends on whether it can be exercised, how long exercise takes, and the loss/cost during exercise. Untested export is an option with unknown strike price.

• Safety cases: a sovereignty claim resembles a structured assurance case. Each claim needs evidence, assumptions, counter-evidence, expiry, and a responsible verifier.

• Constitutional design: customer-owned authorization, separate execution, and independent evidence mirror separation of powers. Combining all three in one vendor control plane creates a technically convenient but weak governance model.

• Product-line engineering: two deployment profiles should be managed as controlled variation points around one tested kernel. Ad-hoc conditionals produce divergent products.

• Digital preservation: long-term sovereignty requires fixity, documented formats, migrations, preserved renderers/interpreters and periodic restoration—not merely backups.

• Distributed systems: disconnection forces explicit decisions about stale policy, identity cache duration, action queues, conflict resolution, time sources, revocation and reconciliation.

Recommended experiments and conformance tests

Experiment	Pass criterion
Clean-room bootstrap	A new team deploys a signed release from offline media without Kugghuset infrastructure or internet access. All undeclared dependencies are failures.
Golden-domain migration	Move data, semantics, policies, identities, lineage, action state and evidence from Microsoft-native to open, and back. Declared queries and decisions produce identical results.
72-hour control-plane loss	Disconnect Azure/public vendor services. Local read/recommendation/action behavior follows documented degradation policy; reconnection creates no duplicate actions.
Policy equivalence corpus	Run thousands of allow, deny, obligation, delegation and revocation cases through both enforcement profiles. Zero unexplained decision differences.
Evidence verification	Verify a sampled action end-to-end offline using only exported receipts, public schemas and customer trust roots.
Data relocation	Move tables and objects to a different URI scheme and catalog. Snapshot history, schemas, decimals, timestamps, nulls, row counts and checksums remain valid.
Adversarial export	Include deleted objects, pending workflows, embeddings, prompts/templates, custom facets, derived metadata and failed actions. Identify every excluded artifact and its effect.
Supply-chain gate	Reject an unsigned image, mismatched digest, invalid SLSA provenance, stale SBOM and prohibited licence. Verification must also work offline.
Independent rebuild	Build the deployed release from source/escrow and compare reproducibility or explain every binary difference.
TEE negative tests	Refuse key release for stale firmware, wrong workload measurement, replayed evidence, expired endorsement, unapproved debugger and unavailable verifier.
Key-sovereignty test	Demonstrate that Microsoft, Kugghuset and infrastructure admins cannot decrypt without customer quorum; exercise rotation, revocation and recovery.
Cross-domain compromise	Compromise a simulated Kugghuset support identity. It must not authorize actions or access plaintext across customer domains.
Destructive recovery	Remove the production tenant/cluster and its identities. Restore elsewhere from separately administered immutable backup and registry.
Licence continuity drill	Replace or fork one critical dependency after a simulated relicensing/end-of-support event. Measure legal review, code changes and downtime.
FDE feature gate	A real customer-developed capability must pass both profiles, export/import, offline install, SBOM, evidence and policy-equivalence tests in the same release.
Exit economics	Record labor, elapsed time, transferred bytes, downtime, semantic exceptions, lost features and recurring destination cost. Contract against these numbers.

Sources

1. Regulation (EU) 2023/2854 — Data Act — adopted 13 December 2023; applicable since 12 September 2025.
2. Regulation (EU) 2024/2847 — Cyber Resilience Act — adopted 23 October 2024; reporting obligations apply 11 September 2026; full application 11 December 2027.
3. European Commission Cloud Sovereignty Framework — implementation guidance — 1 June 2026.
4. EDPB Recommendations 01/2020 on supplementary transfer measures — final 18 June 2021.
5. Open Source Initiative — Open Source Definition — last modified 16 February 2024.
6. OCI Image and Distribution Specifications 1.1 release — 13 March 2024; specifications released 15 February 2024.
7. Apache Iceberg Table Specification — versions 1–3 adopted; version 4 under development; accessed 23 August 2026.
8. SLSA 1.2 release — 24 November 2025.
9. SPDX specifications — SPDX 3.0 current; accessed 23 August 2026.
10. CISA Minimum Elements for an SBOM — August 2025.
11. IETF RFC 9334 — RATS Architecture — January 2023.
12. AMD-SB-3019 — SEV confidential-computing vulnerability — initially 3 February 2025; updated 10 June 2025.
13. Microsoft — disconnected operations for Azure Local — updated 14 May 2026.
14. Microsoft — Azure Arc-enabled Kubernetes — current documentation accessed 23 August 2026.
15. Microsoft — Azure confidential VMs — updated 5 February 2026.

Resonansia graph payload

{
  "entities": [
    {
      "id": "dataheart:portable-kernel",
      "type": "architecture-component",
      "name": "Portable Dataheart kernel",
      "description": "Vendor-neutral semantic, authorization-decision, evidence, action and export contracts implemented through deployment adapters.",
      "status": "hypothesis",
      "valid_as_of": "2026-08-23",
      "tags": ["portability", "semantics", "authorization", "actions"],
      "source_urls": [
        "https://eur-lex.europa.eu/eli/reg/2023/2854",
        "https://opencontainers.org/posts/blog/2024-03-13-image-and-distribution-1-1/"
      ]
    },
    {
      "id": "dataheart:customer-security-domain",
      "type": "security-boundary",
      "name": "Customer-owned security domain",
      "description": "Customer-controlled identities, policies, keys, evidence, backups and deployment trust roots with revocable support delegation.",
      "status": "hypothesis",
      "valid_as_of": "2026-08-23",
      "tags": ["sovereignty", "key-custody", "identity", "separation-of-duties"],
      "source_urls": [
        "https://commission.europa.eu/document/download/2ad80a48-166f-4c77-a513-80c53ca2a128_en?filename=Cloud+Sovereignty+Framework+-+Implementation+guidance.pdf",
        "https://www.edpb.europa.eu/documents/recommendation/recommendations-012020-on-measures-that-supplement-transfer-tools-to_en"
      ]
    },
    {
      "id": "dataheart:microsoft-native-profile",
      "type": "deployment-profile",
      "name": "Microsoft-native deployment profile",
      "description": "Deployment using Microsoft identity, compute, data, management and security services, including connected Azure or eligible disconnected Azure Local.",
      "status": "vendor-claim",
      "valid_as_of": "2026-08-23",
      "tags": ["microsoft", "azure", "azure-local", "arc"],
      "source_urls": [
        "https://learn.microsoft.com/en-us/azure/azure-sovereign-clouds/private/azure-local/disconnected-operations-overview",
        "https://learn.microsoft.com/en-us/azure/azure-arc/kubernetes/overview"
      ]
    },
    {
      "id": "dataheart:self-hosted-open-profile",
      "type": "deployment-profile",
      "name": "Self-hosted open profile",
      "description": "Customer-operated profile with no required Microsoft or public-cloud control plane and with declared open-source or source-available licensing.",
      "status": "hypothesis",
      "valid_as_of": "2026-08-23",
      "tags": ["self-hosted", "offline", "open-source", "open-standards"],
      "source_urls": [
        "https://opensource.org/osd",
        "https://spdx.dev/use/specifications/"
      ]
    },
    {
      "id": "dataheart:open-product-boundary",
      "type": "design-principle",
      "name": "Open product boundary",
      "description": "Versioned protocol, public schema, stable identifiers, compatibility rules, bulk export and independent conformance tests.",
      "status": "established",
      "valid_as_of": "2026-08-23",
      "tags": ["api", "interoperability", "extensions", "exit"],
      "source_urls": [
        "https://eur-lex.europa.eu/eli/reg/2023/2854",
        "https://opencontainers.org/posts/blog/2024-03-13-image-and-distribution-1-1/"
      ]
    },
    {
      "id": "dataheart:portable-evidence-envelope",
      "type": "data-contract",
      "name": "Portable evidence envelope",
      "description": "Signed action and recommendation receipt carrying identity, policy, lineage, artifact and execution evidence.",
      "status": "hypothesis",
      "valid_as_of": "2026-08-23",
      "tags": ["evidence", "audit", "receipts", "provenance"],
      "source_urls": [
        "https://slsa.dev/blog/2025/11/announce-slsa-v1.2",
        "https://www.rfc-editor.org/rfc/rfc9334.html"
      ]
    },
    {
      "id": "dataheart:supply-chain-evidence",
      "type": "assurance-mechanism",
      "name": "Supply-chain evidence",
      "description": "Signed SBOM, source and build provenance, licence declarations and vulnerability-response material.",
      "status": "established",
      "valid_as_of": "2026-08-23",
      "tags": ["sbom", "slsa", "spdx", "cra"],
      "source_urls": [
        "https://slsa.dev/blog/2025/11/announce-slsa-v1.2",
        "https://spdx.dev/use/specifications/",
        "https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf",
        "https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng"
      ]
    },
    {
      "id": "dataheart:confidential-compute-zone",
      "type": "security-pattern",
      "name": "Attestation-bound confidential compute zone",
      "description": "High-sensitivity execution zone where customer key release depends on fresh attestation and customer appraisal policy.",
      "status": "emerging",
      "valid_as_of": "2026-08-23",
      "tags": ["confidential-computing", "attestation", "tee", "key-release"],
      "source_urls": [
        "https://www.rfc-editor.org/rfc/rfc9334.html",
        "https://learn.microsoft.com/en-us/azure/confidential-computing/confidential-vm-overview",
        "https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3019.html"
      ]
    },
    {
      "id": "dataheart:exit-conformance-suite",
      "type": "assurance-mechanism",
      "name": "Exit and cross-profile conformance suite",
      "description": "Automated tests for clean-site bootstrap, cross-profile migration, policy equivalence, evidence verification and disaster recovery.",
      "status": "hypothesis",
      "valid_as_of": "2026-08-23",
      "tags": ["exit", "testing", "disaster-recovery", "conformance"],
      "source_urls": [
        "https://eur-lex.europa.eu/eli/reg/2023/2854",
        "https://commission.europa.eu/document/download/2ad80a48-166f-4c77-a513-80c53ca2a128_en?filename=Cloud+Sovereignty+Framework+-+Implementation+guidance.pdf"
      ]
    },
    {
      "id": "dataheart:eu-cloud-switching-regime",
      "type": "regulatory-regime",
      "name": "EU cloud switching regime",
      "description": "Data Act requirements for contractual exit, export, open interfaces, continuity, switching assistance and withdrawal of switching charges.",
      "status": "established",
      "valid_as_of": "2026-08-23",
      "tags": ["eu", "data-act", "cloud-switching", "interoperability"],
      "source_urls": [
        "https://eur-lex.europa.eu/eli/reg/2023/2854"
      ]
    }
  ],
  "relations": [
    {
      "id": "dataheart:portable-kernel-uses-open-boundaries",
      "from": "dataheart:portable-kernel",
      "predicate": "uses",
      "to": "dataheart:open-product-boundary",
      "description": "The portable kernel is exposed only through versioned, independently testable product boundaries.",
      "confidence": 0.95,
      "status": "hypothesis",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://eur-lex.europa.eu/eli/reg/2023/2854"
      ]
    },
    {
      "id": "dataheart:microsoft-profile-implements-portable-kernel",
      "from": "dataheart:microsoft-native-profile",
      "predicate": "implements",
      "to": "dataheart:portable-kernel",
      "description": "Microsoft services implement profile adapters without defining the canonical Dataheart semantics.",
      "confidence": 0.88,
      "status": "hypothesis",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://learn.microsoft.com/en-us/azure/azure-arc/kubernetes/overview"
      ]
    },
    {
      "id": "dataheart:open-profile-implements-portable-kernel",
      "from": "dataheart:self-hosted-open-profile",
      "predicate": "implements",
      "to": "dataheart:portable-kernel",
      "description": "The self-hosted profile implements the same contracts without a Microsoft or public-cloud dependency.",
      "confidence": 0.88,
      "status": "hypothesis",
      "valid_as_of": "2026-08-23",
      "source_urls": []
    },
    {
      "id": "dataheart:security-domain-governs-microsoft-profile",
      "from": "dataheart:customer-security-domain",
      "predicate": "governs",
      "to": "dataheart:microsoft-native-profile",
      "description": "Customer identity, key, policy and evidence authority remains above the Microsoft implementation.",
      "confidence": 0.9,
      "status": "hypothesis",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://commission.europa.eu/document/download/2ad80a48-166f-4c77-a513-80c53ca2a128_en?filename=Cloud+Sovereignty+Framework+-+Implementation+guidance.pdf"
      ]
    },
    {
      "id": "dataheart:security-domain-governs-open-profile",
      "from": "dataheart:customer-security-domain",
      "predicate": "governs",
      "to": "dataheart:self-hosted-open-profile",
      "description": "Self-hosting does not remove the need for explicit customer key, policy, identity and recovery governance.",
      "confidence": 0.94,
      "status": "hypothesis",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://commission.europa.eu/document/download/2ad80a48-166f-4c77-a513-80c53ca2a128_en?filename=Cloud+Sovereignty+Framework+-+Implementation+guidance.pdf"
      ]
    },
    {
      "id": "dataheart:portable-kernel-emits-evidence-envelope",
      "from": "dataheart:portable-kernel",
      "predicate": "emits",
      "to": "dataheart:portable-evidence-envelope",
      "description": "Every recommendation and controlled action creates a profile-independent signed receipt.",
      "confidence": 0.9,
      "status": "hypothesis",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://slsa.dev/blog/2025/11/announce-slsa-v1.2"
      ]
    },
    {
      "id": "dataheart:supply-chain-evidence-attaches-to-artifacts",
      "from": "dataheart:supply-chain-evidence",
      "predicate": "attaches-to",
      "to": "dataheart:portable-kernel",
      "description": "SBOM and provenance accompany every shipped kernel and adapter artifact.",
      "confidence": 0.96,
      "status": "established",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://opencontainers.org/posts/blog/2024-03-13-image-and-distribution-1-1/",
        "https://spdx.dev/use/specifications/"
      ]
    },
    {
      "id": "dataheart:confidential-zone-controlled-by-security-domain",
      "from": "dataheart:customer-security-domain",
      "predicate": "controls-key-release-for",
      "to": "dataheart:confidential-compute-zone",
      "description": "Customer appraisal policy and trust roots determine whether confidential workloads receive decryption keys.",
      "confidence": 0.92,
      "status": "emerging",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://www.rfc-editor.org/rfc/rfc9334.html"
      ]
    },
    {
      "id": "dataheart:exit-suite-tests-microsoft-profile",
      "from": "dataheart:exit-conformance-suite",
      "predicate": "tests",
      "to": "dataheart:microsoft-native-profile",
      "description": "The suite verifies export, disconnection, restoration and cross-profile behavior.",
      "confidence": 0.95,
      "status": "hypothesis",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://eur-lex.europa.eu/eli/reg/2023/2854"
      ]
    },
    {
      "id": "dataheart:exit-suite-tests-open-profile",
      "from": "dataheart:exit-conformance-suite",
      "predicate": "tests",
      "to": "dataheart:self-hosted-open-profile",
      "description": "The suite verifies offline bootstrap, independent operation, restoration and cross-profile behavior.",
      "confidence": 0.95,
      "status": "hypothesis",
      "valid_as_of": "2026-08-23",
      "source_urls": []
    },
    {
      "id": "dataheart:eu-regime-requires-open-boundaries",
      "from": "dataheart:eu-cloud-switching-regime",
      "predicate": "motivates",
      "to": "dataheart:open-product-boundary",
      "description": "The Data Act establishes contractual and technical switching expectations but does not itself guarantee full application portability.",
      "confidence": 0.98,
      "status": "established",
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://eur-lex.europa.eu/eli/reg/2023/2854"
      ]
    }
  ],
  "claims": [
    {
      "id": "dataheart:claim-portability-is-tested-capability",
      "statement": "Dataheart is portable only when a complete customer domain can be restored under another profile or operator with preserved semantics, authorization, evidence and action state inside measured limits.",
      "confidence": 0.95,
      "evidence_for": [
        "The Data Act distinguishes export, transformation, upload and functional equivalence.",
        "Open artifact and table formats address only parts of the operating capability.",
        "The Commission framework includes operational and technological autonomy."
      ],
      "evidence_against": [
        "Full equivalence can be economically disproportionate for provider-specific managed services.",
        "Some platform capabilities may require declared degradation rather than equivalence."
      ],
      "implications": [
        "Make the conformance suite part of the product definition.",
        "Publish capability-specific portability grades and exceptions."
      ],
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://eur-lex.europa.eu/eli/reg/2023/2854",
        "https://commission.europa.eu/document/download/2ad80a48-166f-4c77-a513-80c53ca2a128_en?filename=Cloud+Sovereignty+Framework+-+Implementation+guidance.pdf"
      ]
    },
    {
      "id": "dataheart:claim-residency-is-not-sovereignty",
      "statement": "EU data residency alone does not establish operational, jurisdictional, technological or supply-chain sovereignty.",
      "confidence": 0.99,
      "evidence_for": [
        "The Commission framework defines eight separate sovereignty objectives and four assurance levels.",
        "The EDPB identifies cases where encryption does not solve third-country access risks."
      ],
      "evidence_against": [
        "Residency remains a useful and sometimes mandatory control.",
        "Contractual and organizational measures can reduce risks even where full sovereignty is unavailable."
      ],
      "implications": [
        "Assess sovereignty as a vector.",
        "Avoid marketing claims based solely on region selection."
      ],
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://commission.europa.eu/document/download/2ad80a48-166f-4c77-a513-80c53ca2a128_en?filename=Cloud+Sovereignty+Framework+-+Implementation+guidance.pdf",
        "https://www.edpb.europa.eu/documents/recommendation/recommendations-012020-on-measures-that-supplement-transfer-tools-to_en"
      ]
    },
    {
      "id": "dataheart:claim-open-formats-are-necessary-not-sufficient",
      "statement": "OCI images and open table formats are necessary portability mechanisms but do not preserve identity, policy, network, catalog, workflow and operational semantics by themselves.",
      "confidence": 0.97,
      "evidence_for": [
        "OCI specifies artifact construction and distribution rather than complete platform state.",
        "Iceberg documents version and path compatibility concerns.",
        "The Data Act separately requires interfaces, metadata, assistance and continuity."
      ],
      "evidence_against": [
        "Standardized packaging substantially lowers migration cost.",
        "A deliberately constrained application can achieve high portability with these standards."
      ],
      "implications": [
        "Add semantic, policy, evidence and action export contracts.",
        "Test relocated state rather than copied files."
      ],
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://opencontainers.org/posts/blog/2024-03-13-image-and-distribution-1-1/",
        "https://iceberg.apache.org/spec/",
        "https://eur-lex.europa.eu/eli/reg/2023/2854"
      ]
    },
    {
      "id": "dataheart:claim-source-available-is-not-open-source",
      "statement": "Source availability, audit access and escrow do not constitute open source unless the licence also provides the required use, modification and redistribution rights.",
      "confidence": 0.99,
      "evidence_for": [
        "The OSI definition explicitly requires modification and derived-work distribution rights."
      ],
      "evidence_against": [
        "A strong customer continuity licence can provide practical sovereignty without public redistribution rights.",
        "Open-source licensing alone does not provide maintainers, documentation or reproducible builds."
      ],
      "implications": [
        "Use precise product-profile terminology.",
        "Test legal and technical continuity separately."
      ],
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://opensource.org/osd"
      ]
    },
    {
      "id": "dataheart:claim-sbom-and-slsa-are-foundational-not-conclusive",
      "statement": "SBOM and SLSA evidence improve traceability and tamper resistance but do not prove that deployed software is complete, vulnerability-free or correctly authorized.",
      "confidence": 0.98,
      "evidence_for": [
        "CISA includes coverage, validation and known unknowns as explicit SBOM concerns.",
        "SLSA defines source and build guarantees rather than behavioral correctness."
      ],
      "evidence_against": [
        "High-quality signed SBOMs and provenance substantially improve response and admission control."
      ],
      "implications": [
        "Combine evidence with runtime policy, testing, vulnerability response and deployment inventory."
      ],
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf",
        "https://slsa.dev/blog/2025/11/announce-slsa-v1.2",
        "https://spdx.dev/use/specifications/"
      ]
    },
    {
      "id": "dataheart:claim-confidential-computing-is-supplementary",
      "statement": "Confidential computing can reduce trust in hosts and operators but does not eliminate firmware, verifier, availability, jurisdiction or operational dependencies.",
      "confidence": 0.97,
      "evidence_for": [
        "RATS makes verifier, reference values, endorsements and appraisal policy explicit trust components.",
        "AMD-SB-3019 required firmware and microcode mitigation.",
        "Azure documents recovery, mobility, regional and operating-system limitations."
      ],
      "evidence_against": [
        "Correctly implemented confidential VMs materially reduce host and hypervisor exposure.",
        "Attestation-bound key release supports strong high-sensitivity designs."
      ],
      "implications": [
        "Use confidential computing only in classified zones.",
        "Make customer appraisal policy, patch state and recovery part of conformance."
      ],
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://www.rfc-editor.org/rfc/rfc9334.html",
        "https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3019.html",
        "https://learn.microsoft.com/en-us/azure/confidential-computing/confidential-vm-overview"
      ]
    },
    {
      "id": "dataheart:claim-dual-profile-needs-continuous-conformance",
      "statement": "A Microsoft-native and self-hosted/open profile will diverge unless every product change is gated by shared behavioral, security, export and recovery tests.",
      "confidence": 0.94,
      "evidence_for": [
        "The Microsoft disconnected environment provides only a documented subset of capabilities.",
        "Platform-specific identity, storage and management semantics differ.",
        "Standards define components but not complete profile equivalence."
      ],
      "evidence_against": [
        "Strictly limiting the common feature envelope may reduce testing demands.",
        "Some customers may accept profile-specific capabilities and declared non-portability."
      ],
      "implications": [
        "Treat profiles as product-line variation points.",
        "Require portability classification and tests for every new capability."
      ],
      "valid_as_of": "2026-08-23",
      "source_urls": [
        "https://learn.microsoft.com/en-us/azure/azure-sovereign-clouds/private/azure-local/disconnected-operations-overview",
        "https://learn.microsoft.com/en-us/azure/azure-arc/kubernetes/overview"
      ]
    }
  ]
}