Skip to content
TACITUS
Section pages
All notes

NOTES BY TACITUS

From seven graphs to nine capsule layers: separating records by responsibility

TACITUS Research · no independent peer review claimedPublished Revised ·TACITUS Research·5 min read·Architecture

Research and design work. TACITUS remains under development; proposed mechanisms and evaluation plans are identified in the article. Check current product capabilities.

dialecticaarchitectureengine

TL;DR

  • 01The seven-graph model is an earlier architectural sketch; the current capsule design names nine layers.
  • 02Logical separation does not require nine databases, nor does a named graph enforce access or review policy.
  • 03Summaries and graph projections must be invalidated when their underlying records change.

The useful question is what each part of a knowledge object means, how it can change, and which other artifacts depend on it. Counting graphs is a consequence of those decisions.

Revision: Replaces the historical seven-graph account with the current nine-layer capsule design. Clarifies logical versus physical storage, migration, derived views, and development status. Added the scoped read the historical terminology through a dated crosswalk example and its evidence boundary.

Keep the history without presenting it as the current schema

The original note described Base, Evidence, Analytical, Narrative, Commitment, Case, and Scenario graphs. That was an attempt to separate source material, interpretations, and counterfactual work. It remains useful as design history, but it is not the current capsule layer list. The current design names evidence, claims, situation, temporal, ontology, reasoning, memory, governance, and runtime.

These lists are not equivalent partitions with two names added. A commitment can be represented as a claim with temporal qualifications, situated among actors and constraints. A scenario can involve several layers and must remain distinguishable from an observed record. Migration requires explicit mappings and preserved identifiers, not renaming graph labels until a validator accepts them.

Nine responsibilities in one inspectable object

Current design responsibilities; this table is not a claim that every PRAXIS export implements each layer.
LayerWhat it recordsWhat changes must preserve
EvidenceSource documents, passages, and source referencesThe identity and version of material used
ClaimsAttributed assertions and qualificationsDisagreement, support, and revision links
SituationActors and the relationships relevant to a caseThe scope of the case and unresolved entities
TemporalEvent dates, recording dates, and intervalsUncertainty and the distinction between clocks
OntologyDefinitions, types, and domain extensionsThe vocabulary version used to interpret records
ReasoningMethods, assumptions, and analytical instructionsAttribution and limits of the method
MemorySelected history useful to subsequent workIts source basis and whether it has become stale
GovernancePermissions and review decisionsWho may use, change, or promote the record
RuntimeInstructions and requirements for a consuming toolWhat the tool actually supports and enforces

Names are not enforcement

RDF datasets can group triples in named graphs; SPARQL can select and query those graphs. Those standards provide representational and query mechanisms, not a guarantee that a runtime keeps an unreviewed assertion out of an answer. The application still needs access checks, explicit query scope, and tests for accidental unions across layers. [1][2]

A relational implementation can express the same responsibilities using versioned tables and joins. A document store can preserve a complete package snapshot. A graph projection can make relationship traversal convenient. The choice should follow query patterns, transactional requirements, and operational cost. Nine logical layers are not an argument for nine services or nine independently mutable stores.

Follow a correction across the package

Suppose a source correction changes a meeting date from 8 September to 9 September. Keep the source versions and record the correction. Update the relevant temporal interpretation through review. Then identify derived artifacts: a chronology, a narrative comparison, a memory summary, and any answer that relied on the earlier ordering. Their dependencies matter more than which storage collection happens to contain them.

PROV-O distinguishes entities, activities, derivation, revision, and invalidation. It provides useful terms for this dependency record, but a provenance edge alone does not refresh a summary. A scheduler or reviewer must decide which artifacts to recompute, which to mark stale, and which historical snapshots to preserve. [3]

Illustrative dependency chain after a source correction.
  1. 1Corrected source version
  2. 2Reviewed temporal revision
  3. 3Affected claim and chronology
  4. 4Stale summary identified
  5. 5New answer assembled from a specified snapshot

Select context; do not serialize the entire architecture

An agent comparing two commitments may need the relevant claims, dates, source passages, and a small part of the ontology. Sending all nine layers in full could waste tokens and expose unrelated material. A context assembler should select a task-specific view while retaining identifiers that allow the agent or reviewer to retrieve omitted detail. Context-engineering guidance supports this distinction between a durable record and a working context window. [4]

A compact view is lossy. It must not silently drop a dissenting claim or the condition that makes two undertakings different. Version the selection policy and record which source snapshot it used. Measure context size alongside evidence recall and answer quality; smaller prompts alone are not a successful optimization.

The test is a reconstructable record

Our evaluation should round-trip a capsule, reconstruct an earlier view after a correction, and rebuild derived graph projections from retained records. It should also attempt unauthorized reads and promotion of unreviewed changes. Compare a layered representation with a simpler versioned document or relational design before accepting the extra machinery.

PRAXIS remains the user-facing workspace, with DIALECTICA as the proposed ingestion and review boundary. The nine-layer description is a developing format and architectural direction. Older reference fixtures can contain a different layer set; their manifest and schema version, not this article title, determine what they actually contain.

Read the historical terminology through a dated crosswalk

The seven-graph model describes an earlier research view. The website’s seven communication lenses organize an authored teaching fixture; they are not the same list. Nine architecture responsibilities and four contextual roles describe further concerns. The compiled reference contains eight layers. Keep each artifact’s pinned version and omissions explicit rather than asserting that a new diagram proves a composed runtime. [5]

SOURCES

  1. [1]W3C. RDF 1.1 Concepts and Abstract Syntax (Recommendation, 2014).Graph and dataset semantics, including named graphs.
  2. [2]W3C. SPARQL 1.1 Query Language (Recommendation, 2013).Queries over RDF datasets and named graphs; authorization remains an application concern.
  3. [3]W3C. PROV-O: The PROV Ontology (Recommendation, 2013).Entities, activities, agents, derivation, revision, and invalidation.
  4. [4]Anthropic. Effective context engineering for AI agents (29 September 2025).Primary engineering guidance on retrieval, compaction, structured notes, and context tradeoffs; not an independent benchmark.
  5. [5]Worked example / implementation boundaryAuthored website demonstration or reference explanation. Not independent analytical validation or production integration proof.

SHARE