Roadmap

The target is the context-layer blueprint, an interactive concept demo dated 2026-09-28. Its idea in one line: parsers, NER models and vector databases are generic, and indx builds your context layer from them. A customer defines document types and fields. A router, one per job, sends each page through the method that works best for that type. Every correction a person makes becomes data that makes the routers better, and better routing moves every workflow downstream: Parse, Extract, Tag, Summarize, Search and Compare.

The blueprint’s own source says its data is invented: “every score is an illustration rather than a measurement.” This page plans the whole blueprint and plans none of that data. The rule, recorded as ADR-0073, is the one ADR-0057 already set for the web app. A screen nothing answers yet is a disabled sidebar entry. It may also be a placeholder page that says in words what will come there. It never shows a number, a chart, a sample document or a sample answer the service did not produce.

Every screen carries one of three states.

• Planned: nothing in the product stands behind the screen yet.
• WIP: the API or a current web-app screen already answers part of what the screen shows.
• Done: a person can use the screen in the web app, over real data, for what the blueprint screen does. The overview is the first to earn it.

The previous roadmap, read against the 2026-09-10 blueprint, is kept as roadmap, 2026-09-10. The engineering build order and the milestones before it are kept too.

At a glance

Blueprint screen	What answers today	State
Overview	The blueprint’s diagram with each part coloured done, WIP or planned and a legend, each part opening on a click what answers today (the spaces, readers and annotators as the snapshot lists them), live counts from /v1/capabilities and /v1/documents, the three parts with each section’s state, and the comparison by category with a state per row	Done
Data & labels	The Data & labels screen defines the installation’s document types: each with its fields and the parser whose format signature recognizes it, kept by /v1/types and written with the operator’s token (ADR-0075). A type can start from one of seven templates, copied on adding, and opens in a dialog where its fields are edited. Below them, every verdict reviewers kept on Extract and Tag, each with the document, page and answer it judged, kept by /v1/labels (ADR-0076), then the datasets, training or evaluation, gathered several documents at a time from the ones reviewed and the ones this browser kept, a document nobody reviewed waiting until it holds a verdict, with no document both teaching and grading one type and a count of the documents the installation can read again, kept by /v1/datasets (ADR-0077). Labels from a teacher model, rules and synthetic variations are Phase 9.	WIP
Embedding spaces	The four shipped spaces, listed live on the web app’s spaces screen	WIP
Routers	The Routers screen draws the one router an installation runs, the ladder, from sources to spaces as the snapshot lists them. It previews a sample’s or a file’s route page by page from /v1/plan before anything is read, and plans again when a reader is pinned (ADR-0063), fallbacks are turned off or signatures are not asked. Above it, the routers the installation keeps (ADR-0078): each a branch per type (reader pin, chunkers, lanes, spaces), a default branch and a recognizer, edited, published as immutable versions and restored, with the rows a picked router draws and the “not sure” row. The preview plans under a picked router, the Data store keeps documents under one, and Parse shows the branch each page took. A version promoted from an experiment names it; metrics per router over time are Phase 8.	WIP
Experiments	The Experiments screen scores candidate routes for one document type on an evaluation dataset (ADR-0082). Each candidate is a router branch (a reader, chunkers, lanes, spaces), run beside the router’s own branch for the type, in the background (ADR-0083). It shows, from stored results only, the checked answers each candidate got right, field by field, the pages still needing a person, the cost and time each run reported, and answers right against cost. Promote publishes a candidate as the router’s next version. The assistant that explains and proposes is Phase 10.	WIP
Parse	The Parse screen opens a document kept on the Data store, where documents are added one or several at a time: each page with its chunks drawn by role, the route the plan chose with its reasons and fallbacks, what read the page, the chunker version, and the format signature that fired. Recognition from your own examples is Phase 5.	WIP
Extract	The Extract screen opens a kept document: what the extractor lanes found, by label and normalized surface with the spellings the document printed, each occurrence at its page with its span marked and its chunk drawn on the page, and which lane found each label. No confidence, since the lanes state no comparable one. With the operator’s token, each occurrence is approved, corrected or rejected, and the document says how many it has had reviewed. A verdict may name the field of one of your types it fills; and a lane picker shows what one extractor found, the labels it lost included (ADR-0079). Few-shot examples are Phase 5.	WIP
Tag	The Tag screen opens a kept document: each facet the classifiers answered with its answer, the runners-up and the scores they returned, then each page’s own top label, the enrichers’ tags, and which classifier or enricher answered. With the operator’s token, each document facet is approved, corrected to another label or rejected. A lane picker shows what one classifier or enricher answered, the facets it lost included. Votes from labelled neighbours are Phase 5.	WIP
Summarize	The Summarize screen opens a kept document: the enrichers’ summary with each sentence citing the pages whose text holds it (computed from the text, so a sentence no page holds cites none), each page’s own summary, and the pages nothing read, and a lane picker shows one enricher’s own summary.	WIP
Search	The Search screen searches every kept document: words before meanings, each hit with each leg’s score and the fused one, opening in Parse at its page with its chunk drawn. Facets from your metadata are Phase 7, a space-version switch Phase 6.	WIP
Compare	Nothing	Planned
Quality	Nothing: a trace names every component that answered, per response, and nothing aggregates traces	Planned
Operations	Nothing	Planned

