Skip to content

Under active development

Development status →
TACITUS
Section pages

White paper · v2.3 · Research proposal

The AI knowledge layer for policy and political work.

A research proposal for durable policy context: preserve evidence and relationships, then select a task-specific view for people and AI. Portability, quality and total cost are questions to test.

Under development. This paper describes a design and a plan to test it. It reports no TACITUS performance advantage. See the current engine and its implementation limits.

TACITUS Research · Updated

Practitioner summary · the question, evidence and limits
Practical question
How can an analyst reuse prior work without losing its evidence and qualifications?
Proposed mechanism
Keep a durable source-linked record; select a smaller task-specific context view for the next question.
Current evidence
Public reference artifacts and recorded PRAXIS workflows establish particular operations, not a measured quality or cost advantage.
Strongest limitation
Whether the added structure improves decisions enough to justify construction and review cost remains unmeasured.

Revision responsibility: TACITUS Research. Summary prepared September 30, 2026; paper dates remain separate. Independent peer review is not claimed.

TACITUS Research · White paper v2.3 · Updated 29 September 2026

Status: research proposal under development. This paper defines an architecture and an evaluation agenda. It reports no TACITUS benchmark advantage, token saving, or prediction accuracy. Published examples, local compiler checks, and a working product interaction answer different questions; none establishes the performance of the complete architecture.

Abstract

An analyst rarely needs every document in an archive at once. They need the passages, relationships, dates, and qualifications that bear on a particular question. A useful AI system must select that context without discarding the detail that could change the answer.

We propose a persistent knowledge layer from which software can assemble a smaller, task-specific context package. The persistent record preserves sources, attributed claims, competing accounts, temporal scope, and review decisions. A query selects a view of that record; a language model uses the view to draft an answer; a reviewer can trace consequential statements back to the underlying material.

Our hypothesis is that this separation can improve continuity, error detection, and the cost of repeated analytical work. It may also fail: extraction introduces errors, schemas can misrepresent a situation, review costs time, and a compact prompt can omit the decisive exception. The relevant comparison is therefore answer quality and total operating cost over a sequence of tasks, against capable retrieval and long-context baselines. A smaller prompt alone is not a successful result.

1. The problem: useful context is more than available text

Consider a regulatory team comparing successive versions of a proposed rule. One source describes the legal text; another records an industry's objection; a third reports a later amendment. A fourth repeats the objection without adding evidence. The team needs to know which version applies, who made each claim, what the amendment changed, and whether two apparent confirmations have the same origin.

Loading all four documents can be reasonable. So can retrieving selected passages. The difficulty is preserving the relationships that make the passages interpretable, especially when a colleague returns to the question months later. A final briefing often leaves those relationships implicit. A conversation transcript preserves a sequence of messages, but does not by itself establish which assertions were reviewed, superseded, or merely suggested.

Long-context research provides a reason to test selection carefully, rather than assume that a larger input solves this problem. Lost in the Middle found sensitivity to where relevant information appeared in the contexts of the models studied. RULER expands evaluation beyond finding a single inserted fact to aggregation and multi-hop tracing. These are findings about particular models, tasks, and experimental conditions. They are not evidence that every current model fails in the same way, or that a graph will outperform it.

The engineering question is specific: what information must remain available for this task, which relationships must be explicit, and what may be left out of the current model call without misleading the reader?

2. The proposal: separate the record from the prompt

A Context Capsule is our evolving unit of reusable analytical context. Current DIALECTICA documentation also calls these PRAXIS Capsules. The proposed capsule contains source references and selected knowledge about a task or situation, together with scope, methods, and review history. It should remain inspectable outside the conversation that first produced it.

The full capsule and the prompt sent to a model serve different purposes. The capsule is the durable record. A context projection is a bounded view assembled for one question, user, time horizon, and output. Several different projections can come from the same capsule without changing its accepted contents.

  1. Source materialPreserve passages, origin, dates, and access conditions.
  2. Proposed recordsExtract claims and relationships; keep uncertainty visible.
  3. Human reviewAccept, qualify, reject, or leave a proposal unresolved.
  4. Accepted contextVersion the record and retain the reason for each change.
  5. Task-specific viewSelect relevant evidence, counter-evidence, and constraints.
  6. Draft and checkGenerate an answer, inspect its support, and record corrections.
