Nine layers, one capsule: separating evidence from interpretation

Follow one statement through the object

Suppose a fictional municipality publishes a notice saying that bridge repairs are expected to finish in October. An analyst later records that the timetable depends on a permit. A model proposes “the bridge will reopen in October.” All three statements concern the same project, but they have different authors, evidence, and status. Storing them under one completion-date field would discard the distinction the reviewer needs most.

Our proposed Context Capsule model separates these responsibilities into nine layers. The captured notice belongs to evidence. The extracted expectation belongs to claims. A relation connecting the repair to the bridge belongs to the situation record. The expected interval belongs to temporal information. The reviewer’s qualification belongs to governance. These references should point to the same underlying records rather than copying slightly different versions into each layer.

A representation does not supply the semantics

JSON-LD 1.1 supports linked data and named graphs, which makes it a candidate representation for related records. It does not prescribe these nine layers or define what TACITUS means by “accepted.” Those are application semantics we must document and test. A consumer that parses the JSON successfully might still mistake an expected date for an actual completion date. [1]

PROV offers another useful distinction: the notice and extracted claim are entities, extraction and review are activities, and the publisher and reviewer are responsible agents. A provenance bundle can itself have provenance. That helps us describe how a capsule was assembled without pretending its contents were all produced by one trustworthy process. [2]

{
  "claim": {
    "id": "claim-17",
    "text": "Repairs are expected to finish in October",
    "source": "notice-4#passage-2",
    "temporalRecord": "interval-8"
  },
  "review": {
    "target": "claim-17",
    "sourceVersion": "notice-4-v1",
    "decision": "accept_with_qualification",
    "qualification": "Forecast, conditional on permit approval"
  }
}

Define the joins before adding more layers

The design needs invariants across records. An accepted claim must resolve to the reviewed source version or explicitly declare that it is an inference. A revision must not silently inherit a decision made on different text. Deleting a source under a retention rule must leave an intelligible missing-source state in dependent records. A query should specify whether it includes proposed, accepted, rejected, or superseded material.

Passage references deserve particular care. W3C’s annotation model describes both text quotations and character-position selectors. A selector is meaningful relative to its target representation; re-extracting a PDF can change offsets even when a human sees the same page. A capsule therefore needs to identify what representation was selected, not merely which URL was visited. [3]

Repeatable serialization is a separate concern. RFC 8785 defines a JSON canonicalization scheme useful when cryptographic operations need consistent bytes. It does not make semantically equivalent JSON-LD documents equivalent, validate an ontology, or prove a claim. We should state exactly which representation a digest covers instead of describing an object as simply “verified.” [4]

Where the complexity must earn its place

Nine responsibilities can become nine opportunities for inconsistency. An early implementation may keep them in a small number of files or tables with explicit references. An embedded graph can be a derived query projection; it should not become a second competing account of accepted state. Importers need a declared compatibility policy when an ontology version or required runtime rule is unknown.

For DIALECTICA development, a useful test fixture starts with the bridge notice, qualifies the forecast, supersedes it with a new date, and exports the capsule. A second consumer should reconstruct what was known at each revision, preserve the qualification, and reject dangling references. PRAXIS should display those distinctions in ordinary review work. Until those tests pass across supported consumers, the layer diagram is an architectural proposal, not evidence of interoperability.

Responsibilities are not a count of delivered services

A reviewed output can still be unsupported. Keep author assertion, source access, rights and exact-revision local acceptance separate. [5]