Research tool on Research Tool

Graph Projection without Graph Worship

cahoover@gmail.com (Christopher Hoover) — Fri, 03 Apr 2026 00:00:00 +0000

(Being what I hope is a catchier title than “Why we stopped treating the graph as the center of the system.”)

When we began building Research Tool, the graph was seductive because it was the most visible, queryable, integrated surface. It looks like the place where everything should live. The first iterations of RT used the graph as the source of truth and the center of gravity. More or less everything revolved around it. I even subscribed to Neo4J marketing emails.

But we discovered that the graph as center of gravity was pulling too many responsibilities into itself:

truth storage
orchestration assumptions
retrieval semantics
lineage
application state
product meaning
and on
and on

That actually felt kind of elegant at first. Then it started to chafe, because too many concerns were getting entangled.

Projection logic started bleeding into truth. Storage decisions started shaping product behavior. Retrieval behavior became harder to separate from graph layout. Debugging got harder, because we couldn’t tell if a problem lived in the source artifacts, the projection pipeline, the graph model, or the consuming service. Replay became harder.

Graphs are genuinely great, but they are so expressive that it’s easy to overreach. Because they can represent almost anything, it’s easy to let them absorb responsibilities that should have remained distinct.

We began to struggle with heisenbugs, and it felt like everything was getting harder. (An aside: this was my introduction to the concept of “heisenbugs.” They’re awful, but what a clever name, huh?)

After beating our heads against a wall for too long, we were forced to step back and reconsider the role of the graph in our platform. We decided the answer was that the graph is not a canonical store; it is a projection.

The graph is an excellent planning surface, exploration surface, and a derived integration surface. It is great at helping traverse structure, discover relationships, and bound useful work. It is great at making meaning navigable. But for us it’s not where truth should live, and it is not where every contract in the system should collapse together.

Once we accepted that, which was surprisingly painful and anxiety-provoking, the architecture got cleaner. [Cue major-key background music]. We moved truth into durable artifacts and producer-owned contracts, and ensured the graph could be rebuilt from those artifacts (without using GraphAR, which was also painful, but we got a lot more flexibility). Projection became something we could replay, inspect, and change without fear of mutating the meaning of the whole system.

I don’t want to treat our journey as some sort of groundbreaking insight, but things did get easier. Services became easier to reason about because producer and consumer boundaries were sharper. Debugging was more straightforward because we could ask simpler questions: was the source wrong, the contract wrong, the projection wrong, or the read model wrong? (Sometimes the answer to that is “yes”).

Net: The graph is no longer the center of the system; it is one member of set of lenses over the system.

Research Tool: The Annotation Substrate

cahoover@gmail.com (Christopher Hoover) — Thu, 19 Mar 2026 00:00:00 +0000

Most ‌people ‌hear ‌“annotation” and picture a sticky note, a little comment bubble hanging off the margin. Extra metadata you tack on afterward. The kind of feature a team adds in Sprint 14 because a customer asked for “collaboration.”

We don’t treat it that way. When someone is working through dense material, legislation, regulatory filings, contracts, or even messy quantitative observations, the real value rarely sits in the raw source. It sits in the judgment and connections formed while reading it. How one amendment quietly collides with another. Whether a revised sentence is an actual policy shift or just cleanup. Why a sudden spike in a series is probably a reporting quirk, not the world changing overnight.

The annotation substrate

Substrate (noun): the base something lives on.

At RT, we’ve been building what we call an annotation substrate, a durable layer where human and (human-verified) machine judgments are treated as first-class objects. They have an identity. They have history. They have a lifecycle. This isn’t “notes on top of content,” it’s infrastructure that makes judgment sturdy enough to become part of system behavior.

For example: an analyst marks a statutory provision as ambiguous. The provision is the target. The justification might be a conflicting committee report, a related amendment, and an older analyst note that argued the opposite. Those aren’t the same kind of thing. They play different roles, so the system should represent them differently.

If you squash all of that into a single “comment on this highlighted span,” you lose what makes annotations searchable, composable, and reusable.