The blueprint’s last screen, “From today to this”, is the engineers’ version of this table, and this page replaces it. The web app has two real screens the blueprint does not draw, Endpoints and Deployment. They stay, under the workspace group, because they show the contract and the installation as served.

The phases, easiest first

Each phase names what its screens show, what already exists, what is missing, what it needs first, and what the screen must not show until something real produces it. A phase can start once the one before it is done. Within a phase, the screens are independent.

Phase 0 — An honest shell: the blueprint’s navigation, and the overview Done

What the screens show.

• The sidebar becomes the blueprint’s: Overview; then Improve (Data & labels, Embedding spaces, Routers, Experiments); Use (Parse, Extract, Tag, Summarize, Search, Compare); and Operate (Quality, Operations).
• The overview carries the thesis diagram (documents → your foundation → a router → downstream methods per page → your context layer, with approved outputs flowing back), the three parts (Improve, Use, Operate), and the comparison against a parser, an NER model and a vector database, by category and with no benchmark.

What was delivered.

• The new navigation. Its first group, “Try it today”, holds the Playground and the Data store as they were: they answer part of every Use screen, and none of those screens is built yet.
• Every blueprint section without its screen (PLACEHOLDER_SECTIONS in indx-ux), the Use ones included, is a dimmed link to a placeholder page. The page states the section’s roadmap state, says in words what will be there and what already answers, and links this page. Data & labels shows the installation’s live sources under its words.
• On the overview, the blueprint’s diagram, each part coloured done, WIP or planned, with a legend, and each part a popover saying what answers today, with the live list where the snapshot has one; live counts from /v1/capabilities and /v1/documents; and each section’s state in the three parts.
• In the comparison table, the indx column states each row’s state rather than the blueprint’s unconditional “Yes”.
• The features screen’s old URL, /features/, lands on Data & labels.
• The front page draws the same diagram as the product, every part finished and captioned “What indx is built to do” with a link here, the labelled target output ADR-0060 allows. Its navbar button is “Open app” and opens the overview.

Needs first. Nothing. It was front-end work over requests that exist.

Must not show. A workspace name, a label count, an accuracy or a type the installation did not return.

blueprint — Overview

Phase 1 — Use, one document at a time, over the API that exists: Parse, Extract, Tag, Summarize, Search Done

What the screens show. One picked document through one task:

• Parse: the page with its chunk boxes, the route and the reader, and a table of every page.
• Extract: fields with where each came from: the page, the box and the method.
• Tag: labels with their scores.
• Summarize: a summary with page citations.
• Search: a query over kept documents, with why each hit matched.

What was delivered.

