Prophecy-Tracking Knowledge Graph Design

Full report

On this page

Executive Summary

A robust prophecy-tracking knowledge graph should not treat “prophecies” as a single undifferentiated object. The system works best when it separates at least five layers: the text itself, the normalized prediction claim, later interpretation claims, the sources that attest each statement, and the provenance and review metadata explaining how each graph assertion entered the system. That separation maps well to existing standards for RDF datasets, provenance, ontology modeling, validation, temporal modeling, geospatial modeling, and metadata, including RDF 1.1, OWL 2, PROV-O, PAV, SHACL, OWL-Time, GeoSPARQL, Dublin Core, JSON-LD, and Turtle.

The most defensible architecture is statement-centric. In practice, this means modeling each important claim as its own first-class object with a stable identifier, source anchoring, machine and human provenance, version history, confidence score, and review state. Contradictions should also be modeled as first-class assertions rather than as bare edges, because contradiction judgments require provenance, scorer outputs, thresholds, reviewer notes, and occasionally competing interpretations rather than binary “true/false” labels. Named RDF graphs and nanopublication-style packaging are especially useful for this because they let you isolate the assertion, its provenance, and publication metadata.

For extraction, the pipeline should be multimodal and archive-aware: ingest born-digital text, scanned pages, and archive manifests; preserve page, line, and bounding-box anchors; run OCR where needed; then perform entity extraction, entity linking, coreference, relation extraction, event extraction, temporal normalization, geospatial normalization, and claim normalization. Historical and multilingual corpora make archival interfaces and standards like IIIF, Internet Archive item metadata, hOCR, and language tags important, while NLP research shows that document-level relation extraction, cross-document event extraction, temporal tagging, and ambiguity handling all benefit from explicit normalization steps rather than end-to-end black boxes.

Contradiction detection should be hybrid. Symbolic rules are strong at exact conflicts in date, place, negation, quantity, and entity identity; embedding retrieval is strong for candidate generation; and supervised NLI-style contradiction scoring is useful for semantic comparison across paraphrases. But recent work also shows that NLI systems remain brittle, especially on simple or document-level contradictions, so automatic contradiction labels should be treated as triage signals rather than final judgments. Thresholds must be calibrated on a domain-specific validation set, not copied from a benchmark paper.

From an implementation perspective, there is no single mandatory storage stack. Property graphs are strong for analyst workflows and intuitive pattern queries through Cypher; RDF/OWL stores are stronger for standards-based interoperability, SHACL validation, Linked Data publication, and named-graph provenance; and dual-model systems such as Amazon Neptune reduce architectural friction because they support openCypher for property-graph-style querying and SPARQL for RDF. If the project’s long-term goal includes exchange with archives, data publication, and research reuse, a canonical RDF layer with optional projection into a property graph is the cleanest design.

A realistic delivery plan is a staged build over roughly 30 to 46 person-weeks for a solid first production system: schema and governance first, then ingestion and normalization, then contradiction scoring and review tooling, then standards export, visualization, and evaluation. The largest technical risks are not storage or query syntax; they are ambiguity in figurative language, weak historical place normalization, and overconfidence in automatic contradiction detectors. Those risks are manageable if the graph distinguishes text from interpretation, preserves provenance at assertion granularity, and keeps a strong human review workflow.

Data Model and Schema

Recommended modeling approach

The core schema should distinguish between works and passages, claims, interpretations, entities, events, sources, contradiction assertions, and review decisions. This follows the general pattern encouraged by RDF, OWL, PROV-O, Dublin Core, and nanopublication practice: represent the thing itself, the assertion about the thing, and the provenance of that assertion as separate but linked resources.

A good default is to make the atomic normalized claim the centerpiece of the graph. The original passage remains immutable evidence. A prophecy statement node can preserve the wording from a passage, while a prediction claim node represents the normalized proposition extracted from that wording. An interpretation claim then connects a prophecy statement or prediction claim to a proposed referent, event, person, place, or period. This distinction matters because theological, symbolic, and historical interpretive traditions often disagree without necessarily contradicting the original passage text itself. That difference is precisely where provenance and review metadata become most important. This is an architectural inference from the provenance and named-graph standards plus the known difficulty of machine contradiction detection in document-scale settings.

Node types, edge types, and attributes

The following schema is a practical minimum.

This attribute set is consistent with widely used metadata and provenance vocabularies: Dublin Core terms supply resource-level metadata such as creator, date, source, language, spatial and temporal coverage; BCP 47 language tags provide standardized language encoding; OWL-Time supports instants, intervals, and durations; GeoSPARQL supports geospatial representation and querying; and PROV-O plus PAV cover derivation, attribution, authorship, curation, and versioning.

