Milestones
The KR1-framed step list this site carried until 2026-09-11, kept for the record.
indx decides how to read a document before paying to read it, then reads it into text, metadata, chunks and embeddings for an index you control. This page is the step list the site carried until 2026-09-11, kept for the record: eight outcomes in build order, each naming the KR1 target it moves. The current roadmap is read against the product blueprint instead, and KR1’s four targets are provisional, never reviewed by the person who set them, so read them as the numbers the benchmark computes rather than as agreed goals. Each step is one outcome; open it for what it unlocks, which KR1 target it moves, and what it needs first. A step that moves none of them says so. The engineering reasons behind the order are on the build order page, and every step links to its entries in features. A dashed Planned badge marks a step that is not built yet. The week-by-week work toward Oct 1 is tracked on the sprints pages.
KR1 — Win on technology
Section titled “KR1 — Win on technology”The company objective this work serves. KR1 is four targets, and each step below names the ones it moves by these IDs.
| ID | Target |
|---|---|
| KR1.1 | Routing accuracy of 90% or better across the ten priority data types |
| KR1.2 | 70% or more of standard documents handled on CPU alone |
| KR1.3 | Inference cost reduced by 40% or more against a fixed pipeline |
| KR1.4 | A similar form stood up in under one day |
The steps
Section titled “The steps”1. A document is planned and read on CPU, with a plan you can inspect, across eleven file types
What is possible. Send a PDF, an image, a scan, a spreadsheet, a Word or PowerPoint file, a text or CSV file, or an email. indx returns a plan saying which reader will handle each page, why, and what it should cost, before anything expensive runs. Execute the plan and you get text, page and chunk blocks with positions, document metadata, detected languages, an optional classification and embeddings. Recognised invoices go to a specialist parser, with the generic path kept behind it.
KR1 target. The foundation all four are measured on. The benchmark already computes KR1.1 and KR1.2 over real documents; KR1.3 is still an estimate and KR1.4 does not exist yet.
Needs first. Nothing. This is what ships today.
2. Anyone can drop a document into a page on this site and watch it planned, read and searched
What is possible. A sandbox page on this site takes a sample or an uploaded document, shows the plan, then shows each page with its chunks drawn where they sit on the page, and lets you search across them. It runs against the real service, so what a customer sees in a meeting is what the product does.
KR1 target. None. This makes the product visible to a prospect; it changes nothing about what indx reads or what it costs.
Needs first. Step 1.
3. Quality is measured against labelled documents, not estimated from a table Planned
What is possible. A small set of benchmark documents carries the text and fields a correct read must produce, so “how well did it read” becomes a measured number. That number is what settles whether the free Office reader is good enough, whether a heavier model earns its cost, and which of two extractors is better. The remaining six readable file types are scored, so coverage is counted rather than claimed.
KR1 target. KR1.1, which needs every priority type scored, and KR1.3, which needs a measured quality side to be credible.
Needs first. Step 1, and public documents for the unscored types, which are being sourced now.
features — read difficult enterprise data; measure the Office readers against a library
4. Every result names the component that produced each part of it
What is possible. A result says which loader fetched the document, which observer inspected it, which reader read each page, which chunker cut it and which classifier labelled it. That is what makes an answer auditable, and it is what lets a caller later ask for a specific component by name.
Where it stands. Delivered on both sides. A plan names the loader, the sniffer and the observer that produced it, and an encode’s trace names those plus the chunkers, the language detector, the classifiers and the entity extractors, each by the distribution that provided it.
KR1 target. None directly. This is enabling work that steps 5 to 8 depend on.
Needs first. Step 1.
5. Pages and chunks are classified, and names, dates and amounts are extracted, in Japanese and English Planned
What is possible. Today a whole document can be given labels. After this step each page and each chunk can be, and people, organisations, places, dates and amounts are found and pointed to in the text they came from. Four extraction engines of increasing cost are available, and the measured set from step 3 says which one to use.
Where it stands. The contract release is done, extraction ships with all four engines, the three shipped classifiers answer per page and per chunk as well as per document, and all of it is visible in the playground. The measurement exists too: the labelled set carries entity labels on five scopes, and the benchmark scores each engine alone against them. On this corpus of forms the hosted model reads the most and is the only engine that costs money, the pattern engine is next and free, then the ONNX model, and the dictionary lane the least, mostly for a granularity it cannot express. What remains is width: 30 entities is a number to widen rather than to trust.
KR1 target. None directly. It widens what indx returns from a document; how correct that output is gets measured with the labelled set from step 3.
Needs first. Steps 3 and 4. This step also bundles every pending change to the wire contract into one release, so integrators regenerate their client once.
features — classifiers per page and per chunk; entity extraction; NER for Japanese and English
6. A whole folder or bucket is processed on CPU, with progress, cost and failures reported Planned
What is possible. Point indx at a folder, an S3 prefix, or a Google Cloud or Azure container and it processes everything in it, reports progress, isolates the documents that fail, and states the CPU-only rate and the cost per thousand documents. This is the corpus-scale claim behind “classify a corpus on CPU”.
KR1 target. KR1.2 and KR1.3. Both are only real at corpus scale, reported per thousand documents.
Needs first. Step 3 for the harness that scores a run, and step 4 so a failed document names what failed.
features — corpus runs and incremental results; classify a corpus on CPU
7. Chunks follow sentences and paragraphs, and a caller can choose how large they are Planned
What is possible. A PDF is cut into lines today, so a wrapped sentence becomes two chunks. After this step chunks follow sentences and paragraphs, still with their position on the page, a caller can ask for coarser or finer chunks, and a deployment can name which chunker to use. Which boundary retrieves better is decided by the measured set from step 3.
KR1 target. None. The benefit is better search results over what indx produced, measured against step 3.
Needs first. Steps 3 and 5, because a chunker that rewrites text must not move the positions entity extraction already points to.
8. Output is exported to an index you control, and a new similar format is set up from a few examples Planned
What is possible. Processed content is written into a vector index you own, with the embedding space and query encoder named so an agent can search it. A recipe, a handful of examples plus a schema, is stored per recognised format, so a new document type that resembles a known one is set up in days rather than with a new pipeline. Authentication, rate limiting and metrics arrive with these, because this is where the service starts holding state.
KR1 target. KR1.4, which recipes are for; the benchmark currently reports it as not implemented. Export moves none.
Needs first. Step 6, because both of these are decided once the corpus run has produced measured baselines.
features — agent-readable export
Related reading
Section titled “Related reading”- Goals & non-goals — the outcomes in plain language, and what indx refuses to do
- Features — every entry above, with examples and source links
- Build order — why the steps are in this order
- Benchmarks — the numbers each step moves