• Upload once, look everywhere. The Data store takes one file or several, and the host’s samples, and keeps each with every installed lane at the units the Use screens read: spans on pages and chunks, labels and summaries per page beside the document’s. Its parameters sit in the overview diagram’s columns, each with the state the diagram shows. Every Use screen then opens one kept document, picked once and carried between screens. A kept document downloads from its row: what was generated from it as JSON, and the file it was read from where the host keeps sources (ADR-0084).
• Parse: each page with its chunks coloured by role, the route the plan chose with its reasons and fallbacks, what read the page, the chunker version, the chunks without a box and why, a table of every page, and the format signature that fired.
• Extract: what the extractor lanes found, by label and normalized surface, each occurrence at its page with its span marked and its chunk drawn, and which lane found each label. No confidence column, since the lanes state no comparable one.
• Tag: each facet’s answer, runners-up and the scores the classifiers returned, then each page’s own top label, the enrichers’ tags, and who answered.
• Summarize: the enrichers’ summary, each sentence citing the pages whose own text holds it, each page’s summary, and the pages nothing read.
• Search: one query over every kept document, words before meanings, each hit with each leg’s score and the fused one, opening in Parse at its page with its chunk drawn.

Left to other work.

• The finer blocks the sales page draws (paragraphs, headings and sections, tables on scans, diagrams, page furniture, continuation) stay their own track, the chunk entries; the screens draw finer boxes as they land.
• Parse shows the plan each kept run was decided under, before it read anything. It does not call /v1/plan ahead of a read, since a document is read once, when it is added.
• Filtering Extract, Tag and Summarize by lane, which needed the API to keep what the other lanes said. Phase 1b delivered it.
• Every Use screen stays WIP: what its blueprint screen still lacks comes with Phases 3, 5, 6 and 7.

Needs first. Nothing. It was front-end work over the API as it is.

Must not show.

• A “recognized as” beyond the format signatures that fire (invoice, process-chart).
• The nearest labelled pages.
• A confidence the answer did not carry.
• A space-version toggle. None of these has a source until Phases 3, 5 and 6.

playground — try it

features — chunk

features — classifiers, entity extraction, enrichment

blueprint — Parse

blueprint — Extract

blueprint — Tag

blueprint — Summarize

blueprint — Search

Phase 1b — Every lane’s own answer, so Extract, Tag and Summarize filter by lane Done

What the screens show. A lane selector on Extract, Tag and Summarize. Each shows what one extractor, classifier or enricher answered, including the labels, facets and summaries it did not win, beside the merged answer.

What was delivered (ADR-0079).

• The merge is unchanged: per unit, the first lane with an answer keeps each label, facet or summary part, and the trace names the winners.
• Beside it, each lane’s whole answer, under the reserved metadata key lanes, keyed by lane ID and in the shape of the merged keys: the facets, labels and summaries it lost included. The document block carries the document’s and the chunks’ answers and the entities; each page block carries its own.
• Every lane a request names is asked. A classifier is no longer skipped when earlier ones took its facets, so a request naming overlapping lanes pays for each.
• The Data store’s “auto” leaves zeroshot out, as it already left out vibrato: asked on the document, every page and every chunk, it takes over a minute per document on CPU. It leaves onnx out too, so a first visit waits for no model. Each still runs when picked by name, and the selector says what it costs: a warning on zeroshot, a softer note on onnx and the model embedding spaces.
• POLICY_VERSION and openapi.json do not move: this is execution output, and block metadata is a free object. The document block’s metadata grows with each lane asked.
• The Data store and the playground take several embedding spaces, classifiers, extractors and enrichers per selector, asked in the order they were picked, so which lane wins the merge is a choice.
• Extract, Tag and Summarize draw a lane picker when more than one lane answered. “Merged” is the kept answer, with who won each part and the review controls; a lane shows its own answer, read-only, since a verdict judges the kept answer.

Left to other work.

• A verdict on one lane’s answer. A label still judges the merged answer and names no lane.
• Documents kept before Phase 1b carry no lanes and draw no picker until they are added again.

