An instrument for reading a body of work

What Ideoscopic is

Most tools for large bodies of text do one of two things: they search (find me the passages about X) or they summarise (tell me what this says). Both hide the whole. Ideoscopic does something else: it measures. You write a question in plain words (“Is the speaker recounting a moment from childhood?”, “How certain does the author sound?”) and it is asked of every passage independently. The answers are laid side by side, so you see where something rises and falls across a book, how two hosts differ, which of a hundred portraits cluster together, which papers argue for a hypothesis and which against.

Because measuring a whole book costs cents and takes seconds, and because every answer is cached, a reading stops being a one-off impression and becomes an object: a set of questions you can revise, fork, re-run and diff against another reading.

Around that core sits a platform:

• Libraries hold a body of work over time (texts, recordings, papers) and keep a graph of the people, works and ideas in them.
• Notebooks are where a maker reads: a live canvas of every passage beside an analyst who answers from the text and can ask new questions of the whole library as you watch.
• Apps put a library in front of an audience: a question box that answers with playable moments, a composed listening session, a live video room where the archive holds a seat, a visual studio.
• Endpoints open every library to Claude, agents and scripts through the Model Context Protocol.

Three kinds of work

The design rests on one division of labour. Each part does only what it is good at, and nothing is asked of a model that code can do.

In short: the frontier proposes, the literal reader measures, and code keeps both honest.

The objects

Everything in Ideoscopic is made of a few nouns. Knowing them makes the rest of the platform predictable.

Work

One book, episode, talk, poem, paper or portrait: the atom. It owns its text.

Passage

What a work is cut into, and what answers a question: a paragraph, an aphorism, a speaker’s turn. A passage from a recording keeps its start and end seconds and its speaker.

Span

A typed range over passages: a chapter, a speaker, a poem read aloud inside a talk, a moment the graph found. Spans may overlap; that is the point.

Collection

A set of works held together to be compared. It owns no text, so adding a work measures only that work and removing one recomputes nothing.

Question

One typed question (yes/no, a score, or a choice) with its wording, levels or options.

Lens

A versioned set of questions, with a record of every change and why. It also says what context each passage is read with (its chapter, its speaker).

Reading

One lens put to a selection of works, one or a hundred. Its measurements are what every canvas draws.

How a passage is measured

A question takes one of three forms, and each gives back a distribution rather than a bare label:

Each passage is sent once, with the context the lens asks for (“Chapter 4”, “spoken by the guest”), and every question is answered against it in parallel. Responses are cached by the exact request, so re-running an unchanged reading is free, and changing a question’s wording re-asks only that question. The confidence of each answer is kept, so a canvas can fade what the reader was unsure of.

How a question earns its place

A question isn’t kept because it sounds good. Before it joins a lens it is linted (one judgement per question, levels that describe situations, an escape option) and then probed: measured over every passage of the reading, and scored against four numbers.

A human hunch and a model’s proposal go through the same gate. When you say “I think what’s really going on is X”, Ideoscopic doesn’t agree with you; it writes X as a question, measures it, and reports whether it separates anything. If it passes, the lens gets a new version recording what was added and why; if not, you see which test failed.

Friction, forks and diffs

Three tools for finding where a lens is blind, and for comparing ways of reading.

Friction

Pairs of passages the lens places at nearly the same point. The literal reader is asked whether each pair really makes the same move; where it says no, the lens is missing a distinction. A frontier model can then propose questions that would separate exactly those pairs, and they go through the gate.

Fork

Copy a lens to take it somewhere else. Its measurements carry over, since the answers belong to the passage and question, not to the lens.

Diff

Two readings over the same passages, compared passage by passage and question by question: where they disagree and by how much.

Coverage

A lens says which overlays a work must carry (speakers, say). A reading reports which works it can reach and why not the rest, instead of silently putting podcast questions to a poem.

Notebooks

A notebook is where a maker reads. It reads some of a library’s sources through a lens of its own, and leads with a canvas where every passage is a point:

Beside the canvas, Read shows the whole text or transcript with a highlighter: pick a question and every passage is tinted by its answer; select passages to ask about them. The lens lets you reword, switch off or add questions; changes are staged and saved as a new version, and only what changed is asked again.

The analyst

The conversation beside the canvas is a frontier model with the reading mounted as tools: it can list and quote passages, look at distributions, find neighbours and friction, search the library’s graph, and propose questions. Two tools act on your screen: ask_question puts a new question to every passage and adds it to the notebook, and show_on_canvas arranges the canvas, so you watch the points move as the answers land.

Its answers are written in a small grammar that keeps every claim one click from the text:

Recordings play from the passage’s second: every player, card and canvas shares one playhead per recording, so anything can seek.

Writing good questions

The reader answering every passage is very literal: it weighs one passage against the words of the question. It doesn’t reason across passages, count, or compare dates. That is why it is consistent, and it shapes what a good question is.

• One judgement per question. “Hopeful and concrete” is two questions.
• Point at the passage. Ask about “the passage”, not the book or the author’s life.
• Levels describe situations, not degrees. “Names a place and a date” beats “somewhat specific”.
• Every choice has an escape, such as “none of these” or “other”.
• Never ask for what code can compute. Lengths, counts and dates are computed, not asked.

You don’t have to write them this way yourself: type the question in your own words, and it is drafted into this form and shown to you before it runs.

Libraries and profiles

A library is a body of work kept together over time: an author, a show, an archive, a field. It has four tabs: Notebooks, Sources, Graph and Apps. Its profile says what kind of body of work it is, and so what its graph looks for:

Sources and recordings

Text

Pasted or imported. Paragraphs become passages; structure a text already carries (numbered aphorisms, chapter headings) is read by code, not guessed.

A book of texts

A file of titles and texts, such as a book of poems. Each text is declared as a work in the graph, which is what lets later recordings be matched against it.

Papers

PDFs uploaded in the browser, or arXiv ids. Read into paragraphs, headings, figure captions and references, each passage keeping its page. See Papers.

Recordings

Audio or video uploaded once, straight to storage. A streaming service plays it and a transcription service hears it, both fetching the same file. It is read as speaker turns: one person’s consecutive words, merged, split when long. Every passage knows who spoke and when.

Portraits

Filmed monologues already hosted and transcribed, imported with their seconds. A long silence closes a paragraph, because pauses are part of the form.

There is deliberately no “fetch from a link”: media comes in only as a file its owner uploads.

How the graph is built

As each source arrives, the library’s graph grows: entities (the poems, people, places, works and ideas its sources refer to) and moments (the exact stretch of a source where each comes up). Every source goes through the same steps, and only the new source does:

1. 1
   Ingestcode

   The source is cut into passages. A book declares its texts (each poem, each essay) as it arrives.

2. 2
   FindJev

   A small lens of yes/no questions, one per kind of moment the library looks for, is put to every new passage.

3. 3
   Matchcode

   Every four-word run of a transcript is looked up in every text the library holds, so a poem read aloud is recognised by its words.

4. 4
   Judgefrontier

   A frontier model reads the flagged windows and marks each moment by quoting its first and last words, naming what it refers to.

5. 5
   Verifycode

   Each quoted boundary must be found in the source by exact match, or the moment is dropped. Characters and seconds come from the match.

6. 6
   Resolvefrontier

   Names become entities: exact names and aliases first, then one call per kind to merge variants (“Dante”, “Dante Alighieri”).

7. 7
   Linkcode

   A question and the answer after it, an introduction and the reading it leads into, become one event.

Adding a book makes earlier recordings matchable too, because the match index is built from the library’s own texts. A meaning layer (a vector for every passage, moment and entity) powers search and “more like this”, but vectors only propose: nothing they find is shown without the passage it points at.

On the Graph tab: a Map (entities clustered by family, people, works and ideas, sized by how often they come up), an alphabetical Index, and the library’s Questions. Open an entity for every moment it appears in, each one playable.