Proposed information flow. Generated text and extracted records do not become accepted knowledge automatically. An answer can trigger a new review proposal, which returns through the same review boundary.

This design gives different responsibilities to the products. PRAXIS is the analyst's workspace: the question, source material, capsule review, drafting, and handover. DIALECTICA is the knowledge-engine development: ingesting material, validating proposed structure, recording review decisions, and compiling context packages. Versioned adapters connect the two. Upstream extraction must not silently write into accepted PRAXIS records.

The current DIALECTICA repository distinguishes local fixture, compiler, archive, export, and interface checks from unfinished live-provider ingestion and production frontend integration. That distinction governs this paper. Our diagrams describe the intended system; they are not deployment diagrams of a completed service.

3. What the persistent record must preserve

A practical record needs more than a statement and a confidence score. At minimum, a consequential claim should retain its speaker or source, relevant passage, scope, temporal interpretation, and review state. A source may faithfully report what someone said while providing no independent evidence that the statement is true.

Record concern What a reviewer needs Failure if omitted
Source identity Original document or reference, version, locator, access conditions A citation cannot be reopened, or a repeated story looks independent
Attribution Who asserted, denied, reported, or inferred a claim An analyst's inference becomes an actor's stated position
Evidence relationship Supports, challenges, qualifies, or supplies background, with the passage Any linked source appears to validate the whole sentence
Time Event or validity interval, date of reporting, and date recorded A historical position is presented as current
Review Decision, reviewer, scope, caveat, and version affected Model output is mistaken for accepted institutional knowledge
Uncertainty Missing information, alternatives, and the reason for uncertainty A numeric score conceals what is unknown
Method and output scope Analytical question, assumptions, audience, and permitted use A useful answer is reused for a materially different decision

Some of these distinctions have established technical reference points. W3C PROV-O provides a vocabulary for entities, activities, agents, and derivation. SHACL specifies graph constraints. They help describe provenance and structural validation. Neither decides whether a source is reliable, whether an inference follows, or whether TACITUS conforms to the standard. Conformance would require a defined mapping and tests.

Source documents should remain available under their original permissions. A capsule may contain a document, an extract, or a reference requiring separate access. Exporting an identifier does not transfer the right to read its target. A cryptographic digest can help detect a changed artifact; it does not establish the truth of the text or the legitimacy of its use.

4. A small vocabulary, with limits

The Agentic Conflict Ontology starts from eight concepts: Actor, Claim, Interest, Constraint, Leverage, Commitment, Event, and Narrative. They reflect recurring questions in conflict, policy, and negotiation work. We treat them as a design hypothesis to test in those domains, not a universal decomposition of all human knowledge.

The important distinctions are often between nearby concepts. A claim is not automatically a commitment. A stated demand is not the same as an underlying interest. An interest may be explicitly reported by the person concerned or inferred by an analyst; the record must distinguish these cases. An event that precedes another is not thereby its cause. A narrative is an attributed framing, not a license to infer intent from word choice alone.

Domain extensions should make their additional requirements explicit. A regulatory obligation may need a jurisdiction, effective date, and controlling text. A negotiated commitment may need a beneficiary, condition, deadline, and evidence of acceptance. Both can inform the shared model without pretending to have identical semantics.

The proposed extension process is: document a recurring representational gap; propose fields and relationships; test them on contrasting cases; review their meaning with practitioners; version the accepted change; define how older records are interpreted. A model may suggest an extension. It must not change the meaning of previously accepted data by silently inventing a new type.

Overly rigid schemas can force ambiguous material into false precision. Unconstrained schemas can accumulate duplicate concepts and incompatible definitions. We need to measure correction time, agreement between reviewers, and retrieval behavior to find a useful level of structure. More classes or edges do not demonstrate better understanding.

5. Time, revision, and a worked example

The record should distinguish when something is said to hold from when the system learned or recorded it. Source publication time is a further useful field. An uncertain interval should remain uncertain; a month mentioned in a source should not become an invented day.

Consider this fictional file:

When recorded Source and stated timing What the record should preserve
3 March A published proposal says a reporting requirement would begin on 1 June Proposed effective date; not yet an enacted obligation
12 March An industry submission objects to the proposal Attributed objection and its grounds; no assumed change to the rule
20 March An amendment changes the proposed date to 1 September A new version and a source-supported change to the proposal
21 March A news summary repeats the original June date A conflicting, possibly stale account requiring inspection