Needs first. Nothing. Phase 1b is done.

Must not show. A lane’s answer the API did not keep, or an attribution guessed from the trace.

Phase 2 — Routers: the route shown before it runs, then a router per job Done

What the screen shows.

• One router per job: sources → recognize the type → per type, read, chunk, extract, embed and link.
• A “not sure” row that sends a page to a person.
• A route preview for a sample document, “decided before anything runs”.
• A version that is published.

What exists today.

• plan() returns a RoutePlan per page, bound to source_digest, capability_snapshot_id and policy_version. encode() runs only the routes and fallbacks it names.
• The ladder: text layer, OCR, a vision model, then manual review, which is terminal.
• Six readers.
• A reader pinned per request (capability_ids, fallbacks_allowed), chunkers named per request, and format signatures that nominate a parser ahead of the ladder.
• Step 1, delivered. The Routers screen draws that router as the blueprint draws one: sources, recognize (the observable formats, and the parsers a signature puts ahead of the ladder), read (the ladder’s rungs, a missing reader said to be missing), chunk, extract and embed, then the row where a page nothing could read goes to manual review. Its route preview plans a sample or a file, never reads or keeps it, and plans again when the reader, the fallbacks or the signatures change. It shows the plan’s status, the signatures that fired, the deployment’s estimate and every page’s reader, fallbacks and reasons.

Step 2, delivered: a stored, versioned router (ADR-0074, ADR-0078).

• A sixth store port, RouterStore, and /v1/routers, with memory, sqlite and postgres implementations. A version is a branch per type the workspace holds (a reader to pin, chunkers, lanes per unit, spaces), a default branch and optionally a recognizer (a classifier, the facet whose label names a type, a threshold). Versions never change: publishing writes the next one, and restoring publishes an old one again.
• A request names router: {id, version?}, and the server resolves it before planning, adding each type’s parser and the digests a person approved to a type. The plan names the version and lists every branch, the pages typed before reading (an approved verdict on the same bytes, else a format signature) and the recognizer. POLICY_VERSION moved to 0.10.0.
• A branch’s reader is pinned only on pages typed before reading. After reading, the executor gives every other page the recognizer’s type when it reaches the threshold, else the default branch marked for review, and runs only that branch’s chunkers, lanes and spaces. The trace records each page’s branch and why; a plan made under another version is a 409.
• The Routers screen edits the next version, publishes and restores, draws a picked router’s rows with the “not sure” row, and previews under it. The Data store keeps documents under a router, and Parse shows each page’s branch and review mark.

Left to other work.

• Metrics per router over time (Phase 8). Promotion from an experiment came with Phase 4.
• A recognizer learned from labelled examples (Phase 5), branches per region, and links as a branch step (Phase 7).
• Chunk-unit lanes in the editor; the API takes them.

Needs first. Nothing. Phase 2 is done.

Must not show. A metric per router or an end-to-end score that no experiment measured, a confidence threshold nothing reads, or a type the installation did not return.

blueprint — Routers

Phase 3 — Data & labels: types, fields, the review queue and datasets Done

What the screen shows.

• The customer’s document types, each with its fields (text, date, amount, ID, company, category) and its format signature.
• A review queue where a person approves or corrects an answer.
• Datasets that say what “better” means, one set for teaching and one for evaluation.

What exists today.

• Classifier facets and extractor spans answer per request.
• The caller’s own labels ride EncodeRequest.metadata.
• Kept documents persist behind DocumentStore and VectorIndex.
• The benchmark’s labelled cases (benchmarks/manifest.json) show what a labelled page must carry. They live in the repository, not the product.

3a, delivered: a persistent store and document types.

