Skip to content
wiki.fftac.org

Prophecy Tracking Knowledge Graph Design - Source Excerpt 04 - Review Workflow

Back to Prophecy Tracking Knowledge Graph Design

Summary

This source excerpt begins near Review Workflow and preserves the surrounding evidence from Antichrist.net/agent-file-handoff/Archive/2026-05-12-content-reports/Prophecy-Tracking Knowledge Graph Design.md.

**Source path:** Antichrist.net/agent-file-handoff/Archive/2026-05-12-content-reports/Prophecy-Tracking Knowledge Graph Design.md

## Review Workflow

### Status model and reviewer roles

A review workflow should be explicit and enumerable. A practical status set is:

| Status | Meaning |
|---|---|
| `ingested` | source registered, not yet extracted |
| `extracted` | machine extraction complete |
| `linked` | entity/time/place normalization applied |
| `auto_flagged` | contradiction or ambiguity alert generated |
| `under_review` | assigned to human reviewer |
| `verified` | accepted as adequately supported |
| `rejected` | extraction or link judged incorrect |
| `disputed` | reviewers disagree; requires adjudication |
| `superseded` | replaced by a later reviewed version |
| `archived` | retained for history, not active |

This level of workflow granularity is not dictated by a single standard, but it fits well with PROV-style provenance and SHACL-style validation outcomes. citeturn19view0turn25view0

Reviewer roles should be formalized under RBAC. At minimum, use `ingest_operator`, `annotator`, `reviewer`, `adjudicator`, and `administrator`. NIST’s RBAC model is a good basis for hierarchical and constrained roles, particularly because prophecy-tracking systems often need separation between content entry, content review, and dispute finalization. citeturn23view1turn23view2

### Provenance tracking, audit logs, and dispute resolution

Every status transition and every reviewer action should be durable and queryable. The log entry should capture the target record, old status, new status, actor, timestamp, rationale, evidence set used, and whether the decision supersedes a prior one. OWASP’s guidance on consistent application logging is useful here, and SHACL validation reports provide a complementary model for machine-generated findings that can be stored alongside human decisions. citeturn23view0turn25view0

For disputes, use a staged process: one reviewer issues an initial decision, a second reviewer can confirm or challenge it, and an adjudicator resolves unresolved disagreement with a written rationale. The adjudication record should not overwrite earlier positions; it should supersede them. That lets the graph preserve interpretive history rather than pretending the disagreement never existed. PROV-O and PAV both support the provenance patterns needed for this. citeturn19view0turn19view12

A particularly important policy for this domain is to avoid collapsing theological disagreement into a system “truth score.” The workflow should verify whether a claim is well-sourced, well-normalized, and internally consistent with the graph schema; it should not claim to adjudicate spiritual truth. That posture is more consistent with human-oversight principles in AI ethics and is safer for culturally sensitive content. citeturn19view13

## Storage Query and Export

### Storage design options

The storage choice should follow the project’s priorities.

| Option | Best for | Main strengths | Main tradeoffs | Representative systems |
|---|---|---|---|---|
| Property graph | analyst UX, graph traversal, intuitive operational queries | expressive pattern matching in Cypher; strong ecosystem for analyst workflows | weaker native standards story for named-graph provenance and ontology interchange | Neo4j |
| RDF/OWL triplestore | semantic interoperability, validation, linked-data publication | SPARQL, OWL reasoning, SHACL validation, named graphs, JSON-LD/Turtle exports | steeper modeling overhead for teams unfamiliar with RDF | Apache Jena/Fuseki, GraphDB |
| Dual-model graph | mixed operational + standards requirements | one environment can support openCypher and SPARQL | still requires careful logical model discipline | Amazon Neptune |

This comparison is grounded in the official platform and standards documentation: Neo4j positions Cypher and the property graph model as intuitive pattern-query tools; Apache Jena provides RDF, SPARQL, OWL, inference, and Fuseki endpoints; and Neptune supports property-graph query languages plus SPARQL for RDF. citeturn34view1turn34view0turn19view8

For this use case, the most future-proof architecture is: **canonical assertion layer in RDF/OWL with named graphs + optional property-graph projection for analysts**. If the team wants to minimize moving parts, a dual-model platform can be a pragmatic compromise. If the team prioritizes analyst productivity over standards, start in a property graph but keep the logical schema compatible with later RDF export. citeturn19view1turn19view2turn19view4turn19view8

### SHACL and schema enforcement

Use SHACL to enforce graph rules that matter operationally: every `PredictionClaim` must have provenance; every `Passage` must have a source locator; every `ContradictionAssertion` must identify two claims, a method, and a score; and every `verified` record must have a corresponding `ReviewDecision`. SHACL is designed for validation of a data graph against a shapes graph and returns a structured validation report with conformance and result objects. citeturn25view0

### Example Cypher queries

The following Cypher examples assume a property-graph projection of the logical model.

