Quality, Provenance, and Trust: Why Knowledge Graphs Fail Audits

Knowledge Graph Practitioner’s Guide: Overview | Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7 | Part 8 | Part 9 | Part 10 | Part 11a | Part 11b | Part 11c | Appendix A | Appendix B | Appendix C | Part 12

The Five-Minute Audit That Took Three Weeks

A regional commercial bank we will call Cornerstone Trust, a composite drawn from publicly documented BCBS 239 enforcement patterns rather than a single real institution, runs its second-line risk function on a knowledge graph built over the prior eighteen months. The graph holds counterparty exposures aggregated across loans, derivatives, deposits, and contingent commitments. It feeds the executive risk dashboard. It feeds the relationship-banker chatbot. It feeds two of the bank’s BCBS 239 reports.

A standard supervisory exam arrives. The lead examiner asks for one thing: pick a number from the most recent risk report, walk it back to the source. The risk number is a single counterparty’s net exposure: roughly $150 million. The chief data officer, who is presenting, expects this to take five minutes.

It takes three weeks.

The graph holds the roughly $150 million as a derived value attached to a counterparty IRI. The team can show that the value was produced by a SPARQL view that joined seventeen triples across three named graphs. They cannot show, without a week of forensics, which version of the upstream loan data was in scope, whether the derivative contract had been amended in the last cycle, who approved the most recent counterparty hierarchy update, or which credit memo triples were reviewer-approved versus auto-extracted by the LLM extraction pipeline. Every triple in the graph is structurally fine. None of them carry the metadata required to defend the number to a regulator.

The team does what every team does in this situation. They reconstruct the lineage by hand. They open the version-control history of the R2RML mappings. They cross-reference Confluence pages to recover who ran which extraction batch. They eventually defend the number. The bank passes the exam with a finding: “data lineage capabilities are insufficient to support the bank’s BCBS 239 obligations.” The remediation plan is the next eighteen months of work.

This article is about the design choices that prevent the second outcome. The vocabulary work in Part 4, the runtime layer in Part 5, and the construction layer in Part 6 all assumed the graph was structurally sound. This article asks the harder question. Is the graph trustworthy. Can it be audited. When the regulator asks “where did this fact come from,” can the system answer in five minutes, not three weeks.

Quality Is Four Things, Not One

The first move is to stop talking about “data quality” in the singular. A KG can be high quality on one dimension and dangerously poor on another, and the failure modes are different per dimension. The four dimensions that matter for graphs are consistency, completeness, currency, and correctness. Each has a graph-specific definition that diverges from the relational analogue.

Dimension	Graph-specific meaning	What enforces it	Common failure mode
Consistency	The graph contains no contradictions per its ontology and shapes. Cardinalities respected. Disjoint classes not violated. SHACL constraints not breached.	SHACL validation at write time; OWL reasoners at audit time	A triple says a Loan has two borrowingParty links when the ontology declares the relation functional
Completeness	The graph contains all the triples it should, given its ontology and the source data committed to it	SHACL sh:minCount, ingestion reconciliation, source-to-graph diff	A Customer exists in the graph but has no legalName because the mapping skipped a null check
Currency	The triples in the graph reflect the current state of the world (or the explicitly declared time of validity)	Bitemporal modeling; named-graph versioning per release; refresh SLAs per source	Alice’s worksAt triple still says Acme Corp two years after she left; a regulation citation still points to the 2023 version
Correctness	The triples in the graph correspond to facts that are actually true in the world	Provenance attribution; reviewer queues; ground-truth audits; SHACL value-set constraints	An LLM extracted “Acme owes Beta $5M” from a credit memo where the actual figure was $5K

The order matters. Consistency is the cheapest to enforce because it is purely structural; SHACL and OWL profiles handle most of it. Completeness is the next cheapest because it is structural plus accounting. Currency requires a temporal model and refresh discipline; it is where most production KGs degrade silently. Correctness is the most expensive because it requires either ground truth or a trust ledger across sources, and ground truth is precisely what most enterprises do not have.

A KG that is consistent and complete but stale and wrong is the dangerous state. The graph passes structural validation. The chatbot answers confidently. The auditor still finds the bank in violation. The Data Quality dimensions surveyed in IBM’s quality dimensions reference and the graph-specific quality discussion in Hogan et al.’s ACM survey both treat these as distinct axes; in my experience the combination of structural correctness and semantic wrongness is the failure mode that most often produces a trust collapse in production KGs, because it is the one that passes every automated gate.