• Three store backends: memory, sqlite (one file) and postgres (a database every instance shares), each held to the same conformance suite and ranking a search the same way (indx-ranking).
• A third store port, SchemaStore, and /v1/types. A type is a key, a label, fields (text, date, amount, ID, company, category) and the parser whose format signature recognizes it. Types belong to one workspace per installation, never expire, and only the operator’s token writes one (ADR-0075).
• The Data & labels screen lists the types, edits their fields and signature, and creates new ones. Seven templates (invoice, contract, purchase order, resume, meeting minutes, inspection report, P&ID) each add a type with its fields in one click, copied so that editing it leaves the template alone (ADR-0086). A host without a token says its types are read-only.
• The deployed hosts keep everything in memory, and set no token, so their types and labels are read-only. Putting a managed Postgres behind them is deferred.

3b, delivered: the review queue.

• A fourth store port, LabelStore, and /v1/labels, with memory, sqlite and postgres implementations. A label is a verdict on one answer, approved, corrected with the right value, or rejected. It copies what it judged: the document’s digest and name, the block, page and box, and the entity or facet. It outlives the kept document it came from, belongs to the installation and is written with the operator’s token (ADR-0076).
• A second verdict on the same answer replaces the first, since a label’s ID is derived from the answer it judged.
• Extract takes a verdict on each occurrence and Tag on each document facet, a correction typed or picked from the runners-up. Each says how many of the document’s answers have been reviewed: the queue is the document’s answers less its labels, with no queue stored beside them.
• Data & labels lists every verdict kept, and the count is the rows stored.
• Who reviewed is a name the client may state, not an identity: authentication is still to come.

3c, delivered: datasets, with the evaluation set kept apart.

• A fifth store port, DatasetStore, and /v1/datasets, with memory, sqlite and postgres implementations (ADR-0077). A dataset is a key, a name, a purpose (training or evaluation), optionally a type, and documents, each a digest with its name copied.
• Membership is by document: adding one brings every verdict kept on it, so no document sits half in training and half in evaluation.
• No document is in an evaluation and a training dataset of the same type; the server refuses it, naming the document and the dataset it already serves.
• A dataset is a live view: its examples are the verdicts its documents hold now. Phase 4 records what each run scored.
• On Extract, a verdict may name the field of a type it fills, so an evaluation set can be scored field by field.
• Data & labels creates datasets, adds several documents at once and removes them, shows the ones still waiting for review, counts each one’s documents and stored verdicts, and downloads a dataset with its labels as JSON.

Left to other work.

• Verdicts on page and chunk facets, and on an entity no lane found.
• Datasets of queries or pairs (Phase 6). Phase 4 freezes the labels an experiment scores, so a dataset needs no version of its own.

Needs first. Nothing. Phase 3 is done.

Must not show. An accuracy per type, a growth chart or an example count that is not a count of stored examples.

blueprint — Data & labels

Phase 4 — Experiments: every method on your checked pages, and promotion Done

What the screen shows. For one type, each candidate route (a reader, a chunker, a method) scored on the pages a person already checked. It shows fields right, pages still needing a person, cost and time. The result appears field by field, as accuracy against cost. A Promote button makes the winner the router’s next version.

What stood in the way. The roadmap said this phase needed nothing more. It needed three things first.

• A kept document held no bytes, so nothing could be read again under another route.
• Nothing in the server outlived one request.
• The benchmark’s “fields right” checked that a value appears somewhere in the page text. It never read what an extractor answered, nor a reviewer’s verdict.

What was delivered.

