Trust and evidence chains

Executive thesis

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:

1. Stable asset, version, and business identifiers.
2. Observed runtime lineage at run, dataset, and field level.
3. Versioned quality rules and their immutable observations.
4. Reproducible metric definitions plus pinned execution context.
5. Signed evidence envelopes binding claims to exact subjects.
6. Access-aware UX that distinguishes freshness, coverage, validity, verification, and approval.

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:

• Established: standardized or repeatedly deployed practice.
• Emerging: useful, active, but without settled interoperability or complete coverage.
• Hypothesis: promising transfer or Dataheart-specific design requiring validation.
• Vendor claim: capability described by the product owner; coverage must be independently tested.

State of the art 2024-2026

Status	Development	Assessment
Established	W3C DCAT 3 became a Recommendation on 2024-08-22, adding stronger versioning, dataset-series, catalog, and provenance patterns. Its quality guidance composes DQV and PROV rather than defining a quality engine.	Good interchange foundation for catalog and version metadata, not runtime evidence.
Established	PROV-O’s Entity–Activity–Agent model remains the strongest vendor-neutral conceptual base for derivation, responsibility, plans, revisions, and provenance bundles. DQV models dimensions, metrics, measurements, policies, annotations, and certificates.	These define meaning but neither automatically captures lineage nor decides whether data is fit for a particular use. DQV explicitly treats quality as contextual.
Emerging-to-established	OpenLineage 1.52, released 2026-07-23, provides a widely implemented event/facet model. Its current facets represent direct and indirect column dependencies, masking, dataset versions, statistics, and quality assertions with separate success and severity.	Best current open wire model for operational lineage. Coverage remains instrumentation-dependent; optional facets and custom extensions can fragment semantics.
Emerging	Open Data Contract Standard 3.1, released 2025-12-08 under LF AI & Data, combines schema, ownership, service levels, and quality declarations in machine-readable YAML/JSON Schema.	Promising portability layer for quality-as-code, but it is not yet a universal executable rule language or proof format.
Emerging	Metrics-as-code is mature inside products and projects. MetricFlow compiles versioned metric definitions into engine-specific SQL and became Apache-2.0 licensed in late 2025. Open Semantic Interchange aims at cross-tool semantic exchange.	No settled vendor-neutral metric execution standard exists. As of 2026-08-23, OSI has no published release, so interoperability claims remain prospective.
Vendor claim	Microsoft Purview Unified Catalog offers profiling, six quality dimensions, column rules, asset-level freshness, scan history, alerts, and rolled-up scores. Fabric exposes workspace lineage and impact views.	Useful Microsoft-native substrate. Documented constraints include DGPU-based scan cost, a 200-rule-per-asset limit, connector-specific coverage, workspace visibility boundaries, and lineage gaps for manually authored queries.
Established primitive; hypothesis in this domain	W3C Data Integrity and in-toto-style statements/envelopes separate subject, predicate, signature, and verification.	Cryptographic reuse for data and metric evidence is technically sound, but sector profiles and operational conventions are still missing. A valid signature proves integrity and signer control—not that the assertion is true.
Established correlation, not evidence	W3C Trace Context carries request correlation across services.	A trace identifier can join UX actions, queries, lineage events, and attestations, but it is neither authenticated evidence nor safe storage for sensitive business context.
Established legal requirement within scope	The EU AI Act requires data governance and automatically generated logs for covered high-risk AI systems.	This creates demand for traceability and retention, but does not prescribe PROV, OpenLineage, signed attestations, or a universal evidence architecture.

Load-bearing concepts

1. Distinguish artifact types

Dataheart should never collapse the following into one generic “evidence” record:

• Declaration: schema, contract, metric definition, quality policy.
• Observation: row count, watermark, null ratio, test result.
• Provenance assertion: input X was used by run Y to generate output Z.
• Attestation: a named issuer signs a claim about a subject digest.
• Verification result: a verifier checked signature, policy, time, revocation, and subject binding.
• Authorization decision: a policy engine allowed a principal to see or act on the subject.
• Human annotation: approval, exception, dispute, or contextual explanation.

A signature over a quality observation must not silently convert the observation into objective truth.

2. Quality as code

The portable invariant is not a particular testing tool. It is a versioned quality definition containing:

• Stable rule identifier and definition version.
• Dataset/field and version scope.
• Dimension and business purpose.
• Executable expression or referenced implementation.
• Expected threshold and severity.
• Sampling/filter policy.
• Evaluation clock and window.
• Owner, exception policy, and expiry.
• Engine/version used.
• Immutable result with numerator, denominator, actual value, and error state.

Definitions should be reviewable in Git and runnable in CI, pre-publication gates, and continuous production scans. The same rule should be exportable to ODCS/DQV-compatible metadata even if Purview, Great Expectations, Soda, Deequ, or another engine executes it.