Durable annotations enable another navigation surface across the corpus, such as: show every provision marked as ambiguous; list findings that rely on this committee report; surface where analysts disagree; track what shifted after a particular amendment; pull every quantitative observation linked to this clause.

What about structured data?

The same idea extends to structured data.

We work with quantitative observations next to legal text, measures, time series, outcomes, analytic checkpoints, and so on. Analysts need to annotate those too: “This spike is a reporting artifact.” “This correlation stops holding after the 2019 rule change.” “This measure isn’t comparable after the statutory revision.”

That means a single annotation can say: This statistical trend (structured target) -> is explained by this clause (document evidence) -> and contradicted by this prior finding (another structured target).

Compounding impact

Annotations made over time (e.g. by a team) have compounding value for the exploration of a large corpus. You can start at a clause and jump to the metrics it might influence. Or begin with an anomaly in the numbers and move back to the governing language. You can trace where an earlier conclusion gets strengthened, weakened, or overturned as versions shift and sources change. You can disagree with annotations and track disagreements.

Still early, but the direction is clear

It’s early. The structured targeting layer still needs resolver APIs, selector schemas, and firmer calls around versioning. Plenty remains to be nailed down.

But the path is straightforward: one substrate across modalities, durable coordinates rather than brittle offsets, explicit evidence rather than collapsed comments, and judgment you can reuse.

About Research Tool

cahoover@gmail.com (Christopher Hoover) — Mon, 01 Jan 0001 00:00:00 +0000

Research Tool is an operational intelligence platform for messy, changing evidence

Every team working in a high-stakes environment runs into the same problem: the truth is scattered across PDFs, filings, legislation, datasets, various APIs, spreadsheets, notes, and multiple versions of the same source. Search gives you fragments or a firehose. Dashboards only show what was already modeled. LLMs will answer confidently, often without showing their work.

Research Tool helps teams monitor change, investigate impact, and make evidence-based decisions. It’s built around a simple idea: in large, messy environments, the highest-signal view is usually not the full archive, it’s the part that changed. A clause appears. A threshold shifts. A definition quietly changes. A metric disappears. A new exception shows up.

RT treats that movement as a starting point for analysis. It preserves documents, datasets, machine-derived signals, and analytical outputs as durable, portable artifacts. Every result stays tied to the text spans, rows, or cells that support it. Graph, search, and vector systems sit on top as exploration layers.

That lets teams do things like:

monitor policy, contract, or regulatory changes and see the downstream impact
investigate a company, person, supplier, or network across many sources
detect emerging risk, narrative drift, or coordinated changes across a corpus
keep analysts in the loop as claims are validated, challenged, and refined against evidence

Under the hood, RT models entities, context, conditions, and change consistently, so the same system can answer: What changed? Who or what is affected? What is emerging? What evidence supports that conclusion?

Machine output is provisional by default. Notes, annotations, and assessments attach directly to evidence and become part of the operating picture.

Research Tool is built for teams working in messy, changing, high-consequence environments. Interested? Reach out.

Architecture

cahoover@gmail.com (Christopher Hoover) — Mon, 01 Jan 0001 00:00:00 +0000

Research Tool is a multi-layered platform that turns complex, evolving sources into durable, queryable, evidence-backed systems of knowledge. Its architecture preserves structure, supports reproducibility, and enables discovery across documents, datasets, media, and time. It’s built in Python and Rust.

Multimodal Ingestion
RT’s ingestion layer turns raw sources into durable, versioned artifacts across documents, datasets, HTML, XML, and media. It is the front door to the platform and the beginning of the evidence chain, designed to preserve provenance from the first step of processing.

Structured Data Engine
RT does not store simple tables. It transforms structured data into governed analytical surfaces that can be normalized across sources, compared over time, and projected into reusable states, relationships, and dynamics. Our testing routinely processes 200M rows.

Document & Media Parsing
RT preserves structure, hierarchy, and evidence fidelity across PDFs, HTML, XML, and media transcripts. Rather than flattening everything into undifferentiated chunks, it retains the internal form of source material so downstream systems can reason over real structure.

