Sprints

One sprint is one week. This page is the frame the sprints share: where the work stood after the KR1 review of 2026-09-11, the four things Index Everything has to prove, what Oct 1 has to show, and the two principles every sprint follows. Each sprint has its own page with its highest-risk questions, its tasks, its Definition of Done and how it is validated. Next week’s page is detailed; the ones after it are placeholders until the previous sprint closes. The roadmap reads the same work against the product blueprint, screen by screen, and the build order holds the dependency reasoning; this page holds the calendar.

Where things stood on Sep 11

• The playground processes real uploads against the deployed service.
• Named-entity recognition, PowerPoint parsing and process-chart detection landed (features, ADR-0043).
• Initial CAD support was shown: a DXF drawing’s text layer and layouts (ADR-0048).
• The web app exists with every blueprint screen over a browser-only store, and its playground runs one real feature, encoding a document (ADR-0051, ADR-0052).

What has to be proved

Development centres on demonstrable technical differentiation, not on a feature count. Four axes:

1. Self-hostable and enterprise-controlled. Unlike an externally hosted document-processing service, the same foundation runs inside the customer’s environment. The deployment pages describe the image and the AWS target that exist.
2. Cloud flexibility. The model lanes adapt to the customer’s cloud-native AI services: AWS with Bedrock, Azure with Azure OpenAI, GCP with Google AI. Not every configuration has to be built now; the architecture has to be shown to support each.
3. Customizable parsing and routing. A document becomes pages, the router picks the best parser per page, and the result is one structured output. Customization comes from configuration and examples, not bespoke engineering. DENSO is the reference case of a customer with company-specific workflows.
4. Few-shot customization. Customer-specific extraction and output formats from a handful of approved examples, including structured diagram output such as a Draw.io-compatible file.

The advantage is expressed in numbers, on purpose-specific benchmarks rather than one score: parsing accuracy, routing quality, speed, resource requirements, cost, few-shot performance, and complex documents and diagrams. The benchmarks page is where those numbers live.

The Oct 1 checkpoint

Oct 1 is an evidence checkpoint, not a perfection milestone. It has to show:

• A basic deployment story across AWS, Azure and GCP patterns, from generic Terraform templates. Customer-specific networking, security and AI-service setup is paid implementation work and stays out.
• A self-hosted or customer-cloud deployment, demonstrated.
• Page-level best-parser selection through the router, demonstrated.
• A few-shot, custom-parsing workflow, demonstrated.
• An initial quantitative technical comparison.

The target outcome behind all five: a live web-app playground that shows clear technical value.

Principles

• Build → Demo → Test → Prove → Reuse. Nothing counts until it is shown, and what is shown is kept.
• Deadline → highest-risk problems → Definition of Done → validation → stop. Each sprint names its deadline, attacks the riskiest question first, states what done means before starting, validates against that, and stops.

An Intern Demo Day will be organized so interns and full-time members demo what they built and get feedback; it is placed in the last sprint before the checkpoint.

The sprints

Sprint	Dates	Theme	State
Sprint 1	Sep 14 – 18	The advantage on one page with evidence, one end-to-end demo on production, three label-free numbers, the Draw.io file	WIP
Sprint 2	Sep 21 – 25	Planned at the end of Sprint 1	Planned
Sprint 3	Sep 28 – Oct 2	The checkpoint week and Demo Day	Planned

A sprint page moves to Done when its Definition of Done is met and validated, and stays as the record of what was shown.