Guided Generative Software Development with UJG

7.1.1. Repository-derived structure metrics

Component, Template, Slot, and SurfaceRealization come from the UJG. Implementation primitives are extra helpers a model invented for itself — its own choice, not something the UJG asked for.

Every run implements all 12 Components and all 9 Templates. They differ only in how they cut things up internally, adding between zero and four helpers of their own.

7.1.2. Structure diagnostics — GPT-5.5 Codex evaluator

7.1.3. Structure diagnostics — Claude Sonnet 5 evaluator

On the two explicit-gated runs the evaluators agree completely: full Storybook coverage of the evaluated interactions, and no missing stories, composition violations, or data-contract violations.

The implicit runs are where they part ways. On Claude implicit, the Codex evaluator sees 50% interaction-story coverage and the Claude evaluator 100%. On Codex implicit, the Claude evaluator finds one composition violation; the Codex evaluator finds one data-contract violation instead. Both readings are kept.

The structural picture is nevertheless one of strong convergence: all four builds realize the same 12 Components and 9 Templates, serving the same 54 SurfaceRealizations. They converge wherever the UJG models something — and the differing helper counts show it does not prescribe one source architecture.

7.2.1. Repository-derived token metrics

Token count describes a build; it does not grade it — a bigger catalogue is not a better one. The four runs differ widely in how many tokens they create and how they split foundation from semantic, yet all four produce two Themes. The modeled Theme boundary holds without dictating one token taxonomy.

Provenance coverage answers a simple question: for how many tokens can you tell where the value came from? It is computed from the repository counts, not supplied by an evaluator:

(direct tokens + inferred tokens) / total DTCG tokens

unclassified tokens = total DTCG tokens − direct tokens − inferred tokens

Coverage says how much of the catalogue is classified — not that every individual classification is right.

7.2.2. Token diagnostics — GPT-5.5 Codex evaluator

For the Codex evaluator, both explicit-gated builds are clean: no unresolved aliases, no raw-value leaks, no parallel token or Theme registries. Both implicit builds keep a weaker grip on the source of truth, and they fail differently — Claude keeps a parallel Theme registry and 116 raw-value leaks, Codex keeps both a parallel token catalogue and a parallel Theme registry plus 73 leaks.

7.2.3. Token diagnostics — Claude Sonnet 5 evaluator

The Claude evaluator also finds both explicit-gated builds clean, and also finds a serious source-of-truth problem in Codex implicit: 56 raw-value leaks and one parallel token catalogue.

The two disagree sharply on Claude implicit. Codex reports 116 leaks and a parallel Theme registry; Claude reports neither and gives full marks. Both readings stand as they are.

On Codex implicit they agree on the direction and differ on the size: both see a parallel token catalogue and much weaker discipline, but count 56 versus 73 leaks and disagree on whether a second, Theme-level registry exists too.

Agreement is far stronger on the explicit-gated runs, where both evaluators independently report nothing wrong at all. So the token results separate two things: building a token system, which all four runs manage, and keeping it authoritative, which only the explicit-gated runs clearly achieve.

7.3.1. Repository-derived styling scope

All four builds carry the Component and Template inventories through styling unchanged. Styling changes appearance without adding or removing modeled artifacts.

7.3.2. Styling diagnostics — GPT-5.5 Codex evaluator

For the Codex evaluator, both explicit-gated builds stick closely to the tokens and leak no raw values. Claude explicit has no duplicated or misplaced styling either; Codex explicit picks up one minor duplication.

The implicit builds fare worse: 116 raw-value leaks, six duplicated style patterns, and two misplaced rules for Claude; 73 leaks, two duplications, and two misplaced rules for Codex. In both cases the evaluator ties these findings to weaker use of the generated tokens and Themes.

7.3.3. Styling diagnostics — Claude Sonnet 5 evaluator

The Claude evaluator also finds Claude explicit fully token-aligned — no leaks, no duplication, no misplaced rules — but reads several other runs differently.

On Claude implicit it reports zero leaks and full adherence where Codex reports 116 leaks and 3.0 / 5. The split comes down to Tailwind: whether a default utility scale counts as a visual value living outside the generated token system.

On Codex explicit it reports eight leaks and one misplaced rule, mostly at the application-shell boundary, where Codex reports none. Both still call adherence relatively strong.

On Codex implicit both see clearly weaker adherence and heavy raw-value duplication, counting 56 and 73 leaks respectively.

Responsive numbers vary just as much. On Claude explicit, the Claude evaluator counts eight responsive artifacts with 88% documented; the Codex evaluator counts nine with 38%. These are evaluator readings, not repository counts, and are kept apart.

What the evaluators agree on most is structural preservation: no run changes the Component or Template inventory during styling. They also broadly agree that the explicit-gated builds hold to the token system better than Codex implicit does. Finer claims — how many raw values leaked, how much styling was duplicated, how well responsive behavior is documented — should be read per evaluator, because the two interpret those properties quite differently.