• Readable evaluation sets (ADR-0081). A seventh store port, SourceStore, keeps what a kept document was read from, under the visitor and until the same expiry. Adding the document to a dataset copies its source to the installation, where it stays while a dataset names it. Data & labels says how many of a dataset’s documents are readable. A host that names no source store retains nothing, as before.
• One scoring core (ADR-0082). indx-evaluation holds pure functions over the wire types, and the repository benchmark’s entity recall now calls it. A reviewer’s verdict is an expectation: approved expects the answer, corrected the correction, rejected its absence. An answer is right when the route’s merged answer holds it on its page after NFKC folding. Offsets are not compared, since a candidate’s chunker moves them.
• Experiments. An eighth store port, ExperimentStore, and /v1/experiments. An experiment names an evaluation dataset of one type, a router and candidates, each a router branch. It freezes the labels its documents hold, and the router’s own branch for the type is always the first candidate, so every other one has a measured baseline. Each candidate reads each document as the router version it would become, with the document typed before reading.
• Runs in the background (ADR-0083). A job runner is a plugin a deployment names (INDX_JOB_RUNNER), and indx-jobs-memory runs one experiment at a time on a worker thread in the server’s process. Each candidate on each document is a stored result of its own, so progress is what the store holds, a stopped run resumes from the cells already scored, and a candidate that fails on a document is recorded with its error.
• Promotion. It publishes the router’s next version with the type’s branch replaced, and the version names the experiment and candidate it came from. It is refused unless the candidate scored every document, and when the router has moved past the version the run measured. Undoing it is Restore on Routers.
• The Experiments screen. A form for a new experiment, with candidates edited like a router branch and a shortcut that adds one per installed extractor. For each candidate: the checked answers right, the pages still needing a person, the cost and time the results reported, and a multiplier against production only when both scored the same documents. Then the same answers field by field, and answers right against cost or time. With no run, the screen says so.
• The stateful domain is its own package (ADR-0080). indx-workspace holds what an installation and its visitors keep, and indx-app-server is transport only.

Left to other work.

• The assistant, “Ask why” and a recommendation in words (Phase 10). The screen marks the most accurate candidate and recommends nothing.
• Accuracy by router version over time, and metrics per router (Phase 8).
• A comparison per field kind. Matching is exact after the fold, so a date written another way does not match.
• Scoring retrieval and tables on a customer’s data (Phase 6), and verdicts on one lane’s answer.
• Adding a candidate to an experiment. A new one is created from the old.
• A run that survives its process, more than one instance, and /v1/jobs (Phases 8 and 9).
• The deployed hosts keep everything in memory and set no token, so they show no experiment.

Needs first. Nothing. Phase 4 is done.

Must not show. A recommendation, a score or a cost multiplier that no run produced. When no run has happened, the screen says so.

benchmarks — the repository harness

blueprint — Experiments

Phase 5 — Recognition from examples, and few-shot extraction and tagging Planned

What the screens show.

• Parse says what a page was recognized as, and why: which labelled pages were nearest.
• Extract shows the examples it drew from the customer’s labelled pages.
• Tag shows the labels its nearest neighbours voted for.

What exists today.

• Recognition is written in code: format signatures under ADR-0045’s two-document rule.
• Embeddings and /v1/search can already find the nearest kept chunks.

What is missing.

• Recognizing a customer type from its labelled examples, with a threshold below which the page goes to review.
• Few-shot extraction: the nearest approved pages handed to an extractor lane as examples.
• Tag votes drawn from the nearest labelled documents.

Needs first. Phase 3’s labelled examples, and Phase 4 to show whether a few-shot route beats the one it would replace.

Must not show. A neighbour, a similarity or a vote that the index did not return.

blueprint — Parse

blueprint — Extract

blueprint — Tag

Phase 6 — Embedding spaces: say what “similar” means, then teach it WIP

What the screen shows.

• Customer spaces, such as equipment condition, commercial terms or drawing layout. Each has an angle, the types and parts it includes (text, table cells, extracted fields, the page image), a model and a version.
• “The 5 nearest” before and after, with right and wrong marks that become pairs.
• hit@5 on the customer’s test questions.
• A switch between space versions on Extract, Tag and Search.

What exists today. Four spaces: default-text, minilm-multilingual, clip-vit-b32 and hosted-text. Each request names the ones it wants in embedding_space_ids, and /v1/embed encodes a query in the same space.

What is missing. Three steps, in order:

1. A space as configuration over a shipped model: the angle, the types and the parts included, stored and versioned.
2. A space learned from right and wrong pairs, such as an adapter over a shipped model, with each version scored by hit@5 on the customer’s own test questions before it can be promoted.
3. The version switch on the Use screens.

Needs first. Phase 3 for the types, the pairs and the test questions. Phase 4 for scoring a version.