For edges, the essential predicates are: HAS_EXPRESSION, HAS_PASSAGE, MENTIONS, ABOUT, PREDICTS, INTERPRETS, REFERS_TO, CITES, DERIVED_FROM, SUPPORTED_BY, CONTRADICTS, COMPETES_WITH, SUPERSEDES, SAME_AS, LOCATED_IN, OCCURS_DURING, OCCURS_AT, REVIEWED_BY, and GENERATED_BY. In an RDF implementation, many of these can be ordinary predicates, while contradiction judgments, reviewer actions, and machine extraction results are usually better reified as resources or placed into named graphs. In a property graph, ordinary semantic links can be direct relationships, but contradiction and review results still benefit from reification whenever you need per-assertion provenance, scores, or audit history.

Identifiers, provenance, and versioning

Use two identifier layers. The first is a stable conceptual ID for the thing itself, such as a person, place, text work, or canonical claim. The second is a versioned record ID for mutable graph records. In RDF form, the stable ID is an IRI; versions can be related through PAV and Dublin Core versioning terms. In a property graph, store both kg_id and version_id on the node and never overwrite version history destructively.

Every machine-created assertion should carry enough provenance to be replayed or challenged later. The minimum high-value fields are: source_id, passage_id, source_locator, source_checksum, pipeline_version, model_name, model_version, prompt_hash if prompting is used, run_timestamp, extractor_confidence, and wasDerivedFrom. That recommendation follows directly from the role PROV-O and PAV play in provenance interchange and version traceability.

A practical versioning rule is: stable sources and passages are immutable; claims, alignments, contradictions, and review decisions are append-only. If a reviewer changes an interpretation or contradiction ruling, create a new version and link it with SUPERSEDES and a provenance edge rather than rewriting the old one. Nanopublication practice is especially useful here because it explicitly separates assertion, assertion provenance, and publication information in distinct graphs.

Example schema diagram

The diagram below shows a recommended logical model. It is illustrative rather than exhaustive.

classDiagram
    class TextWork {
      kg_id
      canonical_title
      tradition
      tags
    }

    class TextExpression {
      kg_id
      language
      edition
      translator
      publication_date
    }

    class Passage {
      kg_id
      locator
      quoted_text
      token_offsets
      ocr_confidence
    }

    class SourceDocument {
      kg_id
      source_type
      author_or_attributor
      date
      reliability_score
      rights
    }

    class ProphecyStatement {
      kg_id
      statement_text
      literalness_score
      hedge_score
      confidence
    }

    class PredictionClaim {
      kg_id
      canonical_form
      predicate
      polarity
      modality
      confidence
    }

    class InterpretationClaim {
      kg_id
      interpretation_text
      school
      confidence
    }

    class Entity {
      kg_id
      type
      canonical_label
      external_ids
    }

    class Event {
      kg_id
      label
      start_time
      end_time
      place_id
    }

    class ContradictionAssertion {
      kg_id
      relation_type
      contradiction_score
      aligned_facets
      threshold_version
    }

    class ReviewDecision {
      kg_id
      status
      reviewer_role
      reviewed_at
      rationale
    }

    class ExtractionRun {
      kg_id
      pipeline_version
      model_name
      model_version
      prompt_hash
      run_at
    }

    TextWork "1" --> "*" TextExpression : HAS_EXPRESSION
    TextExpression "1" --> "*" Passage : HAS_PASSAGE
    Passage "1" --> "1" SourceDocument : ANCHORED_IN
    Passage "1" --> "*" ProphecyStatement : EVIDENCES
    ProphecyStatement "1" --> "*" PredictionClaim : NORMALIZES_TO
    ProphecyStatement "1" --> "*" InterpretationClaim : INTERPRETED_AS
    PredictionClaim "*" --> "*" Entity : ABOUT
    PredictionClaim "*" --> "*" Event : PREDICTS
    InterpretationClaim "*" --> "*" Entity : REFERS_TO
    InterpretationClaim "*" --> "*" Event : REFERS_TO
    ContradictionAssertion "*" --> "1" PredictionClaim : CLAIM_A
    ContradictionAssertion "*" --> "1" PredictionClaim : CLAIM_B
    ContradictionAssertion "*" --> "*" ReviewDecision : REVIEWED_BY
    PredictionClaim "*" --> "*" ExtractionRun : GENERATED_BY
    InterpretationClaim "*" --> "*" ExtractionRun : GENERATED_BY

