What output/stripe Reveals and How to Improve Extraction

After reviewing output/examples-known/stripe, one thing becomes clear: extraction already gives us strong implementation context, but there is still room to make the system much smarter.

This post summarizes what the current output does well and what should come next.

What is inside output/stripe

The folder contains three core artifacts:

1. design.md
2. tokens.json
3. design-preview.html

1) design.md: human-readable design blueprint

design.md combines YAML frontmatter (machine-usable tokens) with narrative markdown (human reasoning).

What it gives us:

• semantic token layer (colors, typography, radius, spacing)
• confidence indicators (for colors, buttons, cards)
• inventory summary (variables, color hits, components)
• rationale and evidence for selected values

This is ideal for handoff between design and frontend because teams can inspect both the result and the reasoning.

2) tokens.json: machine-oriented source of truth

tokens.json is the programmatic layer. It includes:

• extracted source metadata
• resolved theme/profile
• normalized token candidates
• confidence scores
• decision evidence traces

The strongest point here is traceability. A chosen token can be tracked back to CSS variables, selectors, and computed style evidence.

3) design-preview.html: visual audit artifact

The preview file is useful for fast QA:

• visual sanity checks
• selector/link metadata
• side-by-side perception of extracted patterns

It helps confirm whether the extraction still “looks right” before shipping code.

Why this is already valuable

Even today, output-driven generation is better than prompt-only generation for implementation work.

Prompt-only gives speed. Output-driven gives reliability.

With output-driven artifacts, UI decisions become:

• reproducible
• auditable
• measurable

That is exactly what engineering teams need for consistent production UI.

Where extraction can improve

The current output is strong on colors and component inventory, but spacing and layout rhythm can be captured with more precision.

Gap 1: spacing intelligence is still shallow

Spacing tokens in many extractions are too generic (or collapse to simplistic values), while real UI quality depends heavily on spacing hierarchy.

What to capture better:

• margin/padding distributions by component type
• vertical rhythm scale (e.g., 4/8/12/16/24/32)
• section-to-section spacing patterns
• container/gutter behavior across breakpoints
• spacing exceptions (hero, nav, dense tables, modals)

If this improves, generated pages stop feeling "close enough" and start feeling structurally faithful.

Gap 2: responsive intent is underrepresented

Current extraction identifies many static values, but responsive behavior is often implicit.

What to add:

• breakpoint-specific spacing maps
• layout transitions (grid -> stack, nav compaction)
• typography and rhythm shifts per viewport

Without this, reconstructions look good on one viewport and drift on others.

Gap 3: weak learning across runs

Today each extraction is mostly a one-off decision process. We should turn it into a learning system.

Why ML is a strong fit here

Your intuition is correct: ML can improve extraction quality over time.

A practical model can be trained on historical extraction outputs and human corrections to improve token resolution quality, especially in ambiguous scenarios.

What an ML-assisted extraction loop could do

1. Rank better candidates Predict best token candidate from multiple evidence sources (CSS vars, computed styles, DOM context, frequency, component role).

2. Detect suspicious decisions Flag low-confidence or contradictory picks (for example, dark theme detected but background resolved to white).

3. Infer missing structure Estimate spacing scales and component density even when raw values are noisy.

4. Recommend post-extraction fixes Generate “likely improvements” before design.md finalization.

Useful training signals

You can train with:

• extracted candidates + chosen final tokens
• confidence values
• selector and component context
• visual diffs against accepted references
• manual overrides by designers/devs
• downstream defects from generated UI

This creates a feedback loop where every extraction becomes new training data.

Suggested architecture for the next phase

A pragmatic path:

1. Keep deterministic extraction as base layer Do not replace heuristics. Use ML as a ranking/refinement stage.

2. Add a candidate scoring model Input: token candidates + context features. Output: ranked candidate + calibrated confidence.

3. Add a spacing profiler module Build spacing histograms/scales per component and breakpoint.

4. Add quality gates before final output Automatic checks for contradictions, outliers, and accessibility risks.

5. Store correction telemetry Track manual fixes and feed them back into retraining.

This gives gradual improvement without destabilizing the pipeline.

Practical takeaway

output/stripe proves the current extraction system is already useful and production-relevant.

The next leap is not “more prompt engineering.” It is:

• deeper spacing/layout capture
• responsive pattern awareness
• ML-driven refinement from accumulated extraction history

That is how extraction evolves from a strong static snapshot into a continuously improving design intelligence system.