Annotation Substrate
RT’s annotation substrate is a foundational architecture for stand-off semantics. It combines a structure substrate, canonical annotation bundles, and deterministic resolution, allowing machine and human annotations to remain grounded in stable document coordinates.

Durable Artifact Plane
This is RT’s source-of-truth layer: deterministic identities, reproducible artifacts, manifest-based publishing, and stable contracts for downstream systems. It is the foundation that makes replay, auditability, and controlled evolution possible.

Enrichment & Knowledge Derivation
RT combines machine enrichment with analyst-authored semantic layering. This layer derives observations, states, arcs, and annotations from source artifacts while also supporting human validation, curation, and interpretation as first-class knowledge surfaces.

Search & Retrieval Stack
RT’s search stack combines query understanding, hybrid retrieval, graph context expansion, and answer generation. It is designed not as a thin keyword layer, but as a multi-stage retrieval system for evidence-backed exploration.

Graph Projection & Runtime
RT projects durable artifacts into navigable runtime surfaces, including graph, search, and vector representations. This layer supports graph rendering, graph persistence, search indexing, embeddings, and staged projection into operational views.

Exploration & Discovery Loop
RT supports graph-in-the-loop discovery through bounded planning and iterative computation. Candidate sets, checkpoints, and guided exploration loops make it possible to move from raw information to high-signal analytical paths without brute force.

Control Plane & Orchestration
RT’s control plane coordinates jobs, manages specifications, tracks execution, and governs graph change workflows. It is the orchestration layer that keeps the system reproducible, observable, and operational at scale.

Features

cahoover@gmail.com (Christopher Hoover) — Mon, 01 Jan 0001 00:00:00 +0000

Coming soon. We’ll get there.

Use cases

cahoover@gmail.com (Christopher Hoover) — Mon, 01 Jan 0001 00:00:00 +0000

Research Tool is an operational intelligence platform for messy, changing evidence. It can:

unify fragmented data and documents
preserve lineage and evidence
model entities, events, and change over time
let operators move from signal to decision

1. Change monitoring for critical documents and policies

Know what changed in the rules of the game.

RT treats change as a high-signal entry point for discovery.

Examples:

Defense: doctrine, procurement language, sanctions, threat reporting, operational directives
Finance: filings, debt agreements, earnings language, regulatory updates, disclosures
Healthcare: reimbursement rules, clinical guidance, formularies, policy bulletins

2. Blast-radius analysis

“What do I need to care about now?”

RT helps connect events with downstream consequences.

Examples:

A clause changes in a contract or bill — which entities, business units, topics, or metrics are exposed?
A policy update lands — which portfolio companies, facilities, or cohorts are impacted?
A new healthcare rule appears — which claims, procedures, or provider groups move into risk?

3. All-source case building on an entity, network, or account

Build the operating picture for a person, company, unit, supplier, or patient population.

RT makes the corpus navigable as a system, as well as searchable as files.

Examples:

Defense/intelligence: build a dossier on an actor or network from reports, messages, documents, and structured events
Finance: investigate a counterparty, issuer, executive, or suspicious network
Healthcare: understand a provider group, treatment pathway, claims pattern, or patient cohort

4. Early-warning and emerging risk detection

Spot emerging risk before it is obvious.

RT surfaces weak signals and pattern changes across a system, supporting systemic as well as entity-level change.

Examples:

Defense: coordinated language shifts, new exceptions, changing priorities across many documents
Finance: governance drift, distress signals, fraud indicators, unusual disclosure patterns
Healthcare: coding drift, rising adverse-event language, unusual utilization or reimbursement shifts

5. Analyst-driven adjudication and collaboration

Turn competing evidence into an operationally usable view of truth.

RT’s annotation and assessment model delivers a workflow for handling ambiguity, disagreement, and accountability.

Examples:

Analysts annotate, dispute, confirm, and escalate claims
Teams distinguish provisional AI output from validated conclusions
Leadership sees what is believed, what is contested, and what still needs review