THE GOLD STANDARD OF INFORMATION · SPECIALIST STUDY
State which datatype meanings your RDF system is prepared to recognise
Datatype entailment adds meaning only under a declared set of recognised datatype IRIs. That set turns lexical forms into values, permits new conclusions and can also expose contradictions. The result is powerful but conditional: two processors with different recognition profiles may preserve the same RDF terms while supporting different semantic judgements. The gold standard makes the profile, evidence and limits inspectable.
This guide belongs to the Information subject guide, the Gold Standard of Education, and the How X Works learning library. Choose a reading route, work the examples, then use the transfer checks to test whether the method survives a changed context.
Choose a reading route
Build the foundations · chapters 1–2
Apply the core method · chapters 3–5
Test evidence and alternatives · chapters 6–7
Handle limits and disagreement · chapters 8–9
Transfer and govern · chapters 10
The whole problem at a glance
| Question | Evidence needed | Safe conclusion |
|---|---|---|
| Which datatype IRIs are recognised? | Versioned implementation profile | Only listed datatype maps are assumed |
| Does each lexical form map to a value? | Normative lexical-to-value rule and test result | A value exists, fails, or remains uninterpreted |
| Does the graph entail another graph? | Named entailment regime and profile | The conclusion is conditional on both |
| Is there a contradiction? | A failed interpretation under the declared regime | Semantic inconsistency, not automatic parse failure |
Recognition, lexical validity, entailment, application validation and workflow acceptance are separate decisions.
CHAPTER 1 OF 10 · Build the foundations
1. Define datatype entailment as a conditional claim
Core idea. RDF entailment asks whether every interpretation satisfying one graph also satisfies another. Datatype entailment strengthens the interpretation by recognising selected datatype IRIs and their lexical-to-value mappings. The set is part of the claim, so “entailed” without a regime and recognition profile is incomplete.
Method. Write every automated judgement as graph, entailment regime, recognised datatype set, processor version and options. Keep the asserted graph separate from generated consequences and log which rule supported each inferred triple or inconsistency.
Worked example. A graph states ex:item ex:count “01”^^xsd:integer. Under a profile recognising xsd:integer, the literal denotes the integer one. A consumer can support value-sensitive conclusions even though the lexical form differs from “1”.
Changed-context transfer. Transfer to a database query: the same stored text may compare numerically only after the column type and conversion contract are declared. The conditional nature of the comparison remains.
Limits. Datatype entailment does not establish domain truth, completeness or identity across all datatypes. It also does not license a processor to recognise an undocumented private datatype.
Evidence and review. Turn this chapter into a dated claim register. Record the evidence available, the assumption being made, the decision it affects, the accountable owner, the strongest reasonable alternative and the event that would trigger reconsideration. Test the method on real workflow output and preserve enough provenance for an independent authorised reviewer to reproduce the path.
Misconception to avoid. RDF has one universal datatype interpretation that every conforming tool applies. Conformance defines semantics, while deployed recognition and query support still require an explicit profile.
Practical evidence check
- Take one claimed inference and reproduce it with the exact graph, regime, recognised set and processor; then remove one datatype from the set and record what changes.
- Return to chapter contents
CHAPTER 2 OF 10 · Build the foundations
2. Separate datatype IRIs, maps and implementation capability
Core idea. A datatype is not merely a string pattern. It has a lexical space, value space and mapping from lexical forms to values. A recognised datatype IRI identifies such a map for the interpretation, while an implementation may support only selected operations over the resulting values.
Method. Maintain a registry with IRI, authoritative specification, datatype version, lexical checker, canonicalisation, equality, ordering, arithmetic and serialization support. Report unsupported operations without erasing the underlying value claim.
Worked example. A tool recognises xsd:dateTime enough to test lexical validity but cannot compare timezones safely. It may record a value-level result while refusing an ordering operation; those are not contradictory outcomes.
Changed-context transfer. Transfer to units of measure: recognising a unit code does not imply that every conversion, precision rule or uncertainty calculation is implemented.
Limits. Dereferencing an IRI can fail or return changing material. Recognition must rely on a governed specification and version, not live web content alone.
Evidence and review. Turn this chapter into a dated claim register. Record the evidence available, the assumption being made, the decision it affects, the accountable owner, the strongest reasonable alternative and the event that would trigger reconsideration. Test the method on real workflow output and preserve enough provenance for an independent authorised reviewer to reproduce the path.
Misconception to avoid. If a datatype IRI resolves on the web, the processor recognises it. Network retrieval is neither a semantic registry nor proof of correct implementation.
Practical evidence check
- Audit the registry against executable fixtures for every claimed capability, including unsupported operations and version boundaries.
- Return to chapter contents
CHAPTER 3 OF 10 · Apply the core method
3. Test lexical-to-value mappings before reasoning
Core idea. Datatype reasoning depends on whether a lexical form belongs to the recognised lexical space and what value it maps to. Whitespace, signs, timezone notation, language direction or special tokens can change the result. Visual plausibility is not a semantic test.
Method. Use normative positive, negative and boundary examples. Preserve the exact lexical form, datatype IRI, normalisation step and result. Do not silently substitute a repaired string before entailment.
Worked example. “01”^^xsd:integer and “1”^^xsd:integer can map to the same value; “1.0”^^xsd:integer does not become an integer merely because a programming language can coerce it.
Changed-context transfer. For clinical codes, a syntactically neat code can still be outside the declared code-system version. Preserve it as evidence and withhold unsupported inferences.
Limits. Libraries may implement legacy or partial rules. Passing one library is evidence about that configuration, not the abstract datatype itself.
Evidence and review. Turn this chapter into a dated claim register. Record the evidence available, the assumption being made, the decision it affects, the accountable owner, the strongest reasonable alternative and the event that would trigger reconsideration. Test the method on real workflow output and preserve enough provenance for an independent authorised reviewer to reproduce the path.
Misconception to avoid. Canonical form creates validity. Canonicalisation is meaningful only after a lexical form has successfully mapped to a value.
Practical evidence check
- Build fixtures for valid synonyms, invalid forms, bounds and timezone cases; compare two implementations and explain each disagreement.
- Return to chapter contents
CHAPTER 4 OF 10 · Apply the core method
4. Distinguish equality of values from identity of RDF terms
Core idea. Two typed literals can be different RDF terms yet denote the same value under a recognised datatype. Conversely, similar lexical forms with different datatype IRIs can denote different kinds of values. Term identity, value equality and application equivalence answer different questions.
Method. Use sameTerm for RDF-term identity and a declared value comparison for datatype equality. Retain both results in deduplication, joins and evidence records so a value merge does not erase the asserted lexical form.
Worked example. “01”^^xsd:integer and “1”^^xsd:integer are distinct lexical terms but can share value one. A provenance system keeps both assertions while a numeric aggregation counts their common value appropriately.
Changed-context transfer. In names, case-folded equality may help search but should not overwrite the source spelling or imply that two people are identical.
Limits. Some datatypes have partial orders, incomparable values or context-sensitive equality. Never generalise numeric intuitions to every recognised datatype.
Evidence and review. Turn this chapter into a dated claim register. Record the evidence available, the assumption being made, the decision it affects, the accountable owner, the strongest reasonable alternative and the event that would trigger reconsideration. Test the method on real workflow output and preserve enough provenance for an independent authorised reviewer to reproduce the path.
Misconception to avoid. Equal values mean interchangeable assertions. Provenance, datatype, lexical choice and graph position can remain materially different.
Practical evidence check
- Run deduplication twice—by RDF term and by declared value—and inspect every pair that changes membership.
- Return to chapter contents
CHAPTER 5 OF 10 · Apply the core method
5. Detect semantic inconsistency without destroying the graph
Core idea. A graph is semantically inconsistent under a regime when no interpretation satisfies it. Recognised ill-typed literals can create such conflicts. This is stronger than a validation warning but different from syntax failure: the asserted terms and provenance can still be preserved for diagnosis and repair.
Method. Return a structured result naming the graph, regime, recognised set, offending term and rule. Quarantine affected reasoning products, not necessarily the source record. Keep raw evidence immutable and make repair a separately authorised change.
Worked example. A graph contains “yes”^^xsd:boolean under a profile recognising XML Schema boolean. The term is representable, but the lexical mapping supplies no boolean value; the declared semantic assumptions cannot all be satisfied.
Changed-context transfer. Transfer to a spreadsheet with a date column: one impossible date should be retained and flagged while unrelated cells remain available for review.
Limits. Different profiles can expose different inconsistencies. A weaker profile may withhold a judgement rather than establish consistency in every richer regime.
Evidence and review. Turn this chapter into a dated claim register. Record the evidence available, the assumption being made, the decision it affects, the accountable owner, the strongest reasonable alternative and the event that would trigger reconsideration. Test the method on real workflow output and preserve enough provenance for an independent authorised reviewer to reproduce the path.
Misconception to avoid. If a processor does not report a contradiction, the data are consistent everywhere. Silence may reflect an unrecognised datatype or disabled checking.
Practical evidence check
- Inject one known inconsistency and confirm that the system preserves the source, blocks unsafe inferences, identifies the profile and offers a traceable correction route.
- Return to chapter contents
Worked recognised-datatype comparison
| Input | Profile A | Profile B |
|---|---|---|
| “01”^^xsd:integer | Recognised; value 1 | Recognised; value 1 |
| “1”^^ex:grade | Unrecognised; preserve term | Recognised; maps to grade 1 |
| “yes”^^xsd:boolean | Recognised but no boolean value | Same inconsistency if the same datatype rule applies |
| “1”^^xsd:string | Recognised string value | Recognised string value, not the integer 1 |
A datatype IRI does not grant meaning by appearance alone; the profile must identify the map it recognises.
CHAPTER 6 OF 10 · Test evidence and alternatives
6. Design implementation profiles for reproducibility
Core idea. A profile turns abstract semantics into an auditable deployment contract: recognised datatypes, entailment regime, parser features, comparison operations, limits and failure behaviour. Without it, identical labels such as “RDF 1.2 support” can conceal materially different systems.
Method. Publish a machine-readable identifier and human summary. Pin specification and library versions, list exclusions, include conformance vectors and state how unknown datatypes, resource limits and extension functions are handled.
Worked example. A knowledge graph service publishes profile v3 recognising xsd:string, boolean, integer, decimal and dateTime, but not a private geospatial datatype. Clients can predict which value inferences and errors the service will issue.
Changed-context transfer. A school data exchange can publish a separate profile for identifiers, dates and score bands. The same governance makes conversion assumptions visible.
Limits. Profiles can fragment interoperability if every team invents one. Prefer shared standards, declare deviations narrowly and provide compatibility tests.
Evidence and review. Turn this chapter into a dated claim register. Record the evidence available, the assumption being made, the decision it affects, the accountable owner, the strongest reasonable alternative and the event that would trigger reconsideration. Test the method on real workflow output and preserve enough provenance for an independent authorised reviewer to reproduce the path.
Misconception to avoid. A longer recognition list is always better. Extra semantics can expose contradictions, increase cost or create assumptions that partners cannot reproduce.
Practical evidence check
- Give an independent reviewer only the profile and fixtures; require them to reproduce a representative inference, refusal and inconsistency.
- Return to chapter contents
CHAPTER 7 OF 10 · Test evidence and alternatives
7. Query under a named entailment regime
Core idea. SPARQL can operate over explicit triples or an entailment regime that defines an expanded answer set. Datatype recognition affects equality, filters and D-entailment, while query error rules determine what happens when a required value is unavailable.
Method. Record dataset, active graph, regime, recognised set and query engine. Separate materialised triples from virtual answers and test FILTER, BIND, ordering and aggregates with valid, ill-typed and unknown datatype values.
Worked example. A query asks for counts numerically greater than zero. A valid integer participates; an ill-typed integer can cause an expression error for its solution; an unknown private datatype is not safely coerced. Other solutions need not disappear.
Changed-context transfer. In an API, one conversion error should not silently become zero or null. Return an explicit status and retain the original value.
Limits. Engines can differ in extension support and optimisation. A logically equivalent query may expose different operational failures unless the profile and tests are shared.
Evidence and review. Turn this chapter into a dated claim register. Record the evidence available, the assumption being made, the decision it affects, the accountable owner, the strongest reasonable alternative and the event that would trigger reconsideration. Test the method on real workflow output and preserve enough provenance for an independent authorised reviewer to reproduce the path.
Misconception to avoid. An empty result proves the proposition is false. It may reflect regime choice, error filtering, missing data, access control or an unsupported datatype.
Practical evidence check
- Run the same query in explicit-only and datatype-entailment modes; explain every added, removed or errored solution.
- Return to chapter contents
CHAPTER 8 OF 10 · Handle limits and disagreement
8. Control materialisation, caching and profile changes
Core idea. Materialising datatype consequences can speed queries but makes profile changes operationally significant. Cached inferences created under one recognised set may become incomplete, invalid or misleading after an upgrade.
Method. Tag generated statements and caches with profile, rule, source graph and time. On upgrade, diff recognised maps, rerun conformance vectors and invalidate or recompute affected consequences.
Worked example. Version 4 adds recognition for ex:grade. Earlier records that were preserved without value reasoning now produce equality and range conclusions. The migration report identifies newly interpreted data rather than presenting the change as new source evidence.
Changed-context transfer. Transfer to currency conversion: a new exchange-rate table changes derived values but not the recorded transaction. Provenance must separate source from computation.
Limits. Full recomputation may be costly. Use dependency indexes and conservative invalidation, but do not mix products from incompatible profiles.
Evidence and review. Turn this chapter into a dated claim register. Record the evidence available, the assumption being made, the decision it affects, the accountable owner, the strongest reasonable alternative and the event that would trigger reconsideration. Test the method on real workflow output and preserve enough provenance for an independent authorised reviewer to reproduce the path.
Misconception to avoid. Once inferred, a triple is permanent knowledge. An inference is conditional evidence whose support can change when data, rules or profile change.
Practical evidence check
- Trace one cached conclusion to source, rule and profile, then simulate removal of the supporting datatype map and verify invalidation.
- Return to chapter contents
Entailment and failure ladder
| Layer | Positive result | Failure or limit |
|---|---|---|
| Parsing | RDF terms and quads recovered | Syntax error or unsupported feature |
| Datatype recognition | Datatype map is available | IRI remains semantically uninterpreted here |
| Lexical mapping | A value is supplied | Recognised form may be ill-typed |
| D-entailment | A conclusion follows in the named regime | No conclusion, or inconsistency, under that profile |
Never report “invalid RDF” when the evidence establishes only a profile-specific semantic conflict.
CHAPTER 9 OF 10 · Handle limits and disagreement
9. Protect reasoning services from hostile or costly inputs
Core idea. Datatype parsing and entailment can be attacked with oversized lexical forms, pathological numeric precision, expensive calendars, Unicode confusion or graphs designed to amplify inference. Diagnostics can also leak sensitive values.
Method. Set deterministic size, time, recursion and precision limits; use maintained parsers; escape outputs; redact sensitive lexicals; rate-limit repeated failures; and return a distinct resource-limit state rather than a semantic answer.
Worked example. A client sends a ten-million-digit decimal. The service refuses value construction at a documented limit, preserves a secured reference to the input and reports “not evaluated,” not “false” or “ill-typed.”
Changed-context transfer. Scientific workflows may legitimately need huge precision. Provide an authorised high-capacity profile rather than weakening every public endpoint.
Limits. Limits can create unequal access or reject valid edge cases. Measure who is affected and provide escalation and correction.
Evidence and review. Turn this chapter into a dated claim register. Record the evidence available, the assumption being made, the decision it affects, the accountable owner, the strongest reasonable alternative and the event that would trigger reconsideration. Test the method on real workflow output and preserve enough provenance for an independent authorised reviewer to reproduce the path.
Misconception to avoid. A timeout proves non-entailment. Resource exhaustion says the service did not complete the semantic test.
Practical evidence check
- Use oversized, confusable and repeated-failure fixtures; verify bounded work, safe diagnostics and no cached false conclusion.
- Return to chapter contents
CHAPTER 10 OF 10 · Transfer and govern
10. Govern datatype semantics as a living public contract
Core idea. RDF 1.2 adoption, library upgrades, domain datatypes and partner requirements evolve. Governance keeps those changes reviewable: owners, evidence, compatibility, deprecation, security and user-facing explanations.
Method. Create a change proposal for every datatype or rule, test it against retained fixtures and real samples, assess newly entailed and inconsistent cases, publish migration guidance and maintain rollback.
Worked example. A consortium proposes ex:schoolYear. Before recognition, it specifies lexical and value spaces, equality, versioning and examples, then pilots across producers and consumers.
Changed-context transfer. The same process applies to controlled vocabularies, code systems and measurement units: meaning becomes operational only through a shared, testable contract.
Limits. Central control can exclude domain expertise; uncontrolled extension fragments meaning. Use transparent review and scoped extension points.
Evidence and review. Turn this chapter into a dated claim register. Record the evidence available, the assumption being made, the decision it affects, the accountable owner, the strongest reasonable alternative and the event that would trigger reconsideration. Test the method on real workflow output and preserve enough provenance for an independent authorised reviewer to reproduce the path.
Misconception to avoid. Semantic governance ends when the specification is published. Deployed behaviour, incident data and interoperability tests must continue feeding revision.
Practical evidence check
- Audit one profile change from proposal through fixtures, deployment, changed conclusions, partner communication and rollback readiness.
- Return to chapter contents
Build a datatype-profile manifest
List every recognised datatype IRI, authoritative specification, version and supported lexical, equality, ordering and serialization operations. Name exclusions and extensions explicitly.
Record parser, reasoning engine, hash of fixtures, limits and fallback behaviour. A short profile identifier should resolve to this complete contract.
Include unknown, ill-typed, boundary and equivalent-value examples so support claims are executable rather than promotional.
Review the manifest after upgrades and publish changed conclusions before mixed-version systems exchange authoritative data.
Create an entailment evidence record
Store source graph identifier, target claim, regime, recognised set, processor and time. Link every conclusion to the rule and source terms that support it.
Record alternatives: explicit-only result, weaker profile result and any expression errors. This shows whether the conclusion depends on datatype recognition.
Retain a reproducible fixture and expected output. If protected data cannot be copied, keep a lawful redacted case plus a secure reference.
Mark invalidation events such as data correction, rule withdrawal or profile replacement; never leave a derived claim detached from its conditions.
Audit profile disagreement between processors
Run the same corpus through both systems and classify differences as parsing, recognition, lexical mapping, value equality, query error or resource policy.
Use one ordinary case, one boundary case and one intentionally inconsistent case. Compare diagnostics as well as final answers.
Do not settle disagreement by majority vote. Return to the normative datatype rule and the declared capability of each profile.
Publish a compatibility matrix and a safe intersection for exchange, then schedule fixes for unjustified divergence.
Design semantic repair without rewriting history
Keep the asserted literal and provenance immutable. Generate proposed lexical or datatype corrections in a separate review object.
Require evidence for intent, especially where several values are plausible. Show how each proposal changes entailments and downstream decisions.
Apply an authorised update as a versioned change set and invalidate derived products. Preserve who approved it and why.
Re-run validation and entailment, then notify affected consumers if earlier conclusions used the inconsistent value.
Run a recognised-set change audit
Start with one live or realistic workflow and diff every newly interpreted or newly inconsistent record after changing the datatype profile. Define the decision, evidence owner, time boundary and people affected before selecting a metric. Preserve original records so the exercise can be challenged and repeated.
Work one ordinary case and one boundary case through the same procedure. Record rejected interpretations, missing information, dissent and the consequence of delay or error. A neat final answer is not evidence that the path was justified.
Stress-test the result by changing one material assumption at a time. Identify what remains stable, what reverses and what becomes unresolved. Do not turn missing evidence into a hidden default merely to complete the table.
Close with an owner, correction route, retention rule and review date. Publish useful reasons at the level permitted by privacy, security and law, and verify that another authorised reviewer can reproduce where judgement entered.
Test safe diagnostic disclosure
Start with one live or realistic workflow and verify that error messages identify the rule without exposing protected lexical values. Define the decision, evidence owner, time boundary and people affected before selecting a metric. Preserve original records so the exercise can be challenged and repeated.
Work one ordinary case and one boundary case through the same procedure. Record rejected interpretations, missing information, dissent and the consequence of delay or error. A neat final answer is not evidence that the path was justified.
Stress-test the result by changing one material assumption at a time. Identify what remains stable, what reverses and what becomes unresolved. Do not turn missing evidence into a hidden default merely to complete the table.
Close with an owner, correction route, retention rule and review date. Publish useful reasons at the level permitted by privacy, security and law, and verify that another authorised reviewer can reproduce where judgement entered.
Measure cross-engine reproducibility
Start with one live or realistic workflow and reproduce value mappings and entailments on an independent conforming implementation. Define the decision, evidence owner, time boundary and people affected before selecting a metric. Preserve original records so the exercise can be challenged and repeated.
Work one ordinary case and one boundary case through the same procedure. Record rejected interpretations, missing information, dissent and the consequence of delay or error. A neat final answer is not evidence that the path was justified.
Stress-test the result by changing one material assumption at a time. Identify what remains stable, what reverses and what becomes unresolved. Do not turn missing evidence into a hidden default merely to complete the table.
Close with an owner, correction route, retention rule and review date. Publish useful reasons at the level permitted by privacy, security and law, and verify that another authorised reviewer can reproduce where judgement entered.
Map inference dependencies
Start with one live or realistic workflow and link every materialised conclusion to source terms, datatype rules and profile version. Define the decision, evidence owner, time boundary and people affected before selecting a metric. Preserve original records so the exercise can be challenged and repeated.
Work one ordinary case and one boundary case through the same procedure. Record rejected interpretations, missing information, dissent and the consequence of delay or error. A neat final answer is not evidence that the path was justified.
Stress-test the result by changing one material assumption at a time. Identify what remains stable, what reverses and what becomes unresolved. Do not turn missing evidence into a hidden default merely to complete the table.
Close with an owner, correction route, retention rule and review date. Publish useful reasons at the level permitted by privacy, security and law, and verify that another authorised reviewer can reproduce where judgement entered.
Plan profile retirement
Start with one live or realistic workflow and identify consumers, cached products, rollback evidence and a date for removing obsolete semantics. Define the decision, evidence owner, time boundary and people affected before selecting a metric. Preserve original records so the exercise can be challenged and repeated.
Work one ordinary case and one boundary case through the same procedure. Record rejected interpretations, missing information, dissent and the consequence of delay or error. A neat final answer is not evidence that the path was justified.
Stress-test the result by changing one material assumption at a time. Identify what remains stable, what reverses and what becomes unresolved. Do not turn missing evidence into a hidden default merely to complete the table.
Close with an owner, correction route, retention rule and review date. Publish useful reasons at the level permitted by privacy, security and law, and verify that another authorised reviewer can reproduce where judgement entered.
Questions readers ask
Is datatype entailment always enabled?
- No. A processor or service must declare the entailment regime and the datatype IRIs it recognises.
Is an unknown datatype invalid?
- Not merely because it is unknown to one processor. The RDF term can be preserved while value-level conclusions are withheld.
Can two different lexical forms have the same value?
- Yes, for datatypes whose lexical-to-value map assigns them the same value; they remain distinct RDF terms.
Does inconsistency mean the file cannot be parsed?
- No. Semantic inconsistency under a profile is distinct from RDF syntax failure.
Do all SPARQL engines answer the same under D-entailment?
- Only when they implement compatible regimes, datatype profiles, query features and error rules.
What should a profile publish?
- Recognised datatype maps, versions, supported operations, limits, failure behaviour and executable fixtures.
Practise, verify and continue
Create two recognition profiles for the same four-literal graph. Predict term identity, value equality, inconsistency and query results under each; run the fixtures; and write an evidence record for every difference.
Apply the same method to a code system or measurement registry. Separate identifier recognition, value mapping, supported operations, versioning and application policy.
Related eduKate reading
RDF 1.2 ill-typed literals and validation boundaries
RDF 1.2 literal identity and value-space comparison
RDF dataset canonicalisation and verifiable graphs
SHACL validation reports and constraint evidence
Authoritative sources and scope
W3C, RDF 1.2 Semantics
W3C, RDF 1.2 Concepts and Abstract Data Model
W3C, What’s New in RDF 1.2
W3C, SPARQL 1.2 Entailment Regimes
W3C, RDF 1.2 Primer
This article explains standards-based semantics and implementation governance; it is not a substitute for the normative specifications or system-specific conformance testing. RDF 1.2 publications, implementation support and application profiles can evolve. Every operational claim should name the document version, entailment regime, recognised datatype set, processor and options. Examples are original teaching cases. They show how to reason about recognition and inconsistency, not that a particular product behaves in exactly that way. Unknown, ill-typed, inconsistent, invalid under an application profile and rejected by a workflow are different states. Preserve asserted terms and provenance, contain unsafe derived results, protect sensitive values in diagnostics and provide correction routes. A successful entailment check supports only the named conclusion under the named semantics; it does not establish source truth, completeness or fitness for every decision. Re-test after upgrades, profile changes and data repairs, and keep derived claims linked to the conditions that support them.