Verified live: the render, inspect, patch and verify loop removed 2 defects on the offer page.
How it works - chapter: quality loop
How a page is checked and corrected before anyone sees it
A draft page is rendered in a real browser on a phone and a desktop, inspected for defects, corrected with governed patches and checked again. This chapter explains the loop, what stays stable while pages change, and what is still unproven.
The loop
Five steps, repeated until the checks pass
- 1
1. Design
An agent builds the draft from named sections and the governed composed grammar, using object verbs only.
- 2
2. Render
The draft is rendered in a headless browser at phone width and at desktop width.
- 3
3. Inspect
Checks look for horizontal overflow, low contrast, small tap targets, broken images, a call to action below the fold and nested interactive elements.
- 4
4. Patch
A model proposes object patches. A deterministic tool applies them to the draft, so the model never edits files directly.
- 5
5. Verify
The page is rendered and inspected again. The loop is finished when no defects remain.
Verified live
One real run on the offer page
- 2 to 0
- Defects found, then remaining
- 2
- Viewports checked
- 6
- Defect kinds detected
Mobile and desktop, after one correction cycle
Phone and desktop
See the list in the loop above
Edits keep their identity
Each correction is a patch against one addressed unit, not a rewrite of the page. Three kinds of identity are involved, and they are different things.
- Section ids look like s_ followed by lowercase letters and digits. They stay the same when a section is edited, so history and measurements stay attached.
- Composed node ids label the layout nodes inside a composed section. They are a separate namespace from article node ids.
- Tracking is a governed object. Events go to the shared analytics sink, keyed to these stable ids.
Every write goes through a lock, a record version check and a content revision, so two editors cannot silently overwrite each other. Fields marked private never reach readers.
Status
What is proven and what is not
Verified live: edits address sections by stable id, so ids do not change when content does.
Built, not yet proven live: the campaign path that serves one immutable snapshot per experiment arm.
Deployed, not yet used: the edge function that assigns experiment arms. No experiment is configured today.
Verified offline only: the join between experiment arms and revenue. No conversion winner can be claimed from it.
Planned: any statement about which variant converts better, which needs real traffic and complete attribution.
The honest gap: misaligned rows
The loop does not yet detect misaligned rows. If buttons in one row have different sizes, or one card in a row is framed and its neighbours are plain, every check above still passes. A person has to notice it.
This is why an earlier showcase page looked crooked even though the loop reported no defects. Detecting unequal sizes and mixed variants within a row is a planned check, not a built one. Until it exists, pages follow a written rule: items in one row share the same size and the same variant, and only rows differ from each other.
Questions
- Does the loop publish the page?
No. It works on a draft. Publishing is a separate step and releasing to production is another one after that.
- Can I tell which variant converts better?
Not yet. Experiments are built, but none is running, and the revenue join is verified offline only. This site makes no winner claims.
- Can the loop make the page prettier?
No. It finds measurable defects and fixes them. Taste, layout balance and row alignment are not part of what it checks today.