Medical devices · Étude de cas

Finding one table cell inside a 1,593-page technical document

Customer PoC · Demo5 min de lectureConsilience Team

Ce que ça vous donneAsk a 1,593-page technical manual "What's the allowable range for this parameter?" and get an answer that followed the table structure and cross-references like "Table A follows Table B," pointing to which cell of which table is the evidence.

The questions from a medical-device company are usually one line long. "What's the allowable range for this parameter?" The answer is definitely somewhere in the documentation. The catch is that the documentation is a single 1,593-page technical manual, and the answer isn't written in a sentence of body text — it sits in one cell of some table.

Reading that one cell isn't enough. Cross-references like "the value in Table A follows the conditions in Table B" are woven densely throughout the document, so reading one cell correctly means following along to another table and cross-checking. In the medical domain, an answer that's inaccurate or thinly supported is hard to accept.

This piece follows what happens when you put that one 1,593-page manual into a Consilience workspace and get answers that point to "which cell of which table is the evidence," with the tables and reference structure preserved. This is a customer PoC (proof of concept) and demo, and the quantitative evaluation results are not public.

One manual, 1,593 pages, and the answer is in a table cell

The stage for this case is the internal technical-document lookup work at a medical-device company. The document in play is a single technical manual of roughly 1,593 pages. The sheer length matters, but the real difficulty is in the structure. It is unusually heavy on tables, and cross-references — one entry pointing to another table or section — are densely interconnected. So the part that eats the most time isn't reading. It's finding where the answer is.

  • One technical manual, roughly 1,593 pages. The internal lookup work runs on top of this one book
  • Unusually heavy on tables. The key values are often held in a specific cell of a table rather than in a sentence of explanation
  • Cross-references are dense. Links like "the value in Table A follows the conditions in Table B" or "item X points to section Y" run all through the document
  • Some tables break across a page boundary. One table sits split across several pages
  • Looking at a single document fragment carved out as a search unit won't give you a complete answer, because a table's value is bound to a condition in another table
  • On some days several similar questions pour in

On top of this sits a condition particular to the medical domain. An answer that's inaccurate or thinly supported is hard to accept. As much as producing an answer quickly, you have to be able to cite which part of the document it came from.

Find the table, follow the references by hand

Here's the procedure today. You open a document viewer and search by keyword, or you trace your way through the table of contents and the tables yourself to find the value you need. Finding the right cell isn't the end. If that value carries a reference like "follows Table B," you have to flip over to Table B by hand and cross-check the condition.

The thicker the document, the more time interpretation takes, and missing a single reference makes the answer wrong. Worse, it's hard to notice that it went wrong. It's hard for a person to keep all 1,593 pages in their head and follow every reference without a gap. On a day when several similar questions pour in, someone had to repeat the same trace from scratch, one question at a time.

Putting the 1,593 pages in

Setup happens once. The goal isn't to make the document easier for a human to read — it's to make the tables and references something a machine can work with. The original document is never touched.

How the 1,593 pages go in

  1. Cmd+Shift+I → "Extract sources"

    Press the "Extract sources" button in the left sidebar, or Cmd+Shift+I (Windows: Ctrl+Shift+I), and the wizard opens. Drag the 1,593-page technical manual in. If the Activity center is showing a "Build this workspace's knowledge graph?" card when you first open the workspace, pressing "Build" on that card opens the wizard with the list already filled.

  2. Press "Import"

    The button wakes up once a workspace is open and at least one source is listed. It starts the moment you press it. You don't have to sit and watch the run; the app tells you when it's done.

  3. "Reading your files": tables stay tables

    The first stage on the checklist extracts the document into a machine-workable form. Here the tables aren't flattened into text — the row-and-column structure is preserved as is. Tables that break across a page boundary are merged back into a single logical table.

  4. "Extracting the knowledge graph": references stay edges

    The document is cut into search-friendly units, but cross-references like "from Table A to Table B" or "from item X to section Y" are indexed as connections. Tables stay tables, and references stay connecting edges.

  5. ✓ "Your documents are ready" → "Ask a question about your documents"

    When the checklist finishes, you go straight to asking. If some files hit snags, the header says some files need attention instead.

Asking about one table cell

Type it straight into the chat
"What's the allowable range for this parameter?"
→ It doesn't stop at retrieving the relevant document fragments and tables.
   It follows the reference connections to pull in the table
   the condition hangs on as well.
   The answer comes with which cell of which table is the evidence.

"Which table's conditions does this value follow?"
→ It follows references like "the value in Table A follows the
   conditions in Table B" and points out the table you need to cross-check.

(When it's more than a question or two, batch instead of chat)
→ Instead of running a large volume of questions one at a time,
   they're bundled and pushed through at once.
   The demo goal was about 50 minutes. That's a target, not a measured result.

The reason this works is in the setup. Because the tables are kept in their row-and-column structure, one specific cell is handled as a value; because the cross-references are kept as connections, retrieval doesn't stop at finding the relevant fragments and tables. It follows the connections to pull in the tables it needs as well, then answers from the evidence gathered that way while pointing to which cell of which table is the evidence. This is where the answers come from that you'd never get out of a single document fragment.

Finally, the generated answer passes through a medical-domain guardrail (a safety mechanism that filters out answers that stray beyond a defined standard). It's a step that catches unsupported claims or answers that fall outside the scope of the document one more time.

What changes

BeforeNow
You open a document viewer and search by keyword, or trace the table of contents and tables yourself to find the valueYou type the question as-is and get an answer pointing to which cell of which table is the evidence
When you hit a "follows Table B" reference, you flip over to Table B by hand and cross-check the conditionIt follows the reference connections, pulls in the table the condition hangs on, and answers
Miss a single reference and the answer is wrong, with nothing to citeThe answer comes with its evidence, and a medical-domain guardrail catches answers outside the document's scope one more time
When several similar questions pour in, you repeat the same trace from scratch, one at a timeA large volume of questions is bundled and pushed through in a batch at once

In short: index the document with tables kept as tables and references kept as connections, then hand back the answer with the table and cell it rests on attached. The trace a person used to follow by hand across 1,593 pages is followed by the agent instead.

Finding one table cell inside a 1,593-page technical document · Consilience