What this looks like in practice. When someone says “the KG quality is 95 percent,” ask which of the four dimensions. The answer is almost always consistency. The remaining three dimensions are the ones that show up in audits.

SHACL Is Your Consistency Gate (and Only That)

SHACL became a W3C Recommendation in 2017 and is the production standard for validating RDF graphs against shape constraints. A SHACL shape is a declarative statement of the form “every node of class Loan must have exactly one borrowingParty, must have a principalAmount greater than zero, and must reference a Counterparty whose lei matches a regex.” The SHACL engine validates a graph (or a delta) against the shapes and emits a validation report listing every violation.

In production KGs SHACL plays exactly one role correctly: the consistency gate. A small example shape:

@prefix sh:  <http://www.w3.org/ns/shacl#> .
@prefix lkv: <https://lakeside.com/vocab/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

lkv:LoanShape a sh:NodeShape ;
  sh:targetClass lkv:Loan ;
  sh:property [
    sh:path lkv:principalAmount ;
    sh:datatype xsd:decimal ;
    sh:minExclusive 0 ;
    sh:minCount 1 ;
    sh:maxCount 1 ;
  ] ;
  sh:property [
    sh:path lkv:borrowingParty ;
    sh:class lkv:Counterparty ;
    sh:minCount 1 ;
    sh:maxCount 1 ;
  ] .

This shape, run against the graph, will reject any Loan node missing a positive principalAmount or missing a single borrowingParty of class Counterparty. SHACL has expressive constructs for value sets, regular expressions, cardinalities, datatypes, and SPARQL-based custom rules. The Netflix Unified Data Architecture, described in the Netflix Tech Blog Unified Data Architecture post, uses SHACL extensively as the validation layer for its named-graph-first information model.

SHACL has limits, and getting them clear is the difference between a usable trust layer and a misleading one. The recent paper Is SHACL Suitable for Data Quality Assessment? (arXiv 2507.22305) defines SHACL shapes for 69 standard Data Quality metrics and concludes that SHACL is well suited to roughly two-thirds of consistency and completeness checks but inappropriate for currency and correctness. The reason is structural. SHACL evaluates graph state at validation time against shapes; it has no view of “is this true in the world” or “is this still current.”

The 2025 K-CAP paper Lessons Learned from the Combined Development of OWL and SHACL gives the production answer for ontology stacks: use OWL to express what is true and infer derived facts, use SHACL to validate what must be present, layer both on the same RDF graph. We locked this framing in Part 4 and it carries here.

What SHACL is good for	What SHACL is not good for
Consistency: cardinalities, disjoint classes, datatype constraints, value sets	Currency: SHACL has no notion of “stale”
Completeness: required properties, minimum counts, conditional presence	Correctness: SHACL cannot tell if the value is right, only if it conforms
Custom rules via SPARQL targets	Inference: SHACL does not derive new triples; OWL does
Per-named-graph scoping (validate one subgraph against shapes)	Cross-graph reasoning: that is OWL’s job

How to build the check. Author one shape per ontology class for the top ten classes by triple volume. Run the shape suite as a CI gate on every batch ingest, not as a nightly cleanup. SHACL violations should block the merge, not produce a Confluence page nobody reads.

Four Ways to Attach Provenance

Provenance is the metadata that lets you defend a triple. Where did the triple come from. What process produced it. Who is accountable for it. When was it asserted. What can it be derived from. RDF gives four mechanisms for attaching this metadata, each with sharp trade-offs. Picking the wrong one at construction time is one of the most expensive mistakes in KG engineering.

Mechanism 1: Classic RDF reification

The original RDF reification approach turns a triple into a node so other triples can describe it. The triple <Alice> <worksAt> <Acme> becomes:

:stmt_001 a rdf:Statement ;
  rdf:subject :Alice ;
  rdf:predicate :worksAt ;
  rdf:object :Acme ;
  prov:wasGeneratedBy :extraction_batch_42 ;
  prov:wasAttributedTo :reviewer_jane .

Per the W3C RDF 1.1 Concepts specification, this approach uses four extra triples per fact (subject, predicate, object, type) before any provenance metadata is added. For a graph of one hundred million asserted facts, classic reification adds at least four hundred million metadata triples. SPARQL queries against reified triples are awkward because the actual fact is hidden behind the reification node.

Classic reification is mostly historical. It is correct but verbose and slow. New KGs should not adopt it.

