Augment It
A federated workshop for augmenting data with AI.
One shell. Six microfrontends. A small set of disciplined surfaces for the work of collect → prompt → request → review → highlight → insight. Each surface owned by its own repo; all composed by a single host at runtime.
- Module Federation
- Turborepo
- Rsbuild
- Docker
- Submodules
- Shared UI
Where This Came From
The Problem
AI-assisted data augmentation has a lot of moving parts — sources, prompts, requests, responses, highlights, insights — and the obvious approach is one big app that does it all. But each surface wants its own owners, its own deploy cadence, its own scale. A monolith chokes when six teams want to ship at six different rhythms. A backend-only microservices approach doesn't surface the UI handoff cleanly.
The Realization
Each stage of data-augmentation work is its own workshop bench. Owning the UI of each bench as an independently-deployable microfrontend, composed by a shell at runtime — that's the shape that fits the work. Module federation, browser-side, with a shared UI package for the primitives that have to look the same everywhere.
The Unlock
Six microfrontends. One shell. One shared packages/ui. Pipeline order: record → prompt → request → response → highlight → insight. Each microfrontend owned by its own repo, wired into the host as a git submodule, loaded at runtime as a federated remote. The shell composes them; provenance carries through.
The Six Microfrontends
Each owns one bench in the workshop. The shell loads them in flow order; the data contract between them is the canonical record shape that record-collector commits to producing.
Pulls records in from anywhere — files, APIs, CSVs, scraped pages, manual entry — and stages them in a canonical shape for the rest of the pipeline. The upstream constraint everything else inherits from.
Author, version, and pick prompt templates outside the application code. Templates ship with the run, not buried inside it — so a prompt change isn't a code change, and 'what prompt did this response come from' is always answerable.
Render the fully-interpolated request — model, parameters, the prompt with every variable filled in — exactly as the provider will see it. A human signs off (or batch-approves) before tokens are spent.
Inspect what came back. Side-by-side request, raw response, and parsed structured output. Accept moves the record forward; reject flags the template or the source record for another pass.
Pull excerpts, quotes, and salient fragments out of records or responses. Keep what's worth keeping with provenance back to the source; drop the rest. Not every augmented record needs to survive in full.
Aggregate highlights into themed views. The layer above individual records, where patterns earn their keep. Records are atoms; highlights are excerpts; insights are the patterns that emerge across many of both.
The Architectural Bets
Module federation is the central bet. Each of the principles below falls out of taking that bet seriously — and refusing to soften it into a more familiar shape.
Each Surface, Its Own Repo
Six microfrontends, six independent git histories, six contributor circles, six deploy cadences. The host shell loads them at runtime by name — no shared release train, no monorepo build coupling beyond the shared UI package.
Federation Across Submodule Boundaries
Module federation isn't just sibling workspaces. The host resolves remotes that live in git submodules — proving the contract holds across the boundary that actually matters: independent repositories, not sibling folders.
Shared UI Lives in packages/ui
Visual primitives that show up in more than one microfrontend get promoted into the shared package early. RecordCard was first; ErrorBoundary rode along. The rule: any component likely to be reused gets considered for shared/ui before being authored inside an app.
Pipeline Order Matches Pipeline Concerns
record → prompt → request → response → highlight → insight. Six microfrontends in flow order, each owning one bench in the workshop. The shell composes them; provenance carries through from ingest to insight.
Human Always In The Loop, Just Not In The Way
Request review before tokens are spent. Response review before downstream stages consume. Highlight curation before insights aggregate. The pattern: humans gate the transitions, machines do the work between.
Provenance Is A Feature
Every highlight links back to a source record. Every response links back to a prompt template + a request. Every prompt template carries a version. 'Where did this come from' is always answerable — by design, not by reconstruction.
Three Eras of Getting It Right
The current architecture is the third attempt. The first two are documented in the changelog, not hidden — because the journey is the spec.
Bolt-era monolith
Two weeks of vibe-coding on Bolt.new produced a single React app with Supabase + three LLM providers and ~25 components covering every stage of the workshop. Working demo on Jan 27. Never going to be the production system, but the spec-by-running-code that proved what shape the workshop wanted to be. Archived to mpstaton/augment-bolt-code; design memory preserved as analysis files.
First extraction attempt
Two months later: try to peel record-collection off into its own frontend repo. Three commits over two days, one DB swap (Turso out, Supabase in), then stop. The question shifted from 'can we extract this?' to 'what's the shell this gets extracted into?' — and that question would steer the next four months.
Federated rebuild
Tanuj brings up a module-federation starter — Vite host shell + two microfrontends + shared UI package — in late July. The same day, three of the six microfrontends become real git submodules. The day after, RecordCard gets promoted into shared UI. By mid-August the specs folder is real, the bolt era is formally archived, and the first analysis spec is written.
Public splash + history
GitHub Pages splash ships at lossless-group.github.io/augment-it. The full changelog — backfilled from git history and the GH issues list — captures the three-era arc and lands on the splash and in the rolled-up Lossless feed.
The People Behind It
Michael Staton
Architecture · Specs · Brand
Drove the Jan 2025 Bolt-era exploration, the March 2025 extraction attempt, the July repo restart, and the documentation discipline (vision spec, workflow doc, record-collector analysis) that made it possible for other contributors to onboard.
Tanuj Siripurapu
Module Federation · Shared UI
Brought up the working federation starter in late July 2025 — host shell, two microfrontends, shared packages/ui — answering the question that had been blocking the project since March. Wired the first three microfrontends as real submodules the same day; promoted RecordCard into shared/ui the day after.
Watch the Workshop Take Shape
The splash carries the full changelog — including the Bolt-era and extraction-attempt entries — alongside curated context. The GitHub repo carries the actual code, the submodule wiring, and the open issues for the specs still being written.