Sprint 1 — Sep 14 to 18

The first sprint after the KR1 review. Deadline Friday Sep 18, with a demo of whatever is done. The plan was re-pointed on Sep 14: the KPT of Sep 12 asked for one architecture and value story, one end-to-end demo, a measured baseline and validation on production, and the Sep 14 review asked that the advantage be defined for customers and backed by real data and inspectable results, with new functionality only where it strengthens that story. The router is a component of that story, not its objective, and this page is written in that order.

Seven stories, highest priority first. Each has the outcome as a user story, its acceptance in Given / When / Then, its Definition of Done and how it is validated. What is not done by Friday is carried, not stretched.

Two of the KPT’s asks are already in the repository and are reported as such rather than redone: every deploy workflow runs the public smoke and the @deployed acceptance scenarios against the host it deployed (deployment), and the benchmark already measures speed, cost and routing accuracy. What was missing is the story around them, and the review of the labels the accuracy figures rest on.

Status on Wednesday

Where each story stands, so the week can be read without a git log. A story is Done when its Definition of Done is met, WIP while something in it is still owed, and Planned until it starts.

Story	State	Where it stands
1. The advantage on one page	WIP	Engineering’s half is built: the app at the root, the docs under /docs/ (#167, #168, #169). The six steps and their screenshots (#179) were replaced on Thursday by a page that shows the output rather than describing it (ADR-0060; how the page evolved). Owed: the CEO’s wording, and the deploy that puts it on the live URL.
2. The app cleaned of mocks, one end-to-end demo	Done	The mock package gone and every screen live or disabled (#170, #171), the parser per page (#172), the five views (#173), search (#174), the encode cache (#175), the two-parser scenario and the demo script (#176).
2b. The docs playground goes dark	Done	/docs/playground/ and its Japanese route redirect to the app’s, and the docs live spec is retired (#177).
3. Three label-free numbers	Done	The benchmarks page and the docs front page lead with seconds per page, cost per page and the CPU-only share; every accuracy figure sits behind a note that counts reviewed labels rather than asserting. Reviewing the labels is the team’s, and the count is what says how far it has got.
4. Production proves itself, UI included	Done	just frontend::e2e-deployed runs in all three deploy workflows beside the smoke and the @deployed scenarios (#178).
5. One deck in, one Draw.io file out	Done	The parser’s own distribution writes the file, the demo host serves it and the Chart tab downloads it (ADR-0058); tests/fixtures/office-process-chart.drawio is compared byte for byte.
6. Azure and GCP, time-boxed	Planned	Thursday, which is the story’s own trigger.

Two things gate Friday that are nobody’s story: just bench::run is re-run so the published figures are the run of the week, and then the AWS deploy ships everything above to the live host. The demo is against that host and nothing else.

Where things stand on Monday

• Value story. No one-pager. The closest pages are how it works, goals and the target architecture.
• Demo. The docs playground plans, encodes and searches real uploads on the deployed host and shows, per scope, the selected parser, its reasons and the fallbacks retained. The web app runs one live feature, encoding a document; its routing results are fixed examples.
• Numbers. The committed report carries latency and cost from usage, the CPU-only share of pages, and accuracy against labels nobody has reviewed yet.
• Production validation. Smoke and @deployed run in the three deploy workflows. The docs and web-app live Playwright specs exist and run by hand only.
• Three clouds. Terraform for AWS, Azure and GCP validates in CI and each has its page. AWS is deployed and serving; the Azure and GCP workflows have never been run.
• Per-page parser. The router decides per scope and keeps the fallbacks. No committed document whose pages route to different parsers, and no pin (ADR-0050, unbuilt).
• Few-shot and Draw.io. Nothing in code. The process-chart parser writes the graph to the page block’s metadata["process_chart"] (ADR-0043).

1. The advantage on one page, with evidence behind every step

As a salesperson, I want one page that walks Customer Data → Page-level Understanding → Best Parser → Structured Data → Customer-specific Customization → Search / Agent, so that I can explain Index Everything in one glance and click into the proof at each step.

• Given the production host, when I open its root, then each of the six steps has one sentence, one screenshot from real data, and one link to the live playground state that produced it.
• Given a step, when I click its proof, then I land on the playground with that document loaded, not on a JSON file.
• Given the narrative is the CEO’s to own and the week is short, when Tuesday starts, then engineering has posted the proposed flow and six sentences below for the CEO to edit or reject, so the page never waits on a blank sheet.
• Given the page, when the CEO reviews it, then the wording is whatever the CEO kept, the evidence is engineering’s, and neither changes the other’s half without asking.
• Given a sales site is wanted rather than documentation and the web app is what we showcase, when Friday comes, then the web app is the root of the production host on AWS and the docs site lives under /docs/: / redirects to /en/, the sales page is the app’s front page at /en/ and /ja/, with two buttons, “Documentation” and “Open the playground”, and a language toggle. It is deployed, and shown on the live URL for feedback.
• Given the app moves to the root, when it is built, then its base path becomes empty, examples/app2.py mounts the docs export at /docs and the app export at /, and the redirects that today send /app to /app/en/ send / to /en/ instead. The /app/ references in the smoke scripts, the web app’s Playwright specs and the docs pages follow, and a new ADR records the layout, superseding the /app mount in ADR-0051 and the overview-as-locale-root in ADR-0052; neither record is edited.
• Given the docs write their links as absolute paths and set no base today, when they move, then the Astro base becomes /docs, one script rewrites every absolute link, and the route check and the docs Playwright config learn the prefix. One mechanical pull request.
• Given the sales page is the app’s front page, when it renders, then it is a screen package like the others (frontend/packages/screen-home, modelled on screen-overview) on the locale’s root route without the app shell; today’s overview screen moves to /overview/ and the navigation points there. The buttons link to /docs/getting-started/ and to the playground at /en/playground/, which story 2b makes the one playground.
• Given each step’s proof is a link, when I click it, then the app playground opens with that sample and feature preselected from the query string, which story 2 adds.
• Given the AWS deploy builds the image from the branch and the Dockerfile already builds the docs site and the web export, when the pull request merges and the deploy workflow is dispatched, then the layout ships with no infrastructure change.
• Given the AWS and the Azure/GCP smoke scripts assert HTML on /, when / becomes a redirect, then they follow it, and the AWS smoke additionally asserts a marker of the front page, so a regression is caught.
• Given the live page, when the CEO reacts, then the feedback is written into Sprint 2 as the sales-site scope.

Nothing to spike: the app is exported for the root it is served from, so the base-path question of the earlier draft is gone.

Proposed flow and six sentences. The working copy until the CEO edits it; each step names its proof.

1. Your data, where it is. Files come from your file share, S3 or a URL into a service that runs in your own cloud; nothing leaves it. Proof: the deploy screen reading the live capability snapshot, and the AWS page.
2. Every page understood before anything expensive runs. A cheap preflight sees what each page is: native text, a scan, a slide with a diagram, a drawing. Proof: the plan for the mixed sample, page by page.
3. The best parser per page, and the reason. The router picks the cheapest parser that can read that page, keeps the fallbacks and says why. Proof: two pages, two parsers, the reasons shown.
4. One structured result. Text, boxes, entities, languages, tags and a diagram’s symbols and connections, in one document under one contract. Proof: the process chart drawn over its slide, the entity spans in the text.
5. Your formats, from your examples. A customer’s own output shape comes from configuration and examples, not engineering. Proof this week: the Draw.io file from a slide; next, the few-shot library.
6. Ready for search and agents. Chunks with boxes and embeddings, searchable the moment encoding ends. Proof: a search hit naming its page and box.

Headline over the six: Index Everything turns the documents you already have into data your search and your agents can use, inside your own cloud, choosing the right parser page by page.

Definition of Done. The web app at the root of the AWS production host and the docs under /docs/; the sales page live at /en/ and /ja/ with / redirecting to it; the two buttons and the language toggle working; the six proofs linked; one Playwright spec asserting the front page shows the headline and both buttons resolve; the smoke scripts following the redirect and asserting the front-page marker; the ADR recorded; the CEO’s feedback collected on the live URL at the Friday demo.

Validation. just frontend::ci green, the boundaries script carrying the new screen’s edge like every other; just docs::ci green with the base set and every localized route verified under /docs/; the new spec green locally; screenshots in both languages on the pull request; after the deploy, the AWS public smoke and just frontend::e2e-deployed <url> green on the host.

How the sales page evolved

The acceptance above describes the page as it was planned on Monday. It changed twice during the week, and this is the record of why.

1. Tuesday Sep 15 — the headline and six steps. The app took the host’s root and the docs moved under /docs/ (ADR-0056); screen-home rendered the headline and the six steps proposed below, each linking to a playground state (#167, #168, #169).
2. Wednesday Sep 16 — six screenshots of real runs. Each step gained a screenshot captured from the playground by e2e/capture.spec.ts and just frontend::capture (#179). Accurate, but a salesperson still had to explain what the screenshots meant.
3. Wednesday and Thursday — concepts. Two rounds of standalone page concepts were drafted outside the app and kept in the repository for comparison: examples/landing-claude/ (a to h) and examples/landing-chatgpt/ (01 to 08). The drafts moved from telling the story (a page per step, evidence panels) to showing it: concept G let a visitor hover a real page, and concept H put three pages on a stage with the route indx chose for each.
4. Thursday Sep 17 — concept H in the app. screen-home was rebuilt as concept H (3c02e1d0): a notice page with a table, a scanned attachment and a process-chart slide from the samples; per page the route indx takes today (text layer, OCR, process-chart parser, with the fallbacks); hover any block and the stage shows the block indx hands over, a whole paragraph with its section and defined terms, a table with normalized cells, a diagram’s nodes and edges. That output is the target, merged by hand from today’s line chunks, and the page says so. ADR-0060 records why the sales page may show it while every workspace screen stays bound by ADR-0057, and removes the six screenshots and the capture recipe. The page has its own palette and type, English and Japanese copy, and a light and dark switch.
5. Thursday Sep 17 — for the visitor’s own files. The file names on the stage became example names in each language instead of the samples’ real ones (2c7fc3e2), so a visitor pictures their own documents; and the app shell’s light, dark and system menu became the same one-click switch as the sales page (1f6506cc).

What this changes for the story. The six proofs in the Definition of Done are superseded by ADR-0060 rather than met; the proposed six sentences above stay as the CEO’s working copy. The stage now promises more than encode returns: paragraph, heading, table and diagram blocks, sections, page furniture, continuation across pages, OCR corrections, defined terms, cross-references and image descriptions. Each is a Planned entry on features, listed against the page on the roadmap and sequenced in the build order, together with the playground work that brings its layout closer to the stage: the run on top, the page beside its output, hover a block to read it.

2. The web app cleaned of mocks, and one end-to-end demo in its playground

As a prospect, I want every screen of the web app to show only what the API returned, and to upload or pick a document set in its playground and watch it come out structured with the parser chosen per page and the reason, so that nothing I see pretends, and I trust that the machine chose the parser and not a person.

What exists. The playground’s feature dropdown has nine entries and only “Encode document” calls the API; the other eight show canned results, two of them in a shape the API does not have. The encode response already carries the per-page plan (selected parser, reasons, fallbacks retained), each page block’s provenance (the parser that actually read it), the entity spans, the classification and enrichment tags, the chunk boxes and the process-chart graph; the app renders only the boxes. Spaces, sources, the endpoints and the encode run are live; overview and features mix live and mock parts; library, guide and deploy read the browser-only store.

Rule for the week: the app shows nothing the API did not return.

• Given a screen that is live over the API, when I open it, then it stays as it is.
• Given a screen that mixes live and mock parts (overview, features), when the mock parts are removed, then only what the API answers remains on it.
• Given a screen with no backend yet (library, guide, deploy, and any other found on Monday’s pass), when I look at the navigation, then its button is present but disabled, with a “not yet available” hint, so the blueprint stays visible and nothing on it pretends.
• Given the playground, when I open it, then there is no feature dropdown: one Encode run over an upload or a sample, and the result has views, each fed from the response. Pages: the image, the chunk boxes, and per page the parser planned, its reasons, the fallbacks retained and the parser that actually read it. Entities: spans marked in the text. Tags: classification facets and enrichment tags. Chart: symbol and connection counts and the node list from the page’s process_chart metadata; the overlay is a stretch. Search: live, and two lanes fused by rank in the browser – the words a chunk carries, and POST /v1/embed for the query against the chunk vectors when the run embedded into a space; a hit names its page, its box and the lanes that found it, and a run with embeddings off is still searchable by text.
• Given search runs in the browser, when I search, then the index is the documents this browser encoded and nothing else: the vectors are kept in the browser’s own storage so they survive a reload, never sent to the server, and never shared between visitors, and the search view states that scope in one line (“searches the documents you encoded in this browser on this deployment”). The demo host’s encode cache changes nothing here: it answers only someone who uploads the same bytes, and lists nothing.
• Given the demo host offers only default-text, which is CRC32-hashed character trigrams in 256 dimensions and no model, when a query is embedded, then the vector lane is worth what that hash is worth and no more – which is why the text lane exists. A separate pull request installs the fastembed extra so minilm-multilingual is offered, and makes auto prefer a text-retrieval space: sourcesFrom sorts by dimension descending, which on a host with that extra puts clip-vit-b32 (512) ahead of minilm-multilingual (384), and CLIP’s text tower is a caption encoder with a 77-token limit, not a retrieval model.
• Given a committed sample whose pages differ, a native-text page, a scanned page and a process-chart slide, when I encode it, then at least two pages show a different parser, with reasons.
• Given “Few-shot detection” and “Relationships” have no backend, when the mock path is deleted, then they are gone from the playground and stay on the roadmap as Planned.
• Given the mock package and the browser-only store, when the last screen stops reading them, then they are deleted, the boundaries script drops that edge, and the blueprint Playwright spec is rewritten to assert live screens and disabled buttons.
• Given the shell still carries the blueprint’s invented chrome (a named workspace that is also the breadcrumb root, an avatar, a badge, a tagline), when the mocks are gone, then the workspace card becomes a menu with the one workspace this host has and a demo-mode note, the badge, the avatar and the tagline go, and the status pill opens a health page showing what /health and the snapshot answer, with a link to the deployment screen for the rest. The endpoints screen links to the references the host serves (Scalar, Swagger) and opens each operation into a request sample in Python, TypeScript and HTTP, and the deployment screen’s media types read as badges, one colour per family, the full type on hover.
• Given a document already tried, when anyone encodes it again, then the answer is immediate: the demo host, which already keeps a digest-keyed render cache, caches encode responses in memory keyed by a digest of the request body with the per-run request id removed, bounded the same way, and a hit is labelled in the response and shown as “served from cache, computed at …” so it is never mistaken for a live run. No pre-warming; the rehearsal after a deploy warms the samples. A demo-host convenience, not a product feature.
• Given a link to the playground carrying a sample in its query string, when I open it, then it is preselected, and one carrying run=encode encodes it on landing (?sample=<id>&<lane>=<off|auto|id>&run=encode, the sandbox’s grammar); this is what story 1’s proofs point at.
• Given the demo script, when anyone on the team runs it against the production host, then it takes under five minutes and every step is a request the API already serves.

Definition of Done. The mock package gone from the workspace and every navigation button either opening a live screen or disabled; the shell reduced to what the host answers and the health page behind the status pill; the endpoints detail and the reference links; the media-type badges; the mixed-page sample under examples/samples/; the five views on the encode result; live search; the encode cache in the demo host with its label; the query-string preselect and run; one acceptance scenario asserting that two pages route to two parsers; the demo script as a numbered page beside the story; one recorded run; the encode Playwright spec extended to assert the per-page parser line and the absence of a feature dropdown. Pinning a parser (ADR-0050) is not this week.

Validation. just ci and just frontend::ci, then the scenario against the production host with just test::bdd::deployed <url>.

2b. The docs playground goes dark on Friday’s deploy

As the team, I want one playground, so that every demo, link and screenshot shows the same surface.

• Given the app playground shows routing, the chart counts and search, when Friday’s image ships, then /docs/playground/ and /docs/ja/playground/ redirect to the app playground, as two routes in examples/app2.py beside the root ones.
• Given the docs pages link to the docs playground, when the redirect lands, then those links are repointed to the app playground in the same pull request.
• Given just docs::e2e-deployed runs the docs live spec against the docs playground, when the redirect lands, then that recipe and spec are retired, and story 4 wires only the web app’s live spec.
• Given the docs sandbox code and its fixture capture are then unreachable, when Sprint 2 is planned, then deleting them is its first candidate; this week is the redirect only, so the deletion is one reviewable pull request of its own.

Definition of Done. The two redirects, the links repointed, the docs live spec retired. Sequenced after story 2, never before.

Validation. The AWS public smoke, which asserts HTML on the redirected paths, and the web app’s live spec on the host.

3. Three numbers a salesperson can say out loud, none of them accuracy yet

As a salesperson, I want speed, cost and resource use as three headline figures with their caveats one click away, so that the story has numbers and I do not overclaim.

• Given the benchmarks page, when I open it, then the first thing on it is three figures that depend on no label: seconds per page, cost per page routed against every page through the vision model, and the CPU-only share of pages, each restating the committed report and recomputing nothing.
• Given a figure, when I expand it, then I see the case count it rests on and its known gap in one sentence.
• Given the labels have not been reviewed, when I read the page, then every accuracy figure sits behind a “labels under review” note, and the story page quotes none of them.
• Given the labelled cases, when a label is reviewed, then the manifest records who reviewed it and when, and the accuracy figures are cleared for Sprint 2 or the label is fixed.
• Given the seven axes of the Sep 11 plan, when I read the table below the figures, then each axis reads “measured”, “measured, labels under review” or “not yet, needs X”; no competitor column until a like-for-like number exists.
• Given the reference customer’s deck is customer data, when the benchmark runs on a machine that has it, then it scores as a case marked not redistributable and is skipped everywhere else without failing.

Definition of Done. The three label-free figures and the axis table on the benchmarks page; accuracy demoted until reviewed; the label review started, with a reviewed-by field in the manifest; benchmarks/README.md no longer stale against the report; the non-redistributable case admitted.

Validation. just bench::run regenerates the figures shown, and no accuracy figure appears above the note.

4. Production proves itself after every deploy, including the UI

As the team, I want the deploy workflow to fail if the site or the app cannot run the demo, so that “deployed” means “the demo works”.

• Given a deploy to any of the three clouds, when it finishes, then the smoke, the @deployed scenarios and the web app’s live Playwright spec have all run against the public host, and a red one fails the workflow.
• Given the demo script of story 2, when the deploy runs, then at least one @deployed scenario walks its first two steps: plan the mixed sample, assert two parsers.

Definition of Done. just frontend::e2e-deployed wired into the three deploy workflows; the story-2 scenario tagged @deployed; the docs live spec retired with story 2b. Most of this exists; it is listed so it can be reported as done rather than as still owed.

Validation. The deploy workflow’s own run, green on AWS.

5. Customer-specific output: one deck in, one Draw.io file out

As a manufacturing customer, I want the process chart Index Everything read from my slide as a .drawio file, so that the structured result lands in the tool my engineers already use.

• Given the process-chart sample, when I encode it in the playground, then a download gives a file that opens in diagrams.net with the same symbols and connections.
• Given the committed deck, when the test runs, then the produced file matches the fixture byte for byte.

This is the only new feature of the week, because it is step 5 of the story made concrete. The recipe format, the example store and the lookup by signature stay out; they are Sprint 2 candidates, and the benchmark keeps reporting few-shot setup as not implemented.

Definition of Done. The expected file under tests/fixtures/; the download in the playground.

Validation. The fixture compared byte for byte in just test::unit; the file opened by hand in diagrams.net.

6. Azure and GCP attempted once, time-boxed

As the team, I want the Azure and GCP deploy workflows tried against a test subscription and project, so that we learn whether the three cloud patterns cost a day or a sprint, without letting them eat this week.

• Given stories 1 to 5 are on track, when Thursday starts, then one person dispatches the Azure workflow and then the GCP one, each with a hard stop of half a day.
• Given a run reaches the public smoke and the @deployed scenarios green on its hostname, then that cloud is recorded as demonstrated on its deployment page, with the date and the hostname.
• Given a run fails or the half day ends, then the point it reached and the blocker are recorded on the page, the fix is a Sprint 2 candidate, and no more time goes to it this week.
• Given either stack was applied, when Friday ends, then it is destroyed and the destroy is in the record.

Definition of Done. Each of the two workflows dispatched once, or explicitly skipped because stories 1 to 5 needed the time; the outcome on each deployment page either way. Skipping does not count against the week.

Validation. The workflow runs linked from the Azure and GCP pages, green, red or skipped as they came out.

Not this week

• Publishing any accuracy figure until the labels are reviewed.
• A domain or DNS change; the host’s URL layout changes (the app at the root, the docs under /docs/), its hostname does not.
• Guaranteeing Azure or GCP; story 6 is an attempt with a hard stop.
• Parser pinning and the no-fallback flag (ADR-0050).
• A competitor column in the comparison.
• The CAD scope page, carried to Sprint 2.
• Deleting the docs sandbox code; this week it is redirected (story 2b), and the deletion is Sprint 2’s first candidate.
• Backends for the disabled screens (library, guide, deploy); they are disabled buttons this week and Sprint 2 candidates after.
• A product-level result cache; the week’s cache lives in the demo host only.

Friday

The demo shows, in this order: the sales page opened at the root of the AWS host, the end-to-end run in the app playground on AWS production with the docs playground redirecting, the three label-free numbers, the post-deploy checks green on AWS, the Draw.io download, and the Azure and GCP attempts as they stand. The CEO’s feedback on the page is collected in the room. Whatever did not reach its Definition of Done is named as carried into Sprint 2, which is planned at the end of the demo.