The modeling choice to keep Passage, Claim, and ContradictionAssertion separate is strongly supported by provenance and named-graph standards, and it aligns with nanopublication practice for granular, citable assertions.

Illustrative sample records

The table below is synthetic and only illustrates how records can fit together.

Extraction Pipeline

Ingestion from web, OCR, and archives

A prophecy-tracking KG needs an ingestion layer that can handle born-digital documents, scanned manuscripts, archive facsimiles, and derivative PDFs without discarding layout evidence. IIIF Presentation API manifests are useful for interoperable access to compound digital objects and their navigable structure, while the Internet Archive Metadata API and OCR pipeline expose item metadata, OCR artifacts, hOCR files, searchable text, and page-level indexes. Tesseract and TrOCR are both relevant OCR options: Tesseract is widely used and can emit hOCR, TSV, ALTO, PAGE, and searchable PDF output, and TrOCR is a modern transformer-based OCR approach for end-to-end text recognition.

For scanned or archival texts, the system should store four parallel artifacts for every ingestible document whenever feasible: the source image or PDF, the extracted text, the page/line or bounding-box anchor, and the ingest/OCR metadata. Internet Archive’s hOCR design is a good model here because it explicitly preserves text, word-level bounding boxes, per-word confidence, page indexing, and searchable derivatives. In a prophecy-tracking workflow, those anchors are important because later reviewers often need to inspect an exact page, line, or image crop to judge transcription quality or interpretive ambiguity.

NLP pipeline for entities, claims, relations, and events

A practical NLP stack should be staged rather than monolithic. The first pass performs language identification, sentence and passage segmentation, quote detection, and canonicalization. The second pass does entity mention detection, entity linking, and coreference. The third pass performs relation extraction and event extraction. The fourth pass converts raw passages into normalized propositions suitable for graph insertion. Research on document-level relation extraction and cross-document event extraction is important here because many prophecy interpretations depend on information dispersed across multiple sentences or sources, not on one sentence alone.

For general linguistic preprocessing, toolkits such as Stanford CoreNLP remain useful because they bundle tokenization, sentence splitting, parsing, named entities, and coreference into a consistent processing framework. For relation extraction, DocRED is still a relevant benchmark because it explicitly addresses multi-sentence relations in plain text. For cross-document event assembly, recent work on CDEE pipelines is especially relevant to the prophecy domain because it decomposes the task into event extraction, coreference resolution, entity normalization, role normalization, and entity-role resolution across many documents.

Claim normalization should convert each extracted proposition into a slot-based representation such as:

subject | predicate | object | polarity | modality | time interval | place | quantity | source anchor

That form makes downstream contradiction checks tractable and separates wording variance from semantic variance. A passage like “the city shall fall” can remain as a ProphecyStatement, while its normalized PredictionClaim becomes something like CityX FALL polarity=positive time=uncertain. This normal form is an implementation recommendation derived from the strengths and limitations of relation extraction, event extraction, and contradiction detection research.

Temporal and geospatial normalization

Temporal normalization should use explicit intervals, not only single dates. OWL-Time provides a vocabulary for instants, intervals, durations, and ordering relations, while HeidelTime and TempEval remain practical references for extracting and normalizing temporal expressions. For prophecy corpora, many references will be partial or uncertain, so the model should support not_before, not_after, earliest_possible, latest_possible, and calendar/source qualifiers rather than coercing everything into ISO dates.

Place normalization should similarly separate mention strings from canonical places. GeoSPARQL supports geospatial RDF representation and query, GeoNames provides a practical modern gazetteer API, and historical or sacred corpora often require ancient-place resources such as Pleiades. This means a prophecy claim should typically store both the raw place mention and the resolved gazetteer ID, with uncertainty when matching is weak.

Handling ambiguity, metaphor, and translation

Figurative or ambiguous language should not be flattened into literal event claims too early. Metaphor detection research shows that contextual word meaning often diverges from basic meaning, and hedge detection research shows that uncertainty cues remain lexically important and domain-sensitive. In system terms, when a passage is metaphor-heavy, hedged, or strongly interpretive, the graph should create an InterpretationClaim or AmbiguousClaim and route it to review instead of auto-promoting it to a high-confidence PredictionClaim.

Translation should also be modeled explicitly. Each translation or edition should be a TextExpression linked to a TextWork, with its own language, translator metadata, and provenance. Use BCP 47 language tags for normalized storage even if the ingest source originally uses ISO or MARC codes. Preserving the expression layer matters because contradictions can arise from translation choices rather than from the source text itself.

