Screenshot to Implementation Parity

Position this module against the two before it. Modules 2 and 3 were about generating from references and exploring directions, where the reference was an influence to borrow from. This module is the opposite situation: the design already exists — an approved Figma frame, a signed-off mockup, a page being rebuilt during a migration — and the implementation has to match it. The skill is no longer interpretation; it is verification.

Name the core failure up front: agents are good at producing something that looks roughly right and confidently calling it done. The phrase the build closely matches the design is not evidence. Parity in this module means a comparison a third person could check: the reference screenshot, the implementation screenshot, and a list of mismatches with severities and fixes.

Set expectations on tooling. The worked examples assume a coding agent that can run a browser capture script — Playwright in our examples — but the loop itself is tool-agnostic. If the audience cannot script captures yet, the manual version of the same loop still works: capture by hand, compare side by side, log mismatches in a file. The discipline is the content; the automation is the convenience.

Walk the four artifacts and why each one exists. The reference alone is not enough, because an image cannot be argued with precisely — people end up debating whether the spacing feels right. The spec turns the image into something checkable: layout regions, the grid, the type scale, the spacing rhythm, colour roles, and the components the agent can identify. Force measurements where they can be measured and ranges where they cannot; a spec that says generous padding will drift, a spec that says 24px vertical rhythm with 32px section gaps will not.

The spec is reviewed by a human before the build. That review is cheap — ten minutes on a text file — and it is where misreadings get caught. In one of the worked runs later in this module, the spec review caught that a plan card's emphasis was a border plus a background shift, not just a badge. Catching that in the spec cost one comment; catching it after the build would have cost a round.

The capture must be scripted so the comparison is like-for-like on every iteration: same route, same viewport sizes, same wait conditions. Hand-taken screenshots at slightly different widths produce noise that the parity check then reports as mismatches. And the diff is a report, not a feeling — the next slides define exactly what goes in it.

Walk the diagram from the left. The reference and spec are the human-owned contract. The build capture is agent-run and scripted, taken at the reference viewport and the other standard widths. Both feed the parity check, which is also agent-run: it compares the captures against the reference and the spec and reports observable mismatches only — a region in the wrong place, a type size off the scale, a gap that breaks the rhythm, a colour that left its role. Each mismatch gets a severity and a proposed smallest patch.

The verdict gate is the structural point of the diagram. The gate passes when no P0 or P1 mismatches remain and every P2 has either been fixed or accepted by a human. Differences that come from deliberate token mapping are listed as accepted, not hidden. Crucially, the agent never declares parity itself; it produces the report and the verdict recommendation, and a human signs.

The fail path goes to a patch pass — one layer per round, which the convergence slide covers — then a recapture with the same script and a re-run of the check. This is a single-agent loop because the steps are sequential: the spec informs the build, the build produces the captures, the captures feed the check, the check decides whether to loop. There is nothing to parallelise for one screen; if you later need this across many screens, that becomes an orchestration problem outside this module's scope.

Each of these classes shows up consistently in traced runs, which is good news: predictable failures are checkable failures. Spacing drift is the most common — row heights, section gaps, and card padding become more comfortable than the reference, and the density that made the design work disappears. In one of the worked runs, card padding came back at 24px against a 32px spec, which compressed the price block and weakened the emphasised plan. Type drift is similar: an 18px body where the spec maps body to the 16px token quietly breaks vertical rhythm everywhere.

State gaps deserve their own emphasis because the reference physically cannot show them. A screenshot is one moment of one state. Hover, focus, loading, empty, error, disabled, and long-content behaviour all have to come from the spec's not visible in the reference section, or the agent will either omit them or invent them. Either way, that is a decision a human should have made.

Hierarchy and system drift are the subtler ones. The build can match colours while changing what reads first; it can look right while being made of local components instead of the design system's, which costs you later when the prototype graduates. Responsive drift — mobile preserving visual stacking but losing task priority — is covered properly on the responsive slide, but it belongs in this list because it is the one that most often survives review on a desktop monitor.

This is the slide that separates parity from cloning. The goal is parity of intent: the structure, density, hierarchy, and rhythm of the reference, expressed in the team's own materials. Colours map to semantic tokens, type sizes snap to the nearest step in the existing scale, spacing snaps to the existing rhythm. Where the reference cannot be expressed in the current system, the spec records the gap as a decision for a human rather than letting the agent invent a one-off value.