' ' ' cypher
// Find verified contradictions for a given prophecy statement
MATCH (ps:ProphecyStatement {kg_id: $prophecyId})-[:NORMALIZES_TO]->(c1:PredictionClaim)
MATCH (ca:ContradictionAssertion)-[:CLAIM_A]->(c1)
MATCH (ca)-[:CLAIM_B]->(c2:PredictionClaim)
MATCH (ca)-[:REVIEWED_BY]->(rv:ReviewDecision {status: 'verified'})
RETURN ca.kg_id AS contradiction_id,
       c1.canonical_form AS claim_a,
       c2.canonical_form AS claim_b,
       ca.contradiction_score AS score,
       rv.reviewed_at AS reviewed_at,
       rv.rationale AS rationale
ORDER BY ca.contradiction_score DESC;
' ' ' 

' ' ' cypher
// Timeline of interpreted fulfillment events for a text work
MATCH (tw:TextWork {kg_id: $textWorkId})-[:HAS_EXPRESSION]->(:TextExpression)-[:HAS_PASSAGE]->(:Passage)
      -[:EVIDENCES]->(:ProphecyStatement)-[:INTERPRETED_AS]->(ic:InterpretationClaim)-[:REFERS_TO]->(e:Event)
RETURN e.kg_id AS event_id,
       e.label AS event_label,
       e.start_time AS start_time,
       e.end_time AS end_time,
       e.place_id AS place_id,
       ic.confidence AS interpretation_confidence
ORDER BY e.start_time;
' ' ' 

' ' ' cypher
// Provenance trail for a claim
MATCH (c:PredictionClaim {kg_id: $claimId})-[:GENERATED_BY]->(run:ExtractionRun)
OPTIONAL MATCH (c)<-[:NORMALIZES_TO]-(ps:ProphecyStatement)<-[:EVIDENCES]-(p:Passage)-[:ANCHORED_IN]->(s:SourceDocument)
OPTIONAL MATCH (c)<-[:TARGET]-(rv:ReviewDecision)
RETURN c.kg_id, c.canonical_form,
       run.pipeline_version, run.model_name, run.model_version, run.run_at,
       p.locator, s.title, s.source_type,
       collect(DISTINCT rv.status) AS review_statuses;
' ' ' 

These examples match the strengths of Cypher as a declarative query language for property graphs and as a compact pattern-matching syntax. citeturn34view1

### Example SPARQL queries

The following SPARQL examples assume the canonical RDF layer uses named graphs or nanopublication-like packaging.

' ' ' sparql
PREFIX ex:   <http://example.org/kg/>
PREFIX prov: <http://www.w3.org/ns/prov#>
PREFIX dct:  <http://purl.org/dc/terms/>

SELECT ?contradiction ?claimA ?claimB ?score ?reviewedAt ?sourceTitle
WHERE {
  GRAPH ?g {
    ?contradiction a ex:ContradictionAssertion ;
                   ex:claimA ?claimA ;
                   ex:claimB ?claimB ;
                   ex:contradictionScore ?score .
  }
  GRAPH ?reviewGraph {
    ?review a ex:ReviewDecision ;
            ex:target ?contradiction ;
            ex:status "verified" ;
            dct:date ?reviewedAt .
  }
  GRAPH ?provGraph {
    ?claimA prov:wasDerivedFrom ?source .
    ?source dct:title ?sourceTitle .
  }
}
ORDER BY DESC(?score)
' ' ' 

' ' ' sparql
PREFIX ex:   <http://example.org/kg/>
PREFIX time: <http://www.w3.org/2006/time#>

SELECT ?event ?label ?begin ?end ?place
WHERE {
  ?ic a ex:InterpretationClaim ;
      ex:interprets ex:ps_osa_3_14 ;
      ex:refersTo ?event .
  ?event a ex:Event ;
         ex:label ?label ;
         ex:occursAt ?place ;
         time:hasBeginning/time:inXSDDateTime ?begin ;
         time:hasEnd/time:inXSDDateTime ?end .
}
ORDER BY ?begin
' ' ' 

' ' ' sparql
PREFIX np:   <http://www.nanopub.org/nschema#>
PREFIX prov: <http://www.w3.org/ns/prov#>

SELECT ?g ?s ?p ?o
WHERE {
  {
    GRAPH ?head {
      ?np a np:Nanopublication ;
          np:hasAssertion ?g .
    }
  }
  UNION
  {
    GRAPH ?head {
      ?np a np:Nanopublication ;
          np:hasProvenance ?g .
    }
  }
  GRAPH ?g { ?s ?p ?o }
}
' ' ' 

SPARQL, RDF datasets with named graphs, and nanopublication structures are well suited to provenance-rich assertion publishing and query. citeturn19view2turn19view1turn29view0

### Export patterns

For export, support **three first-class serializations**.
Website health report