The question "What date was proposed on 10 March?" needs a different view from "What does the latest amendment propose?" The earlier record remains relevant to the first question. The later document should influence the second without rewriting what was knowable at the earlier date.

A temporal model also needs rules for withdrawals, corrections, uncertain ordering, and sources discovered late. The history of a review decision is separate from the history of the underlying event. If a retention or erasure obligation requires removing material, an append-only design cannot override it. The system needs explicit deletion, access-revocation, and audit policies consistent with the actual engagement.

6. From a question to a context projection

A projection should begin with the task: the question, allowed sources, relevant period, audience, and expected output. Retrieval then proposes candidate passages and records. Selection should consider relevance and the relationships that make those candidates interpretable, including a contradiction or exception that changes the apparent answer.

A proposed projection contains: the question and constraints; a small set of relevant records; supporting and challenging passages; a compact explanation of essential relationships; source locators; and an account of important omissions. The exact serialization is an engineering choice. JSON is explicit but can be verbose. A compact table may be easier for a model to use. Both need token measurement and error analysis with the tokenizer and model actually deployed.

The budget covers instructions, the question, context, tool descriptions and results, and space reserved for the response or reasoning under the model's accounting rules. A system must not fill a context window with retrieved material and then quietly truncate the answer or remove qualifications. When essential evidence cannot fit, it should narrow the task, request another retrieval step, or explain the incomplete coverage.

Selection cannot be justified by semantic similarity alone. For a commitment question, dates and conditions may be indispensable. For a narrative question, original source lineage may matter more than repeated mentions. For an options memo, an apparently peripheral legal constraint may rule out an otherwise plausible recommendation. These requirements belong in task-specific tests.

7. Token efficiency is a total-cost question

We distinguish three mechanisms that are often grouped together. Selection chooses material relevant to a task. Compression shortens its representation. Reuse avoids reconstructing the same context for repeated work. They can be combined, but each has different costs and failure modes.

RECOMP studies extractive and abstractive compression of retrieved material, including selective augmentation when retrieval adds no useful information. LLMLingua-2 learns token selection for prompt compression. These are useful baselines, not evidence that our capsule representation is more efficient. A compression method that performs well on a benchmark can still remove a decisive qualification in a legal or policy document.

The ledger must include input and output tokens, separately billed cached input where applicable, model calls, tool results, embedding or extraction work, and retries. Count the compiler and storage work, update frequency, and reviewer time too. Report human minutes separately unless an explicit, disclosed cost assumption converts them to money.

Total structured-workflow cost over n tasks
  = initial extraction + initial review + indexing
  + sum(task projection + model/tool use + required updates + correction)

Total baseline cost over n tasks
  = baseline preparation
  + sum(retrieval or full-context calls + model/tool use + correction)

A simple break-even estimate divides additional upfront cost by the recurring per-task saving, but only when that saving is positive and roughly stable. Real cases may change too quickly for the initial work to amortize. A one-off question over a small file may be cheaper and better answered with the original documents. Repeated questions over a slowly changing corpus are a more plausible setting for reuse.

Caching and knowledge compression must be measured separately. Cached input may reduce a bill without reducing the number of tokens available to the model. A short projection may reduce tokens while increasing omissions and reviewer work. We therefore propose reporting quality–cost curves across budgets and reuse counts, with failed answers included. Tokens per accepted analytical artifact is more informative than tokens per API request alone.

8. Retrieval, graphs, and generation

A graph is useful when relationships matter to the question and can be represented well enough to query. It is not a universal replacement for lexical search, embeddings, or reading the source. The architecture should retain all of these options.

GraphRAG studies graph-based summarization for global questions over a corpus. Its query documentation distinguishes query strategies. This matters for evaluation: a factual lookup, a timeline comparison, and a broad question about recurring themes should not be forced through an identical retrieval path.

We use Ontology-Augmented Generation, or OAG, to name our proposed approach to generation over explicit record types, relationships, source references, and review state. The proposal is to expose those constraints to retrieval and answer construction, then verify what the answer actually says. It does not establish that the model obeys every constraint or that typed output is factually correct.

A generated answer should distinguish quoted or summarized evidence, an attributed claim, and the system's interpretation. Each consequential assertion needs a support check against the cited passage, not merely a test that its citation ID exists. Missing or contradictory evidence should remain visible. Corrections become proposals for review; they should not automatically overwrite the source record.