Mechanism 2: Named graphs

A named graph is a subgraph identified by its own IRI. Provenance attaches to the graph, not the individual triples inside it. SPARQL has native support via the GRAPH <iri> clause. Trust, source, and version metadata are described once for the whole graph.

GRAPH :credit_memo_extraction_2026_q2 {
  :Alice :worksAt :Acme .
  :Acme :hasParent :AcmeHoldings .
}

:credit_memo_extraction_2026_q2 a prov:Entity ;
  prov:wasGeneratedBy :extraction_batch_42 ;
  prov:wasAttributedTo :reviewer_jane ;
  prov:generatedAtTime "2026-04-15T09:00:00Z"^^xsd:dateTime ;
  prov:wasDerivedFrom :credit_memo_acme_2026_03 .

Named graphs are the dominant production pattern. The Springer 2023 survey on provenance management in KG platforms finds that most enterprise RDF triple stores (see Appendix A for the specific tools) use named graphs as the primary provenance partition. The Netflix Unified Data Architecture is named-graph-first by design; the Netflix Tech Blog describes each named graph as conforming to a governing model, with provenance and validation hung off the graph IRI.

The trade-off: named graphs work cleanly when provenance is uniform across many triples (one extraction batch produces one named graph; one source ingest produces one named graph). They become awkward when you need triple-level provenance, because every triple with distinct provenance becomes its own graph and the graph count explodes.

Mechanism 3: RDF-star

RDF-star (formalized in W3C RDF 1.2 / the RDF-star CG spec) lets you put a triple inside another triple’s subject or object position, enabling per-edge metadata without reification. The same Alice worksAt Acme example:

<< :Alice :worksAt :Acme >>
  prov:wasGeneratedBy :extraction_batch_42 ;
  prov:wasAttributedTo :reviewer_jane ;
  prov:generatedAtTime "2026-04-15T09:00:00Z"^^xsd:dateTime .

Per a triple-store vendor analysis of RDF-star versus named graphs, RDF-star is faster than classic reification, requires less storage than named graphs when provenance varies per triple, and has full SPARQL-star support in modern engines. The trade-off is that inference over starred triples is more limited than over plain RDF triples; OWL profiles do not yet handle quoted triples cleanly. Use RDF-star when you genuinely need per-triple provenance and inference is a smaller concern.

Mechanism 4: PROV-O at the triple-set level

PROV-O, the W3C Provenance Ontology, is a vocabulary of three core classes (prov:Entity, prov:Activity, prov:Agent) and a set of properties (prov:wasGeneratedBy, prov:used, prov:wasDerivedFrom, prov:wasAttributedTo, prov:wasAssociatedWith, prov:wasInformedBy, prov:startedAtTime, prov:endedAtTime). PROV-O does not specify how provenance attaches to triples; it specifies what the metadata graph looks like. Combine it with named graphs (the common case) or RDF-star (when triple-level granularity is needed).

A PROV-O fragment for the same example:

:credit_memo_extraction_2026_q2 a prov:Entity ;
  prov:wasGeneratedBy :extraction_batch_42 ;
  prov:wasDerivedFrom :credit_memo_acme_2026_03 ;
  prov:wasAttributedTo :reviewer_jane .

:extraction_batch_42 a prov:Activity ;
  prov:startedAtTime "2026-04-15T08:30:00Z"^^xsd:dateTime ;
  prov:endedAtTime   "2026-04-15T09:00:00Z"^^xsd:dateTime ;
  prov:used :credit_memo_acme_2026_03 ;
  prov:used :extraction_pipeline_v3_2 ;
  prov:wasAssociatedWith :reviewer_jane .

:reviewer_jane a prov:Agent, lkv:Person ;
  lkv:role lkv:CreditAnalyst .

:credit_memo_acme_2026_03 a prov:Entity ;
  lkv:sourceURI <https://lakeside.internal/sharepoint/memo_acme_2026_03.pdf> ;
  lkv:sha256 "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08" .

The 2024 FOIS paper Full Traceability and Provenance for Knowledge Graphs (Dibowski) lays out the production pattern clearly: PROV-O for the metadata vocabulary, named graphs for the partition mechanism, and explicit prov:Activity records for every batch that asserts triples. In the regulated deployments I have seen, this combination has become the default.

Picking the mechanism