7.3.4. Same modeled template, different implementation models

Claude Sonnet 5 · explicit-gated	GPT-5.5 Codex · explicit-gated

The same UJG ReviewWithActions Template, built by two models under the same explicit-gated protocol. Each is free to style it its own way while keeping the established Template and Component inventory.

7.4.1. Application diagnostics — GPT-5.5 Codex evaluator

For the Codex evaluator, all four runs deliver both interfaces the manifest asked for, and both explicit-gated builds score substantially higher on behavioral fidelity than their implicit counterparts.

Claude explicit is held to the widest set of branches — 30 of 35 verified — and its only real source-of-truth finding is one parallel semantic projection in the browser service layer. Codex explicit is judged against a smaller branch set, verifies 11 of 13, and draws no integration, projection, or invariant findings at all.

Both implicit builds converge less well: Claude implicit picks up two parallel semantic projections and one effect/invariant violation; Codex implicit picks up two design-system integration violations and two parallel projections.

7.4.2. Application diagnostics — Claude Sonnet 5 evaluator

The Claude evaluator reads several runs quite differently. It gives both Claude builds full behavioral fidelity even though the implicit one has far lower verification coverage — the two are separate dimensions: one asks whether the software behaves as modeled, the other whether tests prove it.

On Codex explicit it finds one parallel semantic projection and one effect/invariant violation: the modeled rule that an offered place belongs to its intended participant is not enforced where the state actually changes. Both interfaces exist, but fidelity drops.

The biggest disagreement in the study is on Codex implicit. Codex counts both interfaces realized and scores 3.4 / 5; Claude counts only one and scores 1.0 / 5. Claude's reasoning: the browser application goes around the HTTP domain boundary the manifest selected, duplicates journey behavior in its own in-memory client, and never uses the selected email realization.

Verification coverage is evaluator-specific for the same reason. The two do not always identify the same set of branches — Claude explicit is measured against 35 branches by Codex and 22 by Claude — so each percentage is relative to that evaluator's own set, not one canonical number.

Taken together, the application phase converges less than the structural phase. Every run is handed the same scope, but the evaluators differ on how completely some builds deliver it and keep UJG behavior intact across runtime boundaries. The builds themselves differ in verification depth, semantic projections, persistence and domain design, and interface integration. The narrower conclusion holds: the UJG and manifest constrain the journey and the boundaries, not the architecture — and meeting those boundaries stays an implementation problem.

7.4.3. Example persistence realization

How data gets stored is also left to the implementation.

erDiagram

    PARTICIPANTS ||--o{ REGISTRATIONS : registers

    WORKSHOPS ||--o{ REGISTRATIONS : receives

    PARTICIPANTS ||--o{ WAITLIST : joins

    WORKSHOPS ||--o{ WAITLIST : contains

    PARTICIPANTS ||--o{ OFFERS : receives

    WORKSHOPS ||--o{ OFFERS : provides

    PARTICIPANTS {

        TEXT id PK

        TEXT name

        TEXT email

    }

    WORKSHOPS {

        TEXT slug PK

        TEXT title

        TEXT summary

        TEXT description

        TEXT event_date

        TEXT location

        INTEGER capacity

        INTEGER registration_open

        INTEGER waitlist_open

    }

    REGISTRATIONS {

        TEXT workshop_slug PK, FK

        TEXT participant_id PK, FK

        TEXT name

        TEXT email

        TEXT accessibility_notes

        TEXT created_at

    }

    WAITLIST {

        TEXT workshop_slug PK, FK

        TEXT participant_id PK, FK

        TEXT name

        TEXT email

        TEXT notes

        TEXT created_at

    }

    OFFERS {

        TEXT id PK

        TEXT workshop_slug FK

        TEXT participant_id FK

        TEXT status

        TEXT expires_at

        TEXT created_at

    }

This is the SQLite schema generated by the explicit GPT-5.5 Codex run — not the UJG domain model. SQLite and this table layout are choices the model made inside the fixed technology profile.

8.3.1. Same implementation model, different guidance protocol

GPT-5.5 Codex · implicit-gated	GPT-5.5 Codex · explicit-gated

Both screenshots show the same workshop-overview application from the same model, built under different guidance. The explicit-gated version follows the staged Structure → Tokens → Styling → Application process closely; the implicit-gated one wanders into a broader, less constrained application shell.

So the main benefit is not that more gets built. It is continuity between phases:

• the generated tokens stay the single source of styling values;

• styling leaves the structure from the previous phase intact;

• the application adds fewer competing copies of journey meaning;

• more of the evaluated behavior is actually backed by tests.

This holds for both models, and is much larger for GPT-5.5 Codex.