9. What recent research changes—and what it does not

Two September 2026 preprints make the semantic-contract question especially concrete. Symbolic Separation investigates a knowledge-graph contract for operational data analytics. It connects semantic structure with executable queries and reports results on its own telemetry task. OntoKG-EQ combines competency questions, provenance, and queryable evidence in an equity-analysis setting.

We have not independently reproduced either study. Their data, task definitions, and evaluation conditions differ from contested policy documents. A successful query over operational telemetry does not establish accurate causal interpretation of a political event. A participant's increased trust in an evidence bundle is also different from a measured improvement in factual accuracy. Their value here is to sharpen a question worth testing: which domain relationships can be specified before generation, and what errors does that specification prevent or introduce?

LongMemEval offers another useful reference: memory should be evaluated through questions that require retrieving and updating information across interactions, not merely by showing that a system saved a transcript. For TACITUS, a stronger handover test would ask a second analyst to recover the source, scope, rationale, and unresolved issues behind an earlier assessment.

The literature motivates comparison. It does not provide transferable TACITUS performance numbers. As models, retrieval systems, and caching policies change, the baselines need to change with them.

10. A fair evaluation design

A useful evaluation separates extraction, retrieval, generation, and review. An extraction error can make a later query look precise while answering the wrong question. Good generated prose can hide poor retrieval. A reviewer may repair a weak draft, but the time required is part of the result.

Baseline or ablation Purpose What must stay comparable
Full available context, where it fits Test whether structuring adds value at all Same sources, question, model, and answer requirements
Lexical plus vector retrieval with reranking A strong practical retrieval baseline Source access, retrieval budget, and prompt tuning effort
Retrieval plus extractive or abstractive compression Separate compression from capsule structure Input budgets, preservation checks, and compressor cost
Graph-assisted retrieval Test relationship-based selection Index construction and update costs; query class
Capsule without reviewed relationships Isolate the value and cost of review Same extracted candidates and task set
Capsule without counter-evidence or temporal fields Reveal dependence on these features A diagnostic ablation, not an acceptable deployment setting
Full proposed workflow Test the combined design End-to-end cost, coverage, errors, and reviewer effort

We propose grouping train, development, and test splits by dossier or source family, not randomly splitting related passages across sets. Authors of reference answers should not see the candidate system's answers first. Source availability must be frozen for historical questions so later documents do not leak into an earlier assessment.

Measure support precision and coverage, missing decisive evidence, temporal mistakes, contradiction handling, uncertainty calibration where probabilities are actually defined, and permission violations. Report extraction and entity-resolution errors separately. Human review should record time to a usable artifact and the edits required, with disagreements between reviewers preserved rather than hidden in a single score.

Cost and latency results should include failures and retries, with distributions and uncertainty intervals. Publish model/version, tokenizer, prompts, retrieval settings, context budget, cache conditions, corpus version, and evaluation code where rights permit. If structured context saves tokens but lowers evidence coverage or makes correction slower, that is a failed efficiency claim for that task. The proposed experiments turn these requirements into smaller studies.

11. Where the design may help

The most plausible applications involve repeated questions, changing records, and decisions that require an explanation. Policy teams compare options and legal constraints. Regulatory and legal researchers track changes in authoritative texts and attributed interpretations. Business-risk analysts examine exposure to events without confusing scenarios with forecasts. Scientific or investigative teams preserve the distinction between observations, hypotheses, and unresolved evidence.

In information-environment analysis, source lineage can reveal that several reports repeat one original claim. The same record can preserve competing accounts and changes over time. This is an analytical and defensive use: understanding evidence, detecting possible manipulation for further investigation, and supporting human judgment. Repetition, similarity, or a graph cluster alone establishes neither coordination nor intent.

Each application needs its own task definitions and expert review. A benchmark on short synthetic conflict passages cannot establish readiness for confidential legal files, intelligence assessments, or humanitarian decisions. TCGC is part of an evaluation direction; operational claims require representative data and deployment-specific evidence.

12. Failure conditions and safeguards

The system can preserve an error very effectively. Bad entity resolution can join two people; a misleading extract can become a reusable premise; an old review can be mistaken for present validity. Review status must therefore be scoped and revisable. An accepted claim is not an eternal fact.