Contradiction Detection

Formal definitions

The graph should distinguish at least three different conflict types.

A strict contradiction exists when two normalized claims refer to the same subject and predicate, are aligned in relevant qualifiers such as time and place, and assert mutually exclusive values or polarities. In NLI terms, this is the case where the hypothesis cannot be true if the premise is true.

A qualified contradiction exists when the claims overlap only partially: for example, they align on subject and event frame but conflict on a date range, quantity, or location. These are common in prophecy interpretation because one commentator may identify an event correctly but disagree on chronology or geography. SHACL-style validation and slot comparison are effective for surfacing those structured inconsistencies.

A competing reinterpretation exists when two claims map the same prophecy statement to different referents but are not formally contradictory at the proposition level. This distinction is necessary because the dataset should respect the difference between “these cannot both be true” and “these are rival interpretive traditions.” The need for this distinction is reinforced by the documented difficulty of holistic contradiction detection in long documents and by the brittleness of general NLI systems.

Algorithmic approach

The best-performing design in this domain is a three-stage contradiction pipeline.

The first stage is candidate generation. Use lexical filters, shared entity IDs, overlapping time spans, shared prophecy statement anchors, and sentence embeddings such as SBERT to find potentially related claim pairs. Embedding retrieval greatly reduces the search space in large corpora where exhaustive pairwise comparison is infeasible.

The second stage is symbolic and structural checking. This layer uses normalized claim slots to detect negation conflicts, quantity mismatches, incompatible dates, non-overlapping temporal windows, and location exclusivity. In RDF stacks, these checks can be implemented with SHACL shapes, SPARQL constraints, or rule layers; in property graphs, they map well to Cypher pattern matching plus post-processing. SHACL is particularly useful because it formalizes validation against shapes graphs and returns validation reports with result objects, focus nodes, and conformance state.

The third stage is semantic contradiction scoring. Here, a supervised NLI-style model scores whether two claim texts or canonical forms stand in entailment, contradiction, or neutral relation. Use NLI only after candidate generation and structural alignment, not as a standalone oracle. The reason is empirical: NLI datasets such as SNLI, MultiNLI, and FEVER are valuable training resources, but research also shows that strong benchmark performance can mask brittle reasoning and shallow heuristics. Document-level contradiction work likewise shows that contradiction detection in long contexts remains difficult.

A practical scoring formula is:

contradiction_score = w1*structural_conflict + w2*nli_contradiction + w3*entity_alignment + w4*temporal_overlap + w5*source_reliability_adjustment

That formula is a recommended implementation pattern rather than a published standard. Its chief virtue is transparency: reviewers can see whether a contradiction was driven by logic, semantics, or metadata alignment.

Thresholds, partial matches, and reinterpretations

There is no defensible universal contradiction threshold. Calibration research shows that modern neural models are often poorly calibrated, and temperature scaling remains a strong general-purpose calibration method. For that reason, thresholds should be tuned on an internal gold set and tracked by version.

A sensible operational policy is to use banded thresholds rather than one hard cutoff:

Those bands are implementation guidance, not literature-derived constants. Their purpose is to reduce unreviewed hard claims from brittle NLI outputs.

For partial matches, compare facets independently: entity alignment, predicate alignment, time overlap, place overlap, quantity compatibility, and modality compatibility. If the semantic core aligns but a single facet conflicts, store that as a partial contradiction with explicit facet labels such as time_conflict or quantity_conflict. If the referent shifts entirely, use COMPETES_WITH or REINTERPRETS rather than CONTRADICTS. That design reduces reviewer confusion and better reflects the semantic structure of prophetic interpretation. This recommendation is supported by the difficulty of long-document contradiction detection and by cross-document event normalization research.

Review Workflow

Status model and reviewer roles

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

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.

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.

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.

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.

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.

Storage Query and Export

Storage design options

The storage choice should follow the project’s priorities.

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.

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.

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.

Example Cypher queries

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

// 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;

// 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;

// 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.

Example SPARQL queries

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

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)

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

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.

Export patterns

For export, support three first-class serializations.

Use JSON-LD for APIs and web clients because it is JSON-friendly while preserving linked-data semantics. Use Turtle or TriG for standards-based exchange, archival publication, and human-readable semantic data. Use CSV for bulk analytics and import into general data tools, with at least nodes.csv, edges.csv, passages.csv, and assertions.csv. JSON-LD and Turtle are directly standardized Linked Data serializations, while Jena, Fuseki, and many RDF stacks already support those formats natively.