Walk the table rows as the three possible outcomes. Maps cleanly is the easy case and should be most of the rows. Snaps to scale involves a small, deliberate difference from the reference — and that difference will later appear in the parity report as an accepted difference, which is exactly right; it is visible and signed for, not hidden. Needs a decision is the valuable category: a grid width mismatch or a missing elevation token is a real system question that the screenshot has surfaced, and someone with authority over the system should answer it, not the agent mid-build.

The last row matters for module 2's clone-trap discussion: when the reference is competitor-inspired, the mapping step is the legal and taste firewall. The spec deliberately records only structure and density, and every colour and type value is mapped to the team's system before the build starts. Parity scoped that way is honest about what is being borrowed.

The failure mode this slide prevents is oscillation: the designer reports six problems at once, the agent fixes four, breaks two other things in the process, and the next report has six different problems. Each round looks busy and the build never settles. The fix is to constrain each round to one layer and hold the line on it: structure first, because every later measurement depends on regions being in the right place; then spacing rhythm and type, because they define the texture the colour work sits on; then colour, borders, shadows, and states last, because they are the cheapest to change and the most likely to be invalidated by earlier fixes.

The parity report supports this by carrying severities. P0 task-breaking and P1 hierarchy-or-rhythm items get fixed in their layer's pass; P2 polish waits its turn or gets accepted; P3 judgment calls go to a human rather than into the loop at all. Resist the temptation to let the agent fix a quick colour issue while it is doing the structure pass — that is how like-for-like comparison between rounds gets lost.

The last bullet is the diagnostic: most screens converge in two or three passes. A screen still failing after that usually has a spec problem — an ambiguous measurement, a region the spec never named, a token gap nobody decided — and the right move is to stop patching and fix the spec. That is also the signal that recurring fixes should be encoded upstream, in the spec template or the project's instruction file, so the next screen does not repeat them.

Read the prompt as a structure rather than as magic words. Observable mismatches only is what keeps the report out of adjective territory: the agent must point at a region and a value, not say the spacing feels tight. Measured or estimated values make the report checkable — a reviewer can open the two images and verify the claim. The severity scale is the triage that the convergence loop depends on: P0 means the task breaks, P1 means hierarchy or rhythm is wrong, P2 is polish, P3 is a judgment call that belongs with a human rather than in the loop.

The smallest patch per mismatch matters because it keeps fixes proportional. Without it, agents tend to propose rebuilding a section to fix a padding value. The accepted-differences list is the partner of the token-mapping slide: differences that exist because a value was deliberately snapped to the system are recorded, not hidden, and a human signs them.

The two closing instructions carry the governance. Do not patch anything yet separates comparison from correction, so the human sees the full picture before anything moves. The three-valued verdict — pass, pass with accepted differences, fail with blocking items — gives the gate a vocabulary. Without it, the agent's natural ending is an upbeat paragraph saying the build closely matches the design, which is exactly the assertion this module exists to replace.

The left column is what agents produce by default, and it reads like progress: positive, fluent, and unfalsifiable. None of those statements can be checked, none can be assigned to a patch pass, and none can be disagreed with on evidence. The right column is the same information forced through the prompt from the previous slide: a verdict with counts, then mismatches with a region, a measured value, the spec value, the consequence, and a severity.

Point out what specificity buys beyond accuracy. It makes the review conversation short — the team discusses three named items instead of trading screenshots and adjectives in a thread. It makes the fix assignable — a 24px-versus-32px padding mismatch goes straight into the spacing pass. And it makes disagreement productive: a designer can look at the P2 about body size and decide the 18px rendering is actually fine for this page, accept it, and record that acceptance, which is a design decision rather than an oversight.

If you want a single habit from this slide, it is to reject the weak form when it appears. The first time an agent answers a parity check with the build closely matches the design, send it back with the report structure. Agents follow the format they are held to; the quality of the gate is set by what you accept through it.

A module about matching a reference needs this counterweight, otherwise it teaches pixel worship. There are legitimate reasons to depart from the reference: it has a contrast failure the brand colours cannot fix, it was designed before the current token set existed, it never considered an empty state that real data makes common, or it is a competitor-inspired concept where matching the brand would be both a legal and a taste problem. The parity gate cannot make that call — it can only measure against whatever target it is given. Choosing the target is design judgment and stays human.

The mechanism for departing safely is the spec. An improvement is written into the spec as a decision — we are using our 4.5:1 contrast pair here even though the reference does not — and the gate then measures against the amended spec. The difference shows up in the accepted-differences list with a reason attached. That keeps the door open for an honest conversation with whoever approved the original design, because the departures are enumerable rather than discovered.