A compact view can erase ambiguity. The projection should preserve uncertainty that could change the decision, record its selection policy, and expose the route back to fuller evidence. A different user or task may require a different view. Access checks belong at retrieval and export boundaries, not just at initial ingestion.

Source material is untrusted input. Instructions embedded in a document must not gain the authority of system policy or a reviewed method. Methods and tools need permissions and versioning of their own. Autonomous tool use introduces additional risks; a well-formed capsule does not by itself make an agent safe or reliable.

The architecture is worth rejecting or simplifying when the cost of creating and maintaining structure exceeds its value; when reviewers cannot agree on usable distinctions; when context selection systematically hides dissent; or when ordinary retrieval matches its quality at lower total cost. The aim is useful analytical work, not maximizing the amount of graph structure.

13. Architecture lineage and implementation boundaries

Earlier TACITUS research described seven graphs: Base, Evidence, Analytical, Narrative, Commitment, Case, and Scenario. It also used four reasoning views—ground, context, evidence, and reasoning—to explain how an interpretation relates to its support. Later capsule proposals named nine concerns, including temporal state, governance, memory, and runtime behavior.

These counts describe different design views. They are not interchangeable database schemas, claims about nine deployed services, or proof of an implemented conversion between versions. Current engine documentation is the reference for actual contracts. This paper keeps the architectural responsibilities explicit without making a particular graph count the product promise.

For source code and current local checks, start with DIALECTICA v3. For the visible workflow and current availability, see PRAXIS. AGON and KAIROS are earlier research references for conflict and temporal extraction. Their integration into the current engine should be described through tested adapters, not assumed from a shared name or diagram.

Licenses are repository-specific. The current v3 repository identifies Apache-2.0. Other repositories must be checked individually; a public repository is not automatically permission to redistribute. Neither this paper nor a downloadable schema establishes a supported hosted API, a security certification, or a service commitment.

14. Research questions we want to answer

Can a reviewer find and correct a consequential error faster when the underlying claims and evidence relationships are explicit? Does a task-specific projection retain the exceptions that matter while reducing total cost over repeated questions? Can a second analyst understand the scope and rationale of a prior assessment without reconstructing the entire case? Can an update change the current view without destroying the record of what was known earlier?

These questions require practitioners as well as engineers. A useful collaboration starts with a bounded analytical task, an appropriate source set, a strong baseline, and agreement about what failure would look like. We welcome difficult examples and criticism of the proposed model through the research contact. Until the experiments are run and reported, these remain hypotheses.

References

  1. Liu et al. (2024). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics. Evidence about position sensitivity in the evaluated models.
  2. Hsieh et al. (2024). RULER: What's the Real Context Size of Your Long-Context Language Models?. Long-context evaluation beyond single-fact retrieval.
  3. Xu, Shi, and Choi (2024). RECOMP: Improving Retrieval-Augmented LMs with Context Compression and Selective Augmentation. ICLR. Compression and selective retrieval augmentation.
  4. Pan et al. (2024). LLMLingua-2: Data Distillation for Efficient and Faithful Task-Agnostic Prompt Compression. Findings of ACL. Learned token selection, evaluated on the authors' tasks and models.
  5. Edge et al. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. See also the maintained GraphRAG query documentation.
  6. Wu et al. (2024; ICLR 2025). LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory. Long-term memory evaluation; not an institutional handover benchmark.
  7. W3C (2013). PROV-O: The PROV Ontology. W3C Recommendation.
  8. W3C (2017). Shapes Constraint Language (SHACL). W3C Recommendation.
  9. Symbolic Separation: Grounding Deep Agents in Knowledge Graphs for Trustworthy Operational Data Analytics (September 2026). Preprint; its results have not been independently reproduced by TACITUS.
  10. OntoKG-EQ: A provenance-grounded, competency-question-governed knowledge graph for auditable analyst querying (September 2026). Preprint; task-specific technical and participant evaluations, not TACITUS validation.
  11. DIALECTICA v3 repository. Project source for current implementation boundaries, rather than independent evidence of effectiveness.

Cite this version

TACITUS Research. The AI knowledge layer for policy and political work: structured context, bounded prompts, and reviewable reasoning. Research proposal, version 2.3, 29 September 2026. https://www.tacitus.me/research/vision

Search and terminologyMachine-readable index