Must not show. A hit@5, a before and after, or a downstream improvement that was not measured on the customer’s questions.

extend — add an embedding space

blueprint — Embedding spaces

Phase 7 — Relationships, metadata and Compare Planned

What the screen shows.

• Documents related by shared metadata, such as the same equipment or the same supplier, drawn solid.
• Documents related only by resemblance in a space, drawn dashed as suggestions.
• For a pair, a field-by-field comparison with the differences marked, and buttons to confirm a relation or reject it. Either answer becomes a pair for Phase 6.
• Search facets built from the same metadata, and results expanded along links.

What exists today. Nothing that relates two documents. ADR-0029 and ADR-0037 both name “a relation between two spans” as the event that reopens their port shapes.

What is missing.

• A relation return shape, decided in an ADR.
• Cross-document links over the kept store.
• Metadata normalized to a master, so that every spelling of one supplier becomes one value.
• Comparison over normalized fields.
• Search filtered by metadata and expanded by links.

Needs first. Phase 3’s fields, and the persistent store.

Must not show. A relation, a similarity or a difference that was not computed from two kept documents.

blueprint — Compare

Phase 8 — Quality and Operations: every document in aggregate Planned

What the screens show.

• Quality: accuracy by type and task, the confidence distribution, metadata coverage and normalization, tag shares, and where labelling would help most.
• Operations: pages per route per day, router health (volume, share routed automatically, time, errors), the review queue by age and reason, improvement runs waiting for approval, and version history with restore.

What exists today. Every encode names each component that answered (ADR-0027), and kept documents hold their whole result. Nothing records traffic or aggregates it.

What is missing.

• A record of each run: plan, route, reader, time, errors and review outcome, kept per owner.
• The aggregates over it.
• Router and space versions that can be listed and restored.

Needs first. Phase 2’s versions, Phase 3’s queue, and Phase 4’s evaluation, so that “accuracy” means a measured number.

Must not show. A chart before there is traffic to draw it from. A range control never reaches past the first recorded run.

blueprint — Quality

blueprint — Operations

Phase 9 — Labels at scale: a teacher model, rules, synthetic variations, and an improvement policy Planned

What the screens show. Three more ways to add information beside a person annotating:

• A teacher model labels unlabelled pages, and a person spot-checks a sample.
• Rules act as weak labels.
• Synthetic variations of approved pages.

Operations adds a policy that re-trains after enough new labels, re-evaluates on a schedule, and promotes a better version automatically, asks first, or only reports it.

What exists today.

• The vision lane (generic-vlm) and the LLM lanes answer per request.
• Format signatures and the patterns extractor are hand-made rules.

What is missing.

• The teacher: the same lanes run offline in batch, with each result stored as a label waiting for review, never as an approved one, and a batch discarded when the spot-check disagrees.
• Rules weighted by reviewer agreement. A rule is never a routing signal on its own.
• Generated variations, with the method named on every one.
• The policy. It defaults to “ask me first”, and it never promotes a version under which any measure gets worse.

Needs first. Phases 3, 4 and 8.

Must not show. A projection of what more data would do. A projection is a model of the product, not a measurement of it.

blueprint — Data & labels

blueprint — Operations

Phase 10 — Assistants: improve with indx, and draft a router Planned

What the screens show.

• On Experiments, a chat that explains why a method wins, proposes a new candidate and runs its evaluation.
• On Routers, a sentence turned into a draft router over the customer’s types, metadata and spaces.

What exists today. indx-llm, the chat-model adapter the LLM lanes share (ADR-0038).

What is missing. Both assistants. Each one may propose only actions the API can perform: a candidate route, a router draft, an evaluation run. Each may cite only runs that happened. A draft stays unpublished until a person publishes it.

Needs first. Phases 2 and 4, because an assistant can only propose what a router can express and cite what an evaluation measured.

Must not show. A diagnosis that no measurement supports.

blueprint — Experiments

blueprint — Routers

Deferred

Work that is wanted and not scheduled. It is not a blueprint screen, so it carries none of the three states and waits on no phase order.

