Exeges

Search as Part of an Iterative Discovery Loop

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

Most systems think in terms of search first, analytics second. But once a corpus becomes large, heterogeneous, and dynamic enough, that sequence starts to struggle.

As the depth and breadth of data grow, search can start to wander, analytics can become brute force, and graphs can become more of an ornament than a provider of real context. This is a real challenge if you aren’t sure what you’re looking for, and you don’t know what’s available to explore.

Exeges approaches this challenge with an iterative discovery loop. In each round, search converts an underspecified question into the next bounded investigative move. The graph/lexical/vector stack helps decide what’s worth computing by evaluating topology, neighborhood, joinability, coverage, prior outcomes, and known dead ends.

Every round produces a durable checkpoint that informs the next one. Checkpoints describe what was done and what was found, and inform the next planning pass about what was already tried, what succeeded, what failed, and what inputs produced which outcome.

For example, imagine a bill with forty changed sections. The first pass does not ask the machine to “understand the whole bill.” It publishes a CandidateSet that says, in effect: compare sections 101, 302, and 401 first, because they changed and they join cleanly to downstream budget measures. The planner can see that those sections have not yet been analyzed in the same way with the same inputs, so it does not waste a cycle re-running the same work.

Those three work items are then run, and a checkpoint is written for each with a stable work-item key, a status, an input digest, and pointers to the output manifests. When the next round begins, the planner can see that section 101 already succeeded, section 302 failed, and section 401 surfaced the strongest signal. So the next move is not “search again,” it’s: skip 101, retry 302, and widen the neighborhood around 401. The checkpoint turns exploration from repeated searching into cumulative investigative work.

Compare this to the typical RAG/GraphRAG stack: a user asks a question, the system finds documents, maybe ranks and summarizes them, maybe layers on vector search, graph context, reranking, and a chat interface. However it is the stack assembles data, the system hands back information, and declares victory.

An important part of our discovery loop is that the system proposes the next move without pretending it owns the investigation. The system helps bound the next action, surface the most promising branch, and preserve what happened last time, but the user still steers.

This way, the system is strong where machines are strong: constraining search spaces, preserving lineage, checking coverage, remembering prior work, and producing bounded plans. Users remain strong where humans are strong: deciding whether the next move is actually the right move, recognizing when a branch is semantically off, changing the question, and judging what matters.

For most analyses, “finding something” is rarely the hard part of working across large datasets. What’s tougher is deciding what to do next without exploding the search space, wasting compute, or drifting into arbitrary exploration.

In Exeges, search results aren’t (just) answers. They’re entry points into the next move: compare these versions, inspect these changed sections, test this correlation on this cohort, widen this neighborhood, narrow that taxonomy, follow this chain.

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 Exeges, 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 the platform 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.

Exeges: 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 Exeges, 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 Exeges

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

AI analysis platforms deliver strong synthesis with ephemeral output: nothing compounds, nothing is kept in a form an auditor could replay, every analysis starts from zero. Agent-governance platforms preserve the other half; they can prove what an agent did, not whether its findings survive the evidence.

AI made analysis cheap, and in doing so made trust the scarce asset.

Value is now in a layer where work is retained and compounds. AI analysis is retained and connected to source material with durable annotations, verified at write time, that survive hostile review and let the next analysis start from what’s already known.

How it comes to know

A change arrives already annotated, section by section. An agent’s finding is filed on the change — verified against the text it cites before it can enter the record. An analyst’s disagreement is an annotation too, typed and anchored. A newer finding supersedes an older one, which stays in the record: retracted, still replayable.

That chain is the product: what your organization knows, and how it came to know it.

Who it’s for

Exeges is built for teams working in messy, changing, high-consequence environments — wherever the dataset is large, the ground shifts, and “show your work” is not optional.

Interested? Get in touch.

Architecture

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

Exeges turns complex, evolving sources into durable, auditable, queryable, evidence-backed knowledge.

The evidence foundation

Durable Artifact Plane The source-of-truth layer: deterministic identities, reproducible artifacts, manifest-based publishing, and stable contracts for downstream systems. Everything above this layer is a rebuildable projection, supporting both exploration and retention.

Annotation Substrate Stand-off semantics on stable document coordinates: annotation bundles and deterministic resolution keep human and machine judgments anchored to the spans that support them, durably and across versions. This is the substrate that lets knowledge work compound. We wrote about it here.

Understanding the sources

Multimodal Ingestion Turns any kind of source data, including documents, datasets, HTML, XML, and media, into durable, versioned artifacts. The front door of the platform and the first link in the evidence chain.

Document & Media Parsing 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 original structure.