If you adopt nanopublication-style packaging, export each reviewed contradiction or interpretation as a small package containing assertion, provenance, and publication info. That makes high-value claims portable, citable, and inspectable outside the operational application.

Visualization and Evaluation

Visualization and UX

The most useful UX is claim-centric, not source-centric. Analysts typically start with one prophecy statement or one interpretation and then fan outward to entities, events, conflicting readings, and sources. The most valuable views are an ego graph around a selected claim, a synchronized timeline, a map, a provenance trail, and a contradiction matrix. Time and geography are especially important in this domain, and the standards ecosystem already supports both through OWL-Time and GeoSPARQL.

Recommended visual components are:

The provenance trail is especially important because reviewable AI systems need to expose how a claim was derived, not just what the graph currently says. That is directly in line with provenance standards and human oversight principles.

Evaluation and validation

Evaluation should be split into extraction quality, contradiction quality, operational review quality, and corpus coverage.

For extraction, use entity precision/recall/F1, entity-linking accuracy, relation F1, event extraction F1, temporal normalization exact and relaxed accuracy, and geospatial resolution accuracy. Benchmarks like DocRED, TempEval-3, and entity linking evaluation work are useful starting points—even though none are prophecy-specific. For contradiction detection, use precision/recall/F1, AUROC or AUPRC, calibration error or Brier score, and reviewer override rate. For process quality, measure review latency, adjudication rate, and proportion of high-value claims with complete provenance.

Use existing public datasets where they fit the subtask: FEVER for evidence-grounded claim verification; SNLI and MultiNLI for generic entailment and contradiction training; DocRED for document-level relations; TempEval-3 for time expressions and temporal relations; and cross-document event extraction datasets such as CLES for assembling event structures from multiple sources. But because no standard benchmark captures the special difficulties of prophecy corpora, you should also create an internal gold set and a synthetic benchmark with controlled perturbations such as negation flips, number changes, date shifts, referent swaps, translation variation, and metaphor-to-literal rewrites.

Human-in-the-loop evaluation should be formal, not informal. Use double annotation on a stratified sample of claims, especially metaphor-heavy passages and high-score contradictions. Track inter-annotator agreement and the rate at which reviewers override machine judgments. That matters because recent NLI research shows that models can look strong on mainstream datasets yet fail badly on simple inference cases, and document-level contradiction studies show the long-context version of the problem remains hard.

Roadmap Ethics and Limitations

Prioritized implementation roadmap

A practical roadmap with no assumed stack is below.

That yields about 30 to 46 person-weeks for a strong first production version. In calendar time, that is roughly 4 to 7 months for a 2–3 person team, depending on corpus complexity and how much annotation work must be done manually. The largest schedule risk is not storage engineering; it is domain annotation and review policy design.

Ethical and legal considerations

This project touches sensitive religious and cultural material, so the system should be designed to support respectful comparison rather than adversarial ranking. UNESCO’s AI ethics framework emphasizes human dignity, transparency, fairness, and human oversight, and those principles fit this use case well. In practice, that means labeling what the system is doing as source tracking, interpretation comparison, and schema-level contradiction analysis, not as final adjudication on sacred truth claims.

On the legal side, preserve rights metadata at the source level. RightsStatements.org is useful for standardized cultural-heritage rights descriptions, and copyright constraints for text and data mining vary by jurisdiction. The U.S. Copyright Office’s 2025 AI training report emphasizes that legal analysis is context-dependent and that international TDM rules differ, including EU exceptions conditioned on lawful access and, in some contexts, opt-outs. For this reason, the system should store rights, access basis, source license, and extraction purpose alongside each source record.

A conservative operational policy is: store rich metadata and structural annotations freely; store full text only when rights and access allow; keep display excerpts short when rights are uncertain; preserve source locators so users can inspect authorized originals; and never let machine paraphrases silently replace the original source wording in review interfaces. That is a design recommendation informed by cultural-heritage rights practice and current copyright uncertainty around AI-related text use.

Open questions and limitations

Three limitations should be treated as permanent design constraints. First, modern contradiction models remain imperfect, including on simple inference problems, so automation should support review rather than replace it. Second, historical place normalization is inherently hard, and modern gazetteers are not enough for ancient or sacred geographies; resources like Pleiades help but do not solve all ambiguity. Third, metaphor, hedge, and translation effects can create apparent contradiction where the underlying issue is semantic indeterminacy rather than factual conflict.

If those limits are accepted up front, the design becomes much clearer: keep the original text immutable, make interpretations explicit, attach provenance to every important assertion, and reserve final contradiction decisions for a calibrated human-in-the-loop workflow.