3. Freshness is multi-clock

“Last modified recently” is insufficient. Dataheart needs at least:

• Source event time.
• Source availability time.
• Ingestion time.
• Transformation completion time.
• Publication time.
• Observation time.
• Consumer query time.

A freshness assertion must state which clock, partition, watermark, and lateness allowance it uses. Backfills can make technical modification time recent while business data remains stale; late events can make a healthy stream look temporarily incomplete.

4. Lineage needs several dimensions

Maintain distinctions between:

• Declared/design lineage and observed runtime lineage.
• Dataset-level and field-level lineage.
• Direct value transformations and indirect dependencies through filters, joins, grouping, ordering, conditions, and windows.
• Logical assets and physical versions/snapshots.
• Transformation definition and individual run.
• Complete, partial, inferred, manually asserted, and unknown coverage.

Unknown lineage must remain an explicit state. Inventing an edge is worse than showing a gap.

5. Reproducible metric verification

A metric value is replayable only if its verification capsule binds:

• Metric and semantic-model definitions.
• Definition commit/digest.
• Compiled SQL or logical plan digest.
• Parameters, filters, dimensions, time range, and requested grain.
• Time zone, calendar, currency, rounding, and null semantics.
• Engine, adapter, and relevant configuration versions.
• Exact input snapshot IDs or content digests.
• Query principal and authorization-decision reference.
• Output schema, row count, value digest, and tolerances.
• Runtime and evidence-envelope identifiers.

Matching metric names or source SQL is not reproducibility. Without pinned snapshots and execution semantics, recomputation is only a new observation.

6. Evidence envelopes

A Dataheart envelope should contain an immutable statement with:

• Subject identifiers and digests.
• Predicate type and schema version.
• Issuer/workload identity.
• Creation, validity, and observation times.
• Input subjects and dependency digests.
• Run, trace, contract, metric, and quality references.
• Signature/proof and key identifier.
• Verification policy and result.
• Optional transparency-log inclusion proof.

Using in-toto/DSSE or W3C Data Integrity as the cryptographic layer avoids inventing signature semantics. A Dataheart-specific predicate is still required for datasets, metrics, quality observations, and controlled actions.

7. Trust UX

Avoid one green “trusted” badge. Present independent axes:

• Fresh: relevant freshness SLO passed.
• Quality checked: named rules ran on the displayed version.
• Lineage covered: coverage and unknown segments disclosed.
• Verified: signature and subject digest validated.
• Reproducible: replay test passed under stated tolerances.
• Approved: current authorization or human approval exists.
• Disputed/excepted: an active exception or challenge exists.

Each status should open the exact evidence, scope, observation time, issuer, and limitations. Raw evidence must remain authorization-filtered because lineage graphs disclose schemas, relationships, volumes, systems, and potentially sensitive business operations.

Reference patterns

Vendor-neutral invariant	Microsoft-native profile	Self-hosted/open profile
Canonical assets, versions, contracts, and business identifiers	Purview Unified Catalog/Data Map; Fabric/OneLake identifiers	DCAT 3 registry; ODCS contracts; customer-owned catalog
Observed run/dataset/field lineage	Fabric and Purview lineage plus custom native ingestion where documented capture is incomplete	OpenLineage events into Marquez, OpenMetadata, DataHub, or a customer graph
Versioned rule definitions and immutable observations	Purview Data Quality rules/scans; pipeline-native validation for unsupported cases	Great Expectations, Soda, Deequ, SQL tests, or equivalent; emit normalized OpenLineage/DQV observations
Metric definitions and verification capsules	Fabric semantic models or Microsoft-native metric definitions, exported into Dataheart’s canonical representation	MetricFlow or another compiler; OSI adapter only after its conformance stabilizes
Immutable input/output references	OneLake/Delta versions, Fabric run identifiers, content digests where necessary	Iceberg/Delta snapshots, object versions, Kafka offsets, content digests
Cross-surface correlation	Azure-native monitoring with W3C Trace Context	OpenTelemetry/W3C Trace Context
Signed evidence envelope	Microsoft-managed workload identities and native key/HSM services	in-toto/DSSE or W3C Data Integrity with customer KMS/HSM and optional transparency log
Customer ownership	Exportable canonical graph and append-only evidence store in the customer tenant	Self-hosted graph/object store with the same schema

Recommended runtime pattern:

1. Emit lineage and observations at the execution boundary.
2. Preserve original events unchanged.
3. Normalize into Dataheart’s canonical graph.
4. Calculate coverage separately from quality.
5. Create signed envelopes at meaningful publication/action boundaries.
6. Expose a stable, opaque evidence_ref across every authorized surface.
7. Reverify proof, subject, policy, and freshness when evidence is consumed.

Failure modes and counter-evidence