Accounts — a user name and a password, joined by an invitation an administrator issues Deferred

What it shows.

• A sign-in page: a user name and a password.
• A sign-up page that opens only with an invitation key. An administrator issues the key, and it works once.
• For the administrator, the invitations issued and whether each was used, and the users.

What exists today.

• A visitor is the indx_owner cookie, which names a browser and not a person. Kept documents belong to it.
• One shared secret, the operator’s token (INDX_WORKSPACE_TOKEN), writes types, labels, datasets, routers and experiments (ADR-0075). Whoever holds it is the operator.
• A label’s reviewer is a name the client states, not an identity (ADR-0076).

What is missing.

• Users, their password hashes, sessions and invitations, kept by the installation behind a store port like the others.
• The administrator: who the first one is, and how an invitation is issued, listed and revoked.
• The owner of a kept document becoming the signed-in user, so that what a person kept follows them to another browser.
• What a signed-in user may write. Today the token decides that, for everyone who holds it.
• A reviewer on a label that the server set from the session.
• An ADR for all of it. It replaces or keeps the token, and it says what happens to documents kept under a cookie.

Why it is deferred. The deployed hosts keep everything in memory, so an account would not outlive a restart. A managed Postgres behind them is deferred too, and comes first.

Needs first. A store on the deployed hosts that survives a restart.

Must not show. A reviewer or an owner the server did not authenticate.

A guided tour — the improvement loop, step by step, on a real document Deferred

What it shows. A button that starts a tour of the loop the sidebar does not explain by itself. A type, a label and a dataset mean little to a new user until one has been made in front of them. The tour takes each step itself and says in a sentence what the step is for and what it produced:

• keep a document, and open it in Parse;
• define a type with a field;
• approve or correct an answer on Extract, which makes a label;
• gather the document into an evaluation dataset;
• run an experiment, and promote the candidate that won.

A user may take over at any step and continue by hand.

What exists today.

• The host’s samples, which the Data store keeps in one click.
• The same sequence, already written once: the tour clip in indx-demos drives the real screens through these steps and names each control by its message key (ADR-0085). It is a recording script that runs beside the app, not something the app runs.
• The placeholder pages, which say in words what a section is for.

What is missing.

• The tour in the web app: its steps, each anchored to a control, each sending the request the control sends.
• Short documents made for it, one or two pages each and at least two of one type, so that a type, a field and an evaluation dataset each have something to hold. The samples were chosen to show readers, and are longer than a tour needs.
• Somewhere a visitor may write. Types, labels, datasets and experiments belong to the installation and are written with the operator’s token, and the deployed hosts set none. There, the tour would stop after Search.

Why it is deferred. The deployed hosts are where a new user arrives, and they are read-only for every step past Search. The screens the tour walks also still change with Phases 5 and 6, and each change would move its steps.

Needs first. Accounts, above: they are how a visitor on a deployed host comes to write a type and a label. Phase 5 is better done first too, so that the tour can end on a correction that changes what Parse, Extract and Tag answer.

Must not show. A prepared answer. A tour document is a real file read by the installed readers, and every step shows what the service returned for it (ADR-0073).

What the blueprint draws that the product must not invent

These are illustrations in the blueprint, and each appears in the web app only once something real produces it:

• every accuracy, hit@5, precision and faithfulness figure, and every before-and-after delta;
• the method cards’ scores, review shares and cost or time multipliers;
• every chart: growth, trade-off, version history, the confidence histogram, the heatmap, weekly series, pages per day, and the tag scatter;
• the “what would more data do” projection;
• label, example, pair and queue counts, volumes, times, error rates and budgets;
• the sample workspace, documents, boxes, values, neighbours, relations and summaries;
• the chat’s answers.

Related reading

• Roadmap, 2026-09-10: the previous roadmap, kept for the record
• Build order and milestones: the engineering order and step list before that
• Features: every entry, with examples and source links
• Benchmarks: the repository harness, which shares its scoring core with experiments
• Playground: the Use screens as they run today