Contrast that with the failure mode: the build drifts away from the reference through a series of small unexamined choices, nobody records them, and the gap surfaces in a stakeholder review where the designer cannot say which differences were intentional. The cost is credibility, not just rework. Deliberate departure, recorded; accidental drift, prevented. That is the whole position.

This is the failure class most likely to survive review, because review usually happens on a desktop monitor at roughly the reference width. The reference is typically a single 1440px frame; everything below it — what stacks, what collapses behind a disclosure, what remains visible without scrolling, which panel comes first — is a decision the image cannot express. If the spec does not make those decisions, the agent will, and its default is to stack content in DOM order, which preserves the visual blocks while quietly losing the task priority.

Two concrete cases from the traced runs are worth telling. A dashboard build passed the check at the reference width and dropped a summary panel below the fold at 1280px; the gate caught it only because 1280px was in the capture script, and the patch reflowed the grid. And a conference-demo build had a headline that wrapped to three lines at the projector's 1280px width — caught the night before because the capture included that width, not because anyone thought to look.

The operational rule is mechanical: the capture script defines what parity means. Desktop at the reference width, a tablet width, and a mobile width on every round, with the spec carrying a short responsive section — even three lines of what stacks and in what order is enough to turn agent inventions into checkable claims. And keep the honest limit visible: a passing gate says nothing about widths and states that were never captured.

This run is drawn from the school's published parity workflow, and the numbers are from that traced run rather than a controlled benchmark — say so. The team had an approved 1440px pricing frame and a deadline, which is the typical context for this workflow: the design conversation was over, the implementation conversation had not started.

The round worth dwelling on is the first one. The spec extraction took the agent one pass, and the human review took about ten minutes — and that review caught the most expensive potential miss of the run: the middle plan's emphasis was achieved by a border plus a background shift, not just the badge. An agent building from an impression of the image would likely have shipped the badge alone, and the mismatch would have surfaced as a vague the middle card does not pop comment late in review. One spec comment versus a late aesthetic argument is the economics of the whole module.

The first gate run returning nine mismatches is normal, not a failure: the point of the gate is to find them while they are cheap. Note also what the failures were — body size off the token, padding compressed, a generic accordion instead of the system one — exactly the failure classes from earlier in the module. Two patch passes later the gate returned pass with accepted differences, the only accepted item being a shadow mapped to the nearest elevation token, signed by the designer. The deliverable at the end is a pair: the built screen and a parity report someone can sign. That pair is what makes the handoff in Module 6 honest.

The exercise deliberately starts from an existing implementation rather than a fresh build, because that removes the build time and isolates the skill being practised: extracting a spec, running the check, and reading the report. Most participants are surprised by what one round surfaces on a screen the team considered finished — typically two or three rhythm or type mismatches and at least one missing state.

Steer people towards a bounded screen with a real reference: a settings page, a pricing page, a dashboard panel. The minimal spec does not need to be exhaustive — regions, type scale, spacing rhythm, and colour roles are enough for one round — but push for measurements over adjectives, because the quality of the report tracks the precision of the spec. The mobile capture is non-negotiable even in the minimal version; it is where the most instructive findings usually are.

The sorting step is the actual learning objective. A raw list of mismatches is not the output; the output is the triage — real defects to fix, acceptable differences from deliberate token mapping, and gaps that exist because the spec never made a decision. That last category is the one to discuss if running this live, because it shows participants that most parity arguments are missing constraints rather than agent mistakes. Keep the report: Module 5 builds the QA matrix on top of exactly this kind of evidence.

Recap by connecting the bullets back to the loop diagram rather than repeating them flatly. The setup — reference, spec, capture, diff — exists because drift happens when the agent builds from an impression. The failure classes are predictable, which is what makes the parity check a checklist rather than an open-ended judgment. The token mapping keeps parity honest about whose system the screen belongs to, and the one-layer-per-round discipline is what makes the loop converge in two or three passes instead of oscillating indefinitely.

Restate the limits so the module does not overclaim. The gate proves the build matches the reference in observable ways at the captured widths. It cannot prove the design works for users, cannot validate hover, motion, or loading behaviour the reference never showed, cannot prove accessibility, and cannot decide whether parity was even the right goal. Those stay with the humans who own the spec and the sign-off.

Preview Module 5 concretely: this module checked one screen against one reference at the moment of building it. Visual QA loops generalise that into a matrix — routes, states, breakpoints, and themes — captured and compared against baselines so regressions are caught on every change, not just on the day the screen was built. The parity report from this module's exercise is the seed of that baseline.