Enrichment & Knowledge Derivation Combines machine enrichment with analyst-authored semantic layering: observations, states, transitions, derived from source artifacts, with human validation and curation as first-class knowledge surfaces.

Information retrieval

Search & Retrieval Stack Query understanding, hybrid retrieval, graph context expansion, and answer generation — a multi-stage retrieval system for evidence-backed exploration, not a thin keyword layer. Some notes here.

Projection & Runtime Projects durable artifacts into navigable runtime surfaces — graph, search index, and vector representations — through staged, rebuildable projection.

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

Control Plane & Orchestration Coordinates jobs, manages specifications, tracks execution, and governs change workflows — the 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

A finding in Exeges becomes part of the corpus. Exeges records what your organization knows as durable annotations, each anchored to the exact passage it describes, the way latitude and longitude anchor a point to the map. An extraction filed in a separate store can’t defend itself; an annotation can. It lives on the document, points at the text that proves it, and holds its position as the corpus grows and changes around it.

The record itself is a set of plain files: an open columnar format in your own object storage. If we disappeared tomorrow, you could read everything your team ever established with a laptop.

Three kinds of authors. One layer.

Deterministic passes flag whatever you need flagged. Every citation, every mention of a name, every dollar figure, every image — anything that can be identified mechanically is annotated across the whole corpus at once. This creates the scaffolding the other authors build on.

AI agents file claims, and every claim must survive verification. An agent’s finding is checked against the source excerpt it cites before it can enter the record. Quote text that isn’t there, and the whole write is rejected.

People adjudicate and extend. Analysts write notes with typed stances — support, dispute, question, validate — anchored like everything else, including to other annotations. Disagreement isn’t a comment thread; it’s part of the record.

What a seeded corpus unlocks

See what the record holds. Every annotation family is counted and mapped: where amendments concentrate, which sections carry budget language, what has been examined and what remains untouched. A corpus stops being a pile of documents and becomes an accounted-for structure.

Ask for the set — and get the proof. “Every section that adds an amendment and rescinds funding.” The answer is a proven set, not a relevance ranking that a typical RAG would generate: which conditions matched, how many sections, how many occurrences — selected by annotation membership, ordered by document order.

Ask in plain language. “How does this law affect workers’ tips?” Answers come back anchored: sections opened in place in the annotated corpus, with the amendments, budget references, and prior findings already visible on the passage the answer landed on. The follow-up question is a click, not another search.

When a source changes, the loop runs. A new version lands, every difference is annotated on arrival, watched sections dispatch an agent to investigate — and what survives verification joins the record. The loop from the front page, running on this layer.

First public demos are running summer 2026. Get in touch to see one.

Use cases

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

Exeges turns large, changing datasets into knowledge that compounds — mapped, monitored, investigated, and defended with evidence. The jobs below are the same whether your corpus is regulatory, financial, operational, or clinical; the examples are projections, not boundaries.

1. Change monitoring for critical documents and policies

Know what changed in the rules of the game.

The highest-signal event in a critical corpus is change. Exeges renders each new version into a verified change map — every difference filed as a durable annotation — and fires on the sections you have marked as yours, dispatching investigation on arrival, not just notification. And because monitoring runs across the whole corpus, it also surfaces the wide, quiet movements: coordinated language shifts, new exceptions, changing priorities across many documents at once.

Defense doctrine and sanctions · financial filings and debt agreements · reimbursement rules and clinical guidance.

2. Blast-radius analysis

“What do I need to care about now?”

Exeges models what sources do to each other, so a change arrives with its consequences attached. The answer is not a search result — it is a traversal of typed relationships, each one clickable to the text that proves it. And when you need the exact set, ask for it: every section that adds an amendment and rescinds funding — a proven set selected by annotation membership, with its evidence attached, not a search guess.

Which entities does a changed clause expose? Which facilities does a policy update touch? Which procedures does a new reimbursement rule move into risk?

3. All-source case building

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

Exeges makes a corpus navigable as a system, not just searchable as files — and every element of the picture is an annotation anchored to its sources, so the case survives handoff, scrutiny, and time.

A dossier on an actor or network · a counterparty or issuer investigation · a provider group or claims pattern.

4. Institutional memory that compounds

Every question your team ever asked, still verifiable years later.

Analyst and agent findings accumulate on the corpus as durable, excerpt-verified annotations. Provisional machine output is distinguished from validated conclusions; disagreement is visible and adjudicated — a dispute is itself an annotation, typed and anchored — never silently overwritten. New hires and new agent sessions inherit everything the team has established instead of re-deriving it, and leadership sees what is believed, what is contested, and what still needs review.

Most tools sell answers. This is the asset they cannot produce: an annotated corpus that is the firm’s memory.