Pick	When
Named graphs alone	Provenance varies by source or batch, not by triple. The 80 percent case for enterprise KGs.
Named graphs + PROV-O metadata	You also need to track activities, agents, and derivation chains. The production default for regulated industries.
RDF-star + PROV-O	You genuinely need per-triple provenance (extraction confidence per assertion, reviewer signoff per fact) and named-graph explosion would make the partition unusable.
Classic reification	Almost never. Only for compatibility with legacy systems that predate named graphs.

The named-graph-plus-PROV-O combination handles the BCBS 239 “trace every metric to source” requirement cleanly: every named graph has a PROV-O wasDerivedFrom chain back to the source documents and a wasAssociatedWith agent. Auditors can walk the chain in SPARQL. The bank in the opening anecdote did not have this; that is what the three-week reconstruction was rebuilding by hand.

The Provenance Contract: What Every Triple Must Record

A KG with provenance is a KG where every triple’s metadata answers six questions. If any of the six is missing, the trust layer has a gap.

Question	Standard answer field
Where did this triple come from?	prov:wasDerivedFrom pointing to a source prov:Entity (file URI, database snapshot, API response, prior named graph)
What process produced it?	prov:wasGeneratedBy pointing to a prov:Activity (R2RML run, LLM extraction batch, reviewer approval, inferred-by-OWL-reasoner)
Who is accountable for it?	prov:wasAttributedTo pointing to a prov:Agent (a person, a service account, an automated pipeline)
When was it asserted?	prov:generatedAtTime (and optionally prov:invalidatedAtTime for the end of validity)
What is the trust level?	A custom property like lkv:confidence (1.0 for deterministic mappings; 0.4-0.95 for LLM-extracted; 1.0 for reviewer-approved). Often paired with lkv:trustTier (gold, silver, bronze).
What is the source hash?	lkv:sha256 (or equivalent) on the source artifact, so the team can verify the source has not been silently altered

The contract is a lock. Every ingestion path emits these six fields. SHACL shapes enforce that the metadata named graph itself conforms (no Activity without an Agent, no Entity without a derivation source). Pipelines that cannot answer one of these six questions do not ship.

The agent-era restatement: An AI agent retrieving from a KG without these six fields is making decisions on triples it cannot defend. Per the Part 5 framing on real-time entity resolution and the construction-layer rules in Part 6, the agent path needs the trust tier exposed at retrieval, so the agent can choose to weight gold-tier triples higher than bronze-tier and surface uncertainty to the human in the loop.

Trust Is Not Uniform

A common production failure pattern is to treat all triples as equally trustworthy because the graph is one logical store. The graph in fact contains triples with wildly different trust profiles. A triple that originated in the customer master via a deterministic R2RML mapping reviewed by a human is gold-tier. A triple that an LLM extracted from a single mention in one credit memo with no reviewer signoff is bronze-tier. The aggregation that assumes uniform trust is the aggregation that fails the audit.

The fix is differentiated trust. Per-named-graph trust tiers, exposed to query patterns and to agents. The four-tier schema below is one I use as a starting template; the tier names and confidence bands are an example design, not an industry standard, and most teams tune the bands to their own sources.

Tier	Source pattern	Confidence range	Used for
Gold	Deterministic mapping from a system of record; reviewer-approved facts; OWL-inferred from gold-tier inputs only	0.99 - 1.00	Regulatory reporting; high-stakes decisions; binding agent actions
Silver	Deterministic mapping from secondary sources; LLM-extracted with reviewer signoff; entity-resolved with high deterministic-rule match	0.90 - 0.99	Internal analytics; dashboards; agent recommendations needing human approval
Bronze	LLM-extracted without reviewer signoff; probabilistic ER match below threshold; third-party feed with no SHACL validation	0.50 - 0.89	Hypothesis generation; agent context with explicit uncertainty surfacing
Quarantine	SHACL violations not yet resolved; conflicting assertions across sources	<0.50 or undefined	Not served to consumers; reviewer queue only

A SPARQL query that aggregates exposures for regulatory reporting should filter to gold-tier (or gold + silver with the silver tier flagged in the report). A relationship-banker chatbot can use silver and bronze for context but must surface the tier to the user. The same KG serves both consumers; the trust filter is the differentiator.

This pattern composes with the named-graph-plus-PROV-O provenance layer. Each named graph carries a lkv:trustTier property. SPARQL queries scope to the relevant tier. New ingestion batches default to bronze and graduate to silver or gold via reviewer signoff. The graduation event is itself a prov:Activity with its own prov:wasAssociatedWith agent.

