THE GOLD STANDARD OF INFORMATION · SPECIALIST STUDY
Preview a graph change, test what it would affect and approve a repair plan before the live update crosses the point of no easy return
A syntactically valid SPARQL Update can still target the wrong graph, match a wider population than intended, violate a shape, erase provenance or leave no usable recovery route. A credible preflight therefore does more than run the WHERE clause once. It freezes the intended dataset view, proves authority, computes candidate bindings, materialises a preview in an isolated workspace, compares canonical before-and-after evidence, validates both the proposed state and the change boundary, estimates operational impact, defines rollback and reconciliation conditions, and records a human-readable approval receipt. The gold standard treats a dry run as evidence about a declared snapshot—not as a guarantee that the live store will remain unchanged until execution.
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–8
Handle limits and disagreement · chapters 9–11
Transfer and govern · chapters 12–13
The whole problem at a glance
| Stage | Question | Evidence |
|---|---|---|
| Authority | May this actor change these graphs? | Scoped approval |
| Selection | Which bindings qualify? | Frozen candidate set |
| Effect | Which triples and graphs differ? | Canonical diff |
| Safety | Is the result acceptable? | Validation and rollback receipt |
Passing one stage does not imply the others passed.
CHAPTER 1 OF 13 · Build the foundations
1. Separate preflight from execution
Core idea. A preflight is a controlled prediction of an update against a declared dataset state. Execution is a later mutation under live concurrency, permissions and service conditions. Conflating them turns a useful rehearsal into false certainty.
Method. Record a preflight identifier, update digest, dataset version, shapes version, graph scope, actor, time, expiry and proposed execution window. Require the executor to verify that the approved evidence still applies.
Worked example. A curator previews a correction against snapshot s-884 at 10:00. At 10:12 another writer changes three matched records, so the executor refuses the stale approval instead of applying it blindly.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. Some stores expose no snapshot token and some federated data cannot be frozen. In that case narrow the claim, shorten validity and re-evaluate immediately before mutation.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 1 is complete only when the claimed result survives that review.
Misconception to avoid. A dry run proves the live update is safe. It proves only what the rehearsal actually observed.
Practical evidence check
- Change one matched record after preflight and confirm the stale-evidence guard blocks execution.
- Return to chapter contents
CHAPTER 2 OF 13 · Build the foundations
2. Define authority, graph scope and change budget
Core idea. Safety begins with who may change which graph, predicates and number of resources. A technically correct query can still exceed the mandate that justified it.
Method. Bind approval to named graphs, operation kinds, predicate allowlists, maximum bindings, maximum inserted and deleted triples, maintenance window and accountable owner. Deny rather than silently widen scope.
Worked example. A vocabulary correction may change labels in one catalogue graph but may not rewrite provenance, access-control or archived graphs. A budget of fifty resources stops an unexpected broad match.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. Graph aliases, default-graph configurations and dataset views can hide scope. Verify the service’s actual dataset mapping and record unresolved ambiguity.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 2 is complete only when the claimed result survives that review.
Misconception to avoid. A role that can send UPDATE is authorised for every possible update. Capability and policy authority are different facts.
Practical evidence check
- Attempt the preview through an account with narrower permissions and compare visible target graphs.
- Return to chapter contents
CHAPTER 3 OF 13 · Apply the core method
3. Compile the WHERE clause into a candidate ledger
Core idea. The WHERE clause determines solution bindings before DELETE and INSERT templates are instantiated. A candidate ledger makes that selection inspectable before any mutation occurs.
Method. Run a SELECT using the same dataset clauses, filters and bindings as the update. Persist stable identifiers, relevant old values, graph names and a digest; never rely on row order alone.
Worked example. A DELETE/INSERT correcting 42 records produces a ledger with record IRI, old code, proposed code and source graph. Reviewers can sample the actual population.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. Blank nodes, volatile functions, SERVICE calls and concurrent data can make a later evaluation differ. Flag nondeterminism and remote dependencies explicitly.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 3 is complete only when the claimed result survives that review.
Misconception to avoid. A SELECT that looks similar is automatically equivalent to the update WHERE clause. Tiny dataset or filter differences can change the population.
Practical evidence check
- Generate both from one parsed update plan and compare algebra or canonical request digests.
- Return to chapter contents
CHAPTER 4 OF 13 · Apply the core method
4. Materialise the proposed state in isolation
Core idea. A useful dry run constructs the state that would exist after the change, preferably in a transaction, disposable dataset or copied named graph. It should not simulate only counts.
Method. Apply the exact operations to an isolated clone or transactional workspace, preserve graph identity and record software configuration. Block outbound side effects and remote writes.
Worked example. The candidate update runs on a copy of urn:catalog:live. The preview exposes two new dangling references that a row-count check would miss.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. Large stores may be expensive to clone, and partial extracts can omit constraints. Use graph slices only when their completeness assumptions are explicit.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 4 is complete only when the claimed result survives that review.
Misconception to avoid. Matching the expected insert and delete counts proves semantic correctness. Relationships and constraints can fail even when counts agree.
Practical evidence check
- Query the preview for both intended changes and forbidden invariants, then compare with the original.
- Return to chapter contents
CHAPTER 5 OF 13 · Apply the core method
5. Compute semantic before-and-after diffs
Core idea. RDF diffs are complicated by blank-node labels, entailment and serialisation order. Text diffs of Turtle files can report noise or miss meaning.
Method. Use stable IRIs where possible, canonicalise scoped blank-node subgraphs, compare graph-aware triple sets and keep asserted and inferred views separate. Summarise by graph, predicate and resource.
Worked example. A preview deletes 42 obsolete codes and inserts 42 corrected codes, but also changes four inferred classifications. The receipt reports both asserted and entailed effects.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. Canonicalisation and entailment regimes can be costly or implementation-specific. State the algorithm, scope and regime rather than claiming a universal semantic diff.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 5 is complete only when the claimed result survives that review.
Misconception to avoid. Two serialised files that differ line by line represent different RDF graphs. Triple order and prefix choices are not meaning.
Practical evidence check
- Shuffle serialisation and prove the semantic diff remains unchanged.
- Return to chapter contents
Worked change preview
| Check | Preview result | Decision |
|---|---|---|
| Target graph | urn:catalog:live | Correct |
| Matched records | 42 | Below approved cap |
| SHACL result | Two violations | Stop and repair |
| Rollback source | Snapshot s-884 | Available and verified |
The two violations remain visible in the approval record.
CHAPTER 6 OF 13 · Test evidence and alternatives
6. Validate the proposed state with versioned SHACL
Core idea. SHACL validation can test focus nodes, paths and constraints against the proposed data graph. Its result depends on the shapes graph, entailment assumptions and processor behavior.
Method. Record the shapes version, target selection, severity policy, processor and validation report. Validate both changed resources and any dependent neighbourhood required by the constraints.
Worked example. A correction passes datatype and cardinality checks but fails a class constraint on two linked resources. The update is held until the source mapping is repaired.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. A passing report covers only declared shapes; deactivated constraints, unsupported extensions and incomplete targets remain outside the claim.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 6 is complete only when the claimed result survives that review.
Misconception to avoid. SHACL conformance proves the graph is correct. It proves only conformance to the tested shapes under the declared setup.
Practical evidence check
- Remove one critical shape and show how the same proposed graph changes from nonconformant to conformant.
- Return to chapter contents
CHAPTER 7 OF 13 · Test evidence and alternatives
7. Validate the change boundary, not only the final graph
Core idea. A final state can satisfy every shape while the update still changes forbidden records or deletes evidence that should have been retained. Change constraints inspect the delta itself.
Method. Add rules such as no provenance deletion, no modification outside the candidate ledger, no new blank-node identities and exact correspondence between approved bindings and affected resources.
Worked example. The preview remains SHACL-conformant but deletes six audit triples. A delta rule catches the governance breach that state validation misses.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. Delta policies are project-specific and can be incomplete. Treat them as a separate, versioned control layer.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 7 is complete only when the claimed result survives that review.
Misconception to avoid. If the end state validates, the route taken to reach it is acceptable. History, authority and retention rules may say otherwise.
Practical evidence check
- Create two updates with the same end state but different deletions and prove the receipts distinguish them.
- Return to chapter contents
CHAPTER 8 OF 13 · Test evidence and alternatives
8. Measure cost, locks and operational risk
Core idea. A semantically safe update may still overload the service, hold locks, invalidate caches or exceed a maintenance window. Operational feasibility belongs in preflight evidence.
Method. Estimate candidate cardinality, graph size, query plan, transaction footprint, timeout, index work and cache effects. Test representative scale and set hard abort thresholds.
Worked example. A 42-record change is cheap in a sample but expensive when the WHERE clause scans every graph. An explain plan and timed rehearsal reveal the mismatch.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. Plans can change with statistics and concurrent load. Measurements are conditional, not promises.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 8 is complete only when the claimed result survives that review.
Misconception to avoid. Small output means small operational cost. Selection and entailment may dominate the work.
Practical evidence check
- Repeat the rehearsal with cold and warm caches and report both.
- Return to chapter contents
Change approval receipt
| Claim | Evidence | Boundary |
|---|---|---|
| Intent fixed | Request digest and ticket | Authorised window |
| Effect previewed | Before/after graph digests | Snapshot time |
| Constraints checked | SHACL report | Shapes version |
| Recovery prepared | Restore test and owner | External side effects |
A receipt supports later reconciliation; it is not a warranty.
CHAPTER 9 OF 13 · Handle limits and disagreement
9. Design rollback before approval
Core idea. Rollback is not merely the inverse text of an update. It requires a trustworthy before-state, scope, ordering, authority and treatment of concurrent changes.
Method. Choose transaction abort, snapshot restore, compensating update or graph swap. Verify restore permissions, retention, checksum and time objective; define when rollback is unsafe.
Worked example. A named graph swap can restore the catalogue atomically, while external search indexing needs a separate reconciliation job and cannot be rolled back by SPARQL alone.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. Other writers may create legitimate changes after execution. Restoring an old full snapshot could erase them, so compensation or selective reversal may be safer.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 9 is complete only when the claimed result survives that review.
Misconception to avoid. Every DELETE/INSERT has an obvious inverse. Blank nodes, generated values and outside systems can make inversion ambiguous.
Practical evidence check
- Apply the update in staging, introduce a concurrent legitimate edit, and test the chosen recovery path.
- Return to chapter contents
CHAPTER 10 OF 13 · Handle limits and disagreement
10. Handle disagreements and exceptions visibly
Core idea. Reviewers may disagree about acceptable violations, severity, sampling, change budget or recovery. Approval should preserve that disagreement rather than collapse it into one unexplained click.
Method. Require named dispositions for each exception: repair, waive with reason and expiry, narrow the update, or escalate. Keep minority concerns and evidence links in the receipt.
Worked example. Two SHACL warnings are accepted for legacy records until migration date; one violation blocks execution. The distinction is explicit and time-bounded.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. Urgent response may justify a lighter process, but emergency authority, scope and retrospective review still need records.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 10 is complete only when the claimed result survives that review.
Misconception to avoid. Approval means every reviewer believes the update is risk-free. It means the declared decision rule was satisfied.
Practical evidence check
- Ask a second reviewer to reproduce the decision from the receipt without verbal context.
- Return to chapter contents
CHAPTER 11 OF 13 · Handle limits and disagreement
11. Recheck preconditions at the execution gate
Core idea. Between rehearsal and execution, data, permissions, shapes, service version or graph aliases can change. The gate decides whether the earlier evidence is still applicable.
Method. Compare dataset token or relevant graph digests, candidate ledger, actor scope, shapes digest, update digest and time window. Abort or rerun preflight on material drift.
Worked example. At execution, the candidate count rises from 42 to 45. The gate does not silently expand; it opens a new preview and approval cycle.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. Without version tokens, complete drift detection may be impossible. Use scoped ASK checks and digest samples, then state the residual race.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 11 is complete only when the claimed result survives that review.
Misconception to avoid. Human approval remains valid until someone revokes it. Evidence can expire even when people do not change their minds.
Practical evidence check
- Mutate one shape after approval and verify the gate detects the version mismatch.
- Return to chapter contents
CHAPTER 12 OF 13 · Transfer and govern
12. Publish an execution and reconciliation receipt
Core idea. After execution, the organisation needs to know what was attempted, acknowledged, observed and still uncertain. The preflight receipt should connect to the actual outcome.
Method. Record operation key, approved evidence, request and response, server identity, execution time, resulting graph digests, validation report, deviations, rollback state and reviewer.
Worked example. The server returns success, postconditions match 42 records and the final SHACL report passes. A delayed index is marked pending rather than implied complete.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. Some stores expose weak audit evidence and a network failure can obscure completion. Reconciliation may require authoritative reads and manual review.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 12 is complete only when the claimed result survives that review.
Misconception to avoid. A 2xx response is the final proof of every downstream effect. It acknowledges only the service boundary it actually covers.
Practical evidence check
- Drop the client connection after sending and use the receipt design to recover the outcome.
- Return to chapter contents
CHAPTER 13 OF 13 · Transfer and govern
13. Transfer the method to other controlled changes
Core idea. The same sequence—authority, candidate ledger, isolated effect, semantic diff, constraints, recovery, gate and receipt—applies to schema migrations, access rules and bulk metadata repair.
Method. Map each domain’s objects, invariants, side effects and recovery boundary before reusing the checklist. Keep names concrete so the process remains inspectable.
Worked example. A CSV-to-RDF migration previews affected graphs, validates required identifiers and rehearses restoration, while a policy update adds a separate access simulation.
Changed-context transfer. Changed-context transfer: apply the same reasoning structure to a school or public-service decision. Preserve the formal relationship, then replace the population, authority, privacy duties, evidence and remedy; never copy the domain conclusion.
Limits. No generic workflow removes the need for domain review or vendor-specific testing. High-consequence changes may require independent assurance.
Evidence and review. For this chapter, keep a dated evidence record: the input, rule or assumption, result, accountable owner and a condition that would change the conclusion. Work an ordinary case and a boundary case, preserve rejected alternatives, and require an authorised independent reader to reproduce where judgement entered. Chapter 13 is complete only when the claimed result survives that review.
Misconception to avoid. A successful catalogue update proves the workflow works unchanged everywhere. Transfer requires a changed-context check.
Practical evidence check
- Apply the checklist to a graph-rename operation and identify which evidence fields must change.
- Return to chapter contents
Build the specialist decision record
For “The Gold Standard of Information | SPARQL Update Preflight, Dry Runs, Affected-Graph Diffs, SHACL Validation, Rollback Plans and Change Approval”, begin with one bounded decision rather than an abstract claim. Name the affected people, data or institutions; the time window; the authority for acting; and the conclusion the method is allowed to support.
Preserve source material before interpretation. Record definitions, exclusions, transformations and the person responsible for each judgement. A reviewer should be able to separate an observed fact from an inferred result, a policy choice and a presentation shortcut.
Work one ordinary case in full. Show the input, every material rule or calculation, the output and the action that follows. Then write what the same evidence would mean under the simplest credible alternative method.
Keep an explicit unresolved state. Missing, protected, conflicting or unevaluated information must not become zero, false, consent or absence merely because a form expects one value.
Finish the record with a claim ledger. For every sentence that could drive action, identify its supporting source, inferential step, confidence or legal status, intended reader and expiry condition. This keeps descriptive evidence, formal consequence, professional judgement and institutional authority from collapsing into one impressive-looking conclusion.
Run the boundary-case audit
Select a case near the method’s domain edge: a missing input, a disputed definition, an endpoint, a sparse group, a resource limit or a legal deadline. Boundary cases reveal the contract that routine examples can conceal.
Change one assumption at a time and retain every output. Mark what stays stable, what reverses and what becomes undefined. If several assumptions move together, report that dependence instead of attributing the change to one convenient cause.
Search deliberately for a counterexample to the strongest claim. A method that works on the published illustration can still fail under a permitted input, an alternative grouping, a changed unit or an inaccessible evidence pathway.
Translate the counterexample into plain language: who would receive a different decision, what evidence would be hidden, and which safeguard or narrower claim repairs the problem.
Include an adversarial but plausible case. Let a missing group, ambiguous identifier, extreme weight, conflicting rule or urgent deadline interact with normal system incentives. The aim is not theatrical failure; it is to learn whether ordinary pressure makes the method conceal uncertainty, shift burden or reward a misleading shortcut.
Test independent reproduction
Give a reviewer the bounded inputs, public method contract and permitted access, but not the desired answer. Ask them to reproduce the result and identify every place where judgement, local knowledge or unavailable evidence was required.
Compare the reviewer’s intermediate states, not only the final number or label. Matching outputs can hide different denominators, inference paths, missing-data treatments or authorities that will diverge on the next case.
Where reproduction fails, classify the cause: ambiguous definition, undocumented transformation, incompatible implementation, inaccessible source, calculation error or legitimate alternative interpretation. Each class needs a different remedy.
Retain the disagreement and resolution. A corrected record should show what changed, why it changed and which prior outputs or decisions must be revisited.
Run the reproduction on a changed but structurally similar case after the first discrepancy is repaired. A method is not transferable merely because its authors can explain the original example. The new case tests whether the public contract carries the reasoning or whether hidden expertise is still doing essential work.
Design correction, challenge and remedy
Assign a visible route for correcting inputs, challenging assumptions and reviewing the application of the method. Technical accuracy without a usable remedy leaves the affected person carrying an error they cannot contest.
Separate urgent live-case repair from later system learning. A current decision may need pause, reassignment, fresh evidence or a human review before the organisation finishes its longer investigation.
Protect confidential and privileged material during review, but do not use confidentiality as a reason for unrecorded authority. Layer public explanation, protected oversight and individual reasons according to lawful access.
Verify that correction reaches cached results, derived records, dashboards and future decisions. Closing a complaint is not enough if the old conclusion continues to travel.
Measure remedy from the affected person’s position. A revised database row is useful, but it is incomplete when a hearing, service allocation, published claim or downstream model still relies on the old result. Record notification, restored opportunity, compensation or procedural repair where the governing framework provides it.
Set review and retirement triggers
Review after a change in definitions, population, law, source access, measurement scale, software, vocabulary or incentives. A stable formula can become invalid when the world or the meaning of its inputs changes.
Monitor leading signals as well as final outcomes: coverage gaps, timeouts, overrides, complaints, disagreement, missingness and boundary frequency. These often reveal failure before a headline metric moves.
Predefine thresholds for recalibration, suspension and retirement. Do not force a method to answer after its assumptions fail merely because replacing it is inconvenient.
At retirement, preserve the versioned contract, evidence, known limitations and migration decision. State which historic results remain interpretable and which require warning, restatement or withdrawal.
Schedule one prospective review before confidence fades or controversy forces it. Assign named owners for evidence, implementation and rights impact, and invite at least one reviewer outside the design team. The review should be able to narrow the claim, change the method or stop use without requiring proof of catastrophic failure.
Questions readers ask
Is a dry run the same as a transaction?
- No. A dry run predicts an effect in isolation; a transaction controls the live mutation boundary.
Why validate the delta as well as the final graph?
- The final graph may conform while the update still touched forbidden records or deleted required provenance.
Can SHACL prove the update is correct?
- It proves conformance only to the declared shapes, targets, processor and assumptions.
When should approval expire?
- When the dataset, shapes, authority, update digest, service configuration or approved time window materially changes.
What if the endpoint has no snapshot token?
- Use scoped preconditions and short validity, then state that a residual race remains.
What is the minimum useful receipt?
- Intent, authority, snapshot, candidate set, diff, validation, recovery plan, execution evidence and unresolved limits.
Practise, verify and continue
Choose one consequential case. Reproduce the complete method, work one ordinary and one boundary case, test the strongest rival explanation, and state the evidence that would reverse or suspend the result. Build an evidence pack containing original inputs, definitions, calculations or rule steps, alternatives rejected, uncertainty, reviewer comments and the final action. Give the pack to a reader who did not design the method. Ask that reader to reproduce the result, identify one missing assumption and construct a case that would make the method return unresolved. Revise the public explanation only after the evidence pack and the operational process agree.
Move the method into an education or public-service setting. Keep the reasoning structure while replacing domain authority, population, privacy, evidence and correction routes. Start with a low-stakes historical example, then compare the specialist method with a transparent baseline. Check whether the same people, records and decisions remain inside scope; whether the scale or vocabulary still means the same thing; and whether a person affected by error can understand and challenge it. Pilot under human review, record reversals and burden, and stop the transfer if the formal resemblance hides a different ethical or legal problem.
Related eduKate reading
SPARQL Update replay safety and uncertain completion
SHACL reports, focus nodes and constraint evidence
SPARQL Graph Store Protocol and conditional replacement
Authoritative sources and scope
W3C, SPARQL 1.2 Update Working Draft
W3C Recommendation, SPARQL 1.1 Update
W3C Recommendation, Shapes Constraint Language (SHACL)
This article is information-governance education, not a guarantee for a particular RDF store or a substitute for vendor, security, legal and change-management review. Examples are original teaching cases. Atomicity, isolation, snapshot support, validation behavior, graph identity, rollback and audit evidence depend on implementation and architecture. Test only authorised systems, preserve recovery authority and keep a manual stop-and-reconcile path for consequential changes.