Building a staged research pipeline over a fixed text corpus

What we learned engineering Taaweel: why research questions need stages, an evidence ledger and a model that argues against itself.

Taaweel is our research engine for Quranic inquiry. The product is described on its product page; this article is about the engineering lessons, which apply to any research system built on a fixed body of text, such as case law, standards or technical documentation.

Why a single prompt is not enough

Ask a general model a deep question about a text and you receive a fluent answer you cannot audit. You do not know what it counted, which passages it saw or which readings it dropped. For research, the path to the answer is part of the answer.

Stage the work

We split the engine into stages that mirror how a careful researcher works: plan, map the corpus, collect evidence, build a model of the answer, attack it, revise it and write it up. Each stage persists its output, its jobs and its cost. A run can be stopped and resumed, and one stage can be rerun with different settings without redoing the rest.

Use code for counting and the model for judgement

Every occurrence of a root across the corpus is found by a deterministic concordance over a read-only database. Clustering of those occurrences into patterns of use is computed, and the distinguishing vocabulary of each cluster is ranked statistically. The model is then asked to interpret what the numbers show, rather than to produce the numbers.

Compute the verdict

When competing readings are tested, a model makes one judgement per test, but the final accept or reject decision is computed in code from the results. A single failed test, or survival only by an interpretive rescue, rejects a reading. This keeps the decision rule explicit and reviewable, and stops a persuasive paragraph from overriding a failed test.

An evidence ledger

All evidence goes into a ledger with a tier, a source and a locator. The final report cites ledger rows, and every citation must resolve to a row; a report that cites something not in the ledger fails validation. Readers can follow any claim back to its evidence.

Make the system argue against itself

A dedicated stage mines hard cases, the passages most likely to resist the proposed reading, and a red team writes objections into a ledger. Each objection is ruled on, answered, sustained or carried forward, and the report shows the rulings. The result is more honest, and more useful to an expert, than a confident single answer.

Label certainty

Claims carry labels such as mainstream, minority view, author position or provisional, enforced in the data schema rather than left to prose. Readers can see at a glance how much weight a statement bears.

Limits we state plainly

Language models are probabilistic; runs on the same question can differ; and the tool assists scholarly work without replacing scholars. Stating this in the product, not only in a footnote, is part of building trust.

What carries over to your domain

• Persist each stage; make runs resumable and costs visible.
• Keep sources read-only and cite to a ledger.
• Count with code, interpret with models, decide with explicit rules.
• Build the adversary into the pipeline.

If you have a corpus and questions that need audit trails, our agentic AI development team builds systems like this.