A Trust Diagnostic for the Graph You Inherit

Use this when you walk into a KG that has been running for a year or more and you need to know if it is audit-ready. Each row is a yes/no question; a no on three or more is a strong signal that the trust layer needs work before the next exam.

Diagnostic question	If yes	If no
Can you, from any triple in the graph, walk the provenance chain back to a source artifact in under five minutes?	The provenance contract is intact	The trust layer has gaps; an exam will surface them
Are SHACL shapes authored for the top ten classes by triple volume and run as a CI gate on every batch?	Consistency violations are caught at ingest	Bad triples land in the graph; cleanup is ongoing
Does every triple carry a trust tier (gold, silver, bronze, quarantine) attached via named-graph or RDF-star metadata?	Differentiated queries are possible; agents see uncertainty	All triples are treated as equal; high-stakes consumers see noise mixed with truth
Is currency tracked per source via a refresh SLA and a prov:invalidatedAtTime (or equivalent bitemporal property)?	Stale triples can be detected and either refreshed or downgraded	Currency degrades silently; the chatbot answers confidently from outdated facts
Does the metadata graph itself have SHACL shapes (every Activity has an Agent, every Entity has a derivation)?	The provenance layer is structurally sound	The provenance layer can be silently incomplete
Are PROV-O activities recorded for every batch that writes triples (not just the final ingestion)?	Lineage is end-to-end; reasoner inferences are themselves traceable activities	Lineage stops at the load step; downstream derivations are unattributed
Is the source hash recorded so the team can detect silent source changes?	Source-side tampering or unannounced overwrites are detectable	The source can be silently rewritten and the KG will not know
Does the trust layer integrate with the enterprise OpenLineage (or equivalent) lineage stack so KG provenance and pipeline lineage are queryable as one?	Cross-system audit is feasible	KG provenance and pipeline lineage are two parallel systems; the auditor has to reconcile by hand

What this looks like in practice. Most KG audit findings cluster on three of these eight rows: trust tiers absent, currency untracked, and source hashes absent. Those three are the cheapest to add retroactively if the named-graph-plus-PROV-O scaffolding is already in place and impossibly expensive to add if the graph was constructed without provenance scaffolding at all. This is why the construction-time decision matters more than the audit-time response.

Where KG Provenance Meets Pipeline Lineage

Two adjacent disciplines look like the same thing and are not. KG provenance (this article) lives inside the graph; it tells you what each triple is and where it came from. Pipeline lineage (the OpenLineage standard and the metadata stores and data catalog platforms that implement it; see Appendix A for the specific tools) lives outside the graph; it tells you what each pipeline did to which dataset and when. A regulator under BCBS 239 asks for both. Most enterprises have one and not the other.

The integration pattern is to model the OpenLineage event stream as PROV-O activities inside the KG. Every OpenLineage Run becomes a prov:Activity; every OpenLineage Dataset becomes a prov:Entity; every OpenLineage Job becomes a prov:Activity linked to the Run. The PROV-O graph then contains both the in-KG provenance and the upstream pipeline lineage as one queryable structure. SPARQL walks across both.

Layer	What it tracks	Standard	Where it lives
KG provenance	Triples to source artifacts; reviewer signoffs; OWL-derived facts; trust tiers	W3C PROV-O, named graphs, RDF-star	Inside the KG, as metadata on named graphs and entities
Pipeline lineage	Dataset to dataset; job runs; column-level lineage where supported	OpenLineage spec, the OpenLineage metadata store API	Outside the KG, in the lineage backend
Bridge	OpenLineage events ingested into the KG as PROV-O activities	Custom mapping (RML or hand-coded)	The named graph that holds operational lineage

A 2025 enterprise data lakehouse OpenLineage announcement and a cloud data catalog OpenLineage integration (the product now branded Knowledge Catalog, formerly Dataplex Universal Catalog; see Appendix A for the specific tools) demonstrate that the major platforms are converging on this bridge pattern. For BCBS 239 reporting, the bridge is what lets a single SPARQL query traverse from a regulatory metric in the report, through the KG-derived value, through the named graph that produced it, through the OpenLineage Run that ran the SPARQL view, through the upstream pipeline that loaded the source data, to the source database snapshot.

Regulatory Cross-Walk

Three regimes drive most of the audit pressure on enterprise KGs. The KG trust layer designed above answers each.

Regime	What the regulator asks	What the trust layer must produce
BCBS 239 (banking risk data aggregation, Basel Committee, 2013)	Trace every risk metric in every regulatory report from final number through every transformation back to the system of record. Demonstrate accuracy, completeness, and timeliness.	Named-graph-plus-PROV-O provenance from the metric back to source; OpenLineage bridge for upstream pipeline lineage; trust tier on every contributing triple; source hash for tamper detection
GDPR Article 30 (records of processing activities, EU 2018)	For every personal data element, document the purpose of processing, categories of data subjects and data, recipients, retention period, and security measures.	PROV-O activities for every processing step that touches personal data; named graph per processing context; SHACL shapes that enforce required GDPR properties (purpose, lawful basis, retention) on Person-related triples
EU AI Act (in force Aug 2024; high-risk obligations phased to Dec 2027 / Aug 2028 per the 2026 Omnibus)	For high-risk AI systems, document training data provenance, model versioning, human oversight, and decision lineage.	KG holds the model registry and training dataset references as PROV-O entities; agent decisions logged as PROV-O activities; trust tier on context retrieved for each decision; named graph per model version

For the bank in the opening anecdote, BCBS 239 was the precipitating regulator. For a healthcare KG it would be HIPAA plus the FDA’s 21 CFR Part 11 on electronic records. For a pharmaceutical KG supporting clinical trials it would be GxP and the recent FDA guidance on AI/ML in regulatory submissions. The vocabulary differs; the underlying ask is the same: defend every fact, name the agent, time-stamp the activity, hash the source.

Seven Failure Modes Specific to the Trust Layer

These are the patterns where the trust layer breaks down. Recognize them on a system you inherit and you save quarters of remediation.

Failure	Symptom	Root cause
Provenance deferred to “later”	Audit fails; reconstruction by hand takes weeks	Construction pipeline emitted triples with no PROV-O scaffolding; retrofitting requires re-ingest of every batch
Uniform trust across the graph	High-stakes consumers (regulators, agents acting on behalf of users) get hit with bronze-tier triples mixed into gold-tier aggregates	No named-graph trust tiering; no per-graph trust property; SPARQL queries do not filter by tier
Currency invisible	The chatbot confidently asserts facts that are two years old	No prov:invalidatedAtTime; no per-source refresh SLA; bitemporal model absent
SHACL as documentation, not gate	SHACL shapes exist; they are run nightly as a report; nobody reads the report	Shapes are not on the CI write path; violations do not block ingest
Metadata graph unvalidated	Half the named graphs have an Activity without an Agent; the audit cannot complete	The provenance scaffolding itself was not subjected to SHACL validation
OpenLineage and KG provenance siloed	KG can defend itself; pipeline lineage can defend itself; the auditor still cannot trace end-to-end	No bridge between OpenLineage events and PROV-O activities inside the KG
Source hash absent	A vendor silently rewrites a feed; the KG asserts old facts as if they were new	Construction pipeline did not capture lkv:sha256 (or equivalent) at ingest; silent source changes are invisible

Decision Tree for the Trust Layer

When you are designing the trust layer for a new KG, walk these questions in order.

1. What is the highest regulatory bar this KG will face in its lifetime? BCBS 239, GDPR, EU AI Act, HIPAA, GxP, SOX, or none. The bar sets the minimum viable provenance contract.
2. What provenance mechanism will you use? Named graphs alone for the simple case; named graphs plus PROV-O for the regulated default; named graphs plus PROV-O plus RDF-star for triple-level granularity.
3. What are your trust tiers? At minimum gold, silver, bronze, quarantine. Define the source patterns that map to each.
4. What are your SHACL shapes for the top ten classes? Author them before the first batch ingest. Run them as a CI write gate, not a nightly report.
5. What is your currency model? Per-source refresh SLAs; bitemporal modeling for the highest-currency-sensitivity entities (counterparty status, regulatory citations, employment relationships).
6. What is your source hash policy? Deterministic at ingest; alert on hash change; new hash creates a new named graph version.
7. What is your OpenLineage bridge? Identify the events to pull (Job runs, Dataset materializations, Run completions); model them as PROV-O activities in a designated named graph.
8. What is your trust scoring policy? Named-graph default tier on ingest; reviewer signoff promotes a graph one tier; SHACL violation demotes a graph to quarantine.
9. What is your audit query suite? At minimum: pick any triple, walk to source in five SPARQL queries; for any regulatory metric, produce the full provenance graph; for any quarantine graph, produce the SHACL violation list and the responsible agent.
10. What is the change protocol when shapes evolve? See Part 8 on operations and versioning.

Most production KGs that pass an audit cleanly converge to: named-graph-plus-PROV-O for provenance, four trust tiers with explicit graduation rules, SHACL on the CI write path, bitemporal modeling on high-currency entities, source hashes on every ingest, and an OpenLineage bridge to the pipeline lineage backend. That is not the only shape; it is the shape that produces a five-minute audit instead of a three-week reconstruction.

What You Should Now Be Able to Do

If you read this article cold, you should now be able to:

• Distinguish the four quality dimensions for a KG (consistency, completeness, currency, correctness) and identify which mechanisms enforce which.
• Design SHACL shapes for the top classes in your ontology and wire them as a CI write gate.
• Pick a provenance mechanism (named graphs alone, named graphs + PROV-O, RDF-star + PROV-O, classic reification) with a defensible justification.
• Author a PROV-O fragment for any ingestion batch with the six-field provenance contract intact.
• Define and operate trust tiers (gold, silver, bronze, quarantine) with explicit graduation rules and SPARQL filtering.
• Diagnose a KG you inherited against the eight-row trust diagnostic and produce a remediation plan.
• Bridge KG provenance with OpenLineage pipeline lineage so a single audit query can traverse both.
• Map your KG’s trust layer to the relevant regulatory regime (BCBS 239, GDPR Article 30, EU AI Act, or domain-specific equivalents).

You now have the trust layer of the KG. The construction layer in Part 6 plus this trust layer plus the operations layer in Part 8 cover the full lifecycle of triples in a production graph. The applications layer (Part 9 for agents, Part 10 for governance) follows. The Lakeside Trust Bank reference architecture in Part 11 instantiates the trust layer end to end against a BCBS 239 scenario.

Do Next

Priority	Action	Why it matters
This week	Run the eight-row trust diagnostic against your current KG (or your candidate platform’s reference deployment). Score each row honestly. Identify the rows that are no.	Most teams have not actually scored their trust layer. The diagnostic is a forty-minute exercise that produces a remediation backlog.
This week	Pick the most recent value in your most recent regulatory or executive report. Walk it back to source by hand, and time the walk. If it takes longer than five minutes, the trust layer has a structural gap, not just a process gap.	This is exactly the test the regulator runs. Running it on yourself first is cheaper than running it under audit.
This month	Author SHACL shapes for the top ten classes by triple volume and wire them as a CI write gate (not a nightly report). Block the merge on violations. Per the W3C SHACL spec, the shape suite is the single most effective consistency control.	Per the 2025 paper on SHACL for data quality assessment, SHACL on a CI gate catches the majority of consistency and completeness defects before they enter the graph.
This month	If your KG has no named-graph-plus-PROV-O scaffolding, stop building features and add it. Re-ingest the most recent batches with provenance attached so that at least the active working set is auditable.	Retrofitting provenance at construction time is one to two orders of magnitude cheaper than retrofitting it under audit pressure. The longer you wait, the larger the remediation cost.
This quarter	Define your four trust tiers (gold, silver, bronze, quarantine) with explicit graduation rules. Wire trust filtering into the SPARQL queries that feed your highest-stakes consumers (regulatory reports, agent decisions).	A graph that does not differentiate trust is a graph whose users implicitly assume uniform trust. The auditor and the agent both lose when that assumption is wrong.
This quarter	Stand up the OpenLineage bridge. Pull pipeline events into a designated named graph as PROV-O activities. Verify that a single SPARQL query can traverse from a regulatory metric to the source database snapshot via the KG and the lineage backend.	The cross-system audit has become the practical BCBS 239 test. Without the bridge, even a perfect KG provenance layer fails the end-to-end ask.
Next two quarters	Build the audit query suite as a regression test. At minimum: pick any triple, walk to source; for any reportable metric, produce the full provenance graph; for any quarantine graph, produce the SHACL violation list and the responsible agent. Run the suite on every release.	The audit query suite is the only way to know that the trust layer still works after schema evolution and ontology change. See Part 8 for how the trust layer survives operations.

---

Part 8 of this series, “Operating a Knowledge Graph: Change, Versioning, and Evolution at Scale,” covers what happens when the ontology evolves, when the source schemas change, and when the trust layer itself has to be migrated. Read it next.