Papers: claims and evidence

A library of papers is read as an argument, not a pile of text. Before any model is involved, code declares each paper, its first author, every bibliography entry, and paragraph by paragraph what it cites, by matching arXiv ids, DOIs and author/volume/page.

Each claim and its evidence become one argument, and code adds the measurements inside the evidence, the figures it names and the papers it cites. The reading is literal-model first: the library’s own hypotheses, objects and methods become the options of a choice, Jev answers every paragraph against them, and the frontier model is called only to name something no option fits, which then becomes a new option.

Apps

An app puts one library in front of other people. Each is one deployment serving every instance by its own address, and reads its library only through the library’s endpoint with a key of its own. Its guests reach nothing else.

Making and publishing an app

1. Make it from the library’s Apps tab. It gets an address and a key for the library.
2. Shape it in the editor. The controls come from the app’s own manifest (headline, starter questions, manner and length of answers, stage colours, how deep visitors may go), so a new setting in an app shows up in the editor with no change to Ideoscopic.
3. Preview it. The preview is the real app in a frame, running your draft. Edits save as you go.
4. Publish to copy the draft live. Activity shows every question asked, with its cost, and a per-hour limit keeps visitors in bounds (never you).
5. Open it: private, by invitation (by email or a join link), or public, with or without anonymous guests.

The endpoint (MCP)

Every library is a server in the Model Context Protocol, which is the same surface the apps use. Point Claude, an agent or a script at it and it can read the library the way the apps do. Find the address and make a key under Connections in the library’s Apps tab:

{
  "mcpServers": {
    "my-library": {
      "type": "http",
      "url": "<endpoint from Connections>",
      "headers": { "Authorization": "Bearer <your key>" }
    }
  }
}

A key sees only the tools it may call. Keys are stored hashed, belong to one library, and stop working the moment they’re revoked.

The studio: new questions from outside

A key given the measure scope can do more than read: it can write a question in plain words (draft_dimension), ask the library to suggest some (suggest_dimensions), and measure one over a sample or every passage (measure, which returns at once while values fills in). This is what lets an app’s visitors ask the library something nobody has asked before.

• Same wording, same question. A crafted question is named by its words, so two visitors who ask the same thing share one question and one set of cached answers.
• Beside the lens, never in it. Crafted questions live in a scratch space next to the library’s published lens; they don’t change it.
• Spending is capped per key per day (three dollars by default), counted before anything is measured.

Accounts, access and trust

• By invitation. Ideoscopic is being made with a small group of people and their work; accounts are admitted from an allowlist.
• Makers own what they make. A maker reaches only their own libraries, and everything built on them: sources, readings, notebooks, media, collections. No other maker can see them.
• Audiences never touch the engine. Members, the public and anonymous guests use apps; apps read one library through its endpoint with their own key.
• Quotes are real. A moment exists only if its first and last words were found verbatim in the source; cards show the source’s words, never a model’s retelling.
• The gallery is open. Every app its maker has made public is listed in the gallery, for anyone to use.

Glossary

Argument

In a papers library: a claim and its evidence, with the values, figures and citations inside it.

Coverage

Which works a lens can reach, and why not the others.

Entity

A person, work, place, idea, hypothesis or instrument in a library’s graph.

Event

Moments that belong together: a question and its answer, an introduction and the reading after it.

Friction

Passages a lens places together that in fact differ: where the lens is blind.

Gate

The four tests a question passes before it joins a lens.

Jev

The literal reader that measures every passage.

Lens

A versioned set of questions, plus the context passages are read with.

Moment

An exact, verified stretch of a source where an entity comes up.

Probe

A trial measurement of a candidate question over every passage.

Profile

What kind of library it is (readings, conversation, papers, portraits) and so what its graph looks for.

Reading

A lens put to a selection of works.

Scope

What a key may do beyond reading; measure lets it craft and measure questions.

Span

A typed, possibly overlapping range over a work’s passages.