Coverage illusion

Automatic lineage frequently breaks at dynamic SQL, UDFs, stored procedures, notebooks, manually authored mashups, path-based tables, renamed assets, unsupported connectors, rollback, and cross-workspace boundaries. Fabric explicitly limits some views to a workspace plus one upstream level and does not guarantee certain manually authored connections.

Mitigation: calculate lineage coverage against expected execution inventory; label edges observed, inferred, or manual; expose missing emitters and unsupported constructs.

Freshness theatre

File modification time, pipeline success, and catalog scan time can all be green while the latest valid business event is old.

Mitigation: define freshness against source event watermarks and publish both technical and business freshness.

Aggregate-score deception

An arithmetic quality score can hide a failed critical rule behind many trivial passes. Sampling can miss rare but severe defects. Rules validate what was encoded, not all business correctness.

Mitigation: keep rule results, severities, denominators, and blocking consequences visible; never allow an aggregate score to override a critical failure.

Lineage poisoning

A compromised or buggy emitter can publish false edges. Manual lineage can be stale. Duplicate identifiers can stitch unrelated assets together.

Mitigation: authenticate emitters, namespace identifiers, sign batches, reconcile output metadata against the storage system, and retain contradictory assertions rather than overwriting history.

Evidence authenticity versus truth

A valid signature proves that the signed bytes have not changed and that the signer controlled the key. It does not prove that:

• The source data was correct.
• The signer was uncompromised.
• The predicate was complete.
• The test was appropriate.
• The issuer had authority.
• Evidence was not selectively omitted.

Mitigation: independent observation, separation of issuer and verifier, completeness checks, key rotation/revocation, and explicit assurance levels.

Replay and semantic drift

A valid old metric envelope can be replayed after the metric definition, policy, or source has changed. Warehouse upgrades, nondeterministic SQL, floating-point behavior, locale, and time-zone database changes can alter results.

Mitigation: bind definition and engine versions, include validity windows and nonces where appropriate, and test exact or tolerance-based replay.

Trace-context confusion

A trace ID is correlation metadata, not authorization or cryptographic provenance. W3C Trace Context also warns against inserting identifiable or sensitive information.

Mitigation: propagate opaque references only; validate authorization and retrieve the signed evidence out of band.

Evidence-store leakage

A provenance graph can reveal customer names, sensitive columns, transaction volumes, operating schedules, system topology, and cross-domain dependencies.

Mitigation: authorization-aware graph traversal, field redaction, tenant isolation, metadata minimization, purpose-specific views, and audit of evidence access.

Operational cost

Major cost drivers are:

• Full-table quality scans and cross-table checks.
• Column-level edge cardinality.
• Per-run event and evidence retention.
• Reconciliation and replay compute.
• Key/HSM operations.
• Indexing large temporal graphs.
• Authorization checks during recursive traversal.

Purview explicitly bills quality work in governance processing units and limits scans to 200 rules per asset. Open infrastructure avoids service lock-in but transfers cost to engineering, scaling, upgrades, and on-call ownership.

Lock-in

Lock-in occurs through proprietary asset identifiers, scanner-specific coverage, quality-score formulas, rule DSLs, semantic-model syntax, undocumented query compilation, and non-exportable evidence history.

MetricFlow’s current Apache-2.0 license reduces code lock-in, but its dependency on dbt projects and OSI’s lack of a released specification leave semantic interchange immature. Dataheart should therefore store canonical definitions and compiled artifacts, not only references to a vendor’s semantic API.

Implications for Dataheart

1. Build a trust kernel, not a catalog wrapper.Core entities should include AssetVersion, TransformationRun, FieldDependency, QualityRule, QualityObservation, MetricDefinition, MetricResult, EvidenceEnvelope, AuthorizationDecisionRef, and VerificationResult.

2. Make the canonical model customer-owned.Store original events plus a normalized, versioned representation. Every normalized fact must retain its source event, adapter version, and normalization rule.

3. Use standards at their natural boundaries.DCAT/DQV/PROV for exchange semantics; ODCS for declared contracts; OpenLineage for runtime events; W3C Trace Context for correlation; in-toto/DSSE or Data Integrity for cryptographic proof.

4. Keep Microsoft and open profiles behaviorally conformant.They may use different storage, scanners, testing engines, metric compilers, keys, and graph databases. Their exported canonical evidence and verification behavior should be equivalent.

5. Make coverage first-class.Every answer should expose whether evidence is observed, inferred, manual, partial, stale, or unavailable.

6. Attach evidence to actions.Recommendations and controlled actions should reference the metric result, quality observations, lineage slice, authorization decision, and evidence verification used at decision time.

7. Do not put sensitive evidence into propagation headers.Carry only opaque trace and evidence references; retrieve details through an authorized service.

8. Productize forward-deployed work.Kugghuset engineers should deliver adapters as reusable conformance packs with golden fixtures, coverage reports, and exit criteria—not customer-specific mutations of the canonical model.

Connections to other domains

• Software supply-chain security: in-toto’s subject–predicate–envelope separation transfers well to data artifacts. The major difference is that datasets are often mutable, privacy-sensitive, and too large to hash naïvely.
• Scientific reproducibility: a metric capsule resembles a research compendium: inputs, code, parameters, environment, output, and uncertainty must be preserved together.
• SRE: freshness and quality should be managed as SLOs with error budgets, burn rates, and controlled escalation rather than binary dashboard colors.
• Accounting and internal control: assertion, evidence, approval, exception, and independent verification should be distinct records with segregation of duties.
• Event sourcing: original lineage and evidence events should be append-only; corrected interpretations become new assertions rather than destructive rewrites.
• Zero trust: possession of an evidence reference confers no right to view it. Every traversal and proof retrieval requires current authorization.
• Transparency systems: append-only logs can expose equivocation or retrospective alteration, but introduce retention, privacy, and operational availability problems.
• AI governance: the AI Act’s data-governance and logging requirements increase the value of traceable evidence, while leaving implementation architecture open.

Recommended experiments and conformance tests

Experiment	Pass criterion
Cross-profile golden pipeline	Microsoft-native and self-hosted executions normalize to the same canonical assets, runs, field dependencies, observations, and envelopes except for explicitly allowed profile metadata.
SQL/compute lineage torture corpus	Joins, filters, windows, aggregation, UDFs, dynamic SQL, notebooks, streaming, incremental runs, rename, rollback, and failure paths produce correct lineage or explicit unknown; no invented edge is accepted.
Freshness clock test	Backfill, late arrival, clock skew, and stale source scenarios keep business freshness separate from pipeline and storage modification times.
Metric replay	A stored capsule reproduces the same result on the same snapshot, or falls within a declared tolerance; missing snapshot or engine context makes the result non-certified.
Cross-engine metric differential	Run canonical metric fixtures through Microsoft-native and open compilers. Any difference in joins, nulls, dates, rounding, currency, or grain is detected and explained.
Evidence tamper test	Changing a subject digest, input, definition, quality result, timestamp, or predicate causes verification failure. Replayed, expired, or revoked evidence is rejected according to policy.
Emitter poisoning test	Events from an unauthorized producer, colliding namespace, or inconsistent storage version are quarantined rather than merged.
Authorization-leak test	Unauthorized users cannot infer asset names, fields, volumes, existence, graph degree, or failure details through APIs, search, errors, or timing.
Collector outage test	A 24-hour metadata-backend outage does not lose source events; backpressure and replay remain within the declared recovery objective. Fail-open/fail-closed behavior is explicit per evidence class.
Coverage honesty test	Disabling one connector or instrumentation hook visibly lowers coverage. No “verified lineage” state remains green merely because the stored subgraph is internally consistent.
Cost/cardinality test	Publish compute, storage, and p95 traversal cost per million runs, million field edges, quality-rule scan, and signature verification. Enforce profile-specific budgets.
Trust-UX study	Users correctly distinguish fresh, quality-checked, lineage-covered, verified, reproducible, approved, and disputed states in at least 90% of decision tasks.
Contract portability	ODCS/DQV/DCAT export–import preserves all invariant fields. Unsupported fields remain explicit extensions rather than being silently dropped.
Retention and erasure	Subject data and sensitive graph metadata can be deleted or redacted under policy without leaving linkable personal information in signatures, indexes, logs, or cached trust views.

Sources

1. W3C PROV-O Recommendation — 2013-04-30.
2. W3C Data Quality Vocabulary — 2016-08-30.
3. W3C DCAT Version 3 — Recommendation, 2024-08-22.
4. OpenLineage 1.52.0 release — 2026-07-23.
5. OpenLineage Column-Level Lineage Facet — specification accessed 2026-08-23.
6. OpenLineage Data Quality Assertions Facet — specification accessed 2026-08-23.
7. Open Data Contract Standard 3.1 — release 2025-12-08.
8. Open Semantic Interchange repository — no published releases as of 2026-08-23.
9. MetricFlow repository and licensing history — Apache-2.0 from v0.209.0; accessed 2026-08-23.
10. Microsoft Purview Unified Catalog Data Quality — updated 2026-05-15.
11. Microsoft Fabric lineage — updated 2026-04-17.
12. in-toto Attestation Envelope specification — current v1 specification accessed 2026-08-23.
13. W3C Verifiable Credential Data Integrity 1.0 — Recommendation, 2025-05-15.
14. W3C Trace Context — Recommendation, 2021-11-23.
15. Regulation (EU) 2024/1689, Artificial Intelligence Act — Official Journal, 2024-07-12.