ViewSpec Rendering
Generative UI should produce a validated view specification executed by a deterministic renderer—not improvise pixels.
Place typed component vocabulary, data binding, accessibility rules, policy validation, and visual regression at the rendering boundary.
§ 01
The operating conditions that justify ViewSpec Rendering
Direct model-generated markup and behavior is difficult to constrain for accessibility, security, and brand consistency.
Storing only prompt output cannot reproduce which data and rules created a screen.
- Screens must adapt to work context within an allowed UI system
- Generated screens must be validated, audited, and replayed
- A few fixed screens fully meet the requirement
- No team owns component, data, and action schemas
ViewSpec Rendering: system plate
- 01
Stage 1
Define allowed components, properties, data shapes, and actions in a versioned schema.
- 02
Stage 2
Constrain model output to a parseable, policy-validatable ViewSpec rather than executable code.
- 03
Stage 3
A deterministic renderer applies authority, data binding, and accessibility defaults.
- 04
Stage 4
Validate schema, semantics, accessibility, and visual regression with fixed fixtures each release.
- The workflow begins with Define allowed components, properties, data shapes, and actions in a versioned schema..
- It reaches an acceptance decision through Schema and policy pass rate.
§ 03
Fix the boundary and acceptance criteria before implementation.
Generative UI should produce a validated view specification executed by a deterministic renderer—not improvise pixels.
- 01
Stage 1
Define allowed components, properties, data shapes, and actions in a versioned schema.
Review artifact 1 - 02
Stage 2
Constrain model output to a parseable, policy-validatable ViewSpec rather than executable code.
Review artifact 2 - 03
Stage 3
A deterministic renderer applies authority, data binding, and accessibility defaults.
Review artifact 3 - 04
Stage 4
Validate schema, semantics, accessibility, and visual regression with fixed fixtures each release.
Review artifact 4
§ 04
Hypothetical workloads make the applicability boundary concrete.
Screens must adapt to work context within an allowed UI system
Direct model-generated markup and behavior is difficult to constrain for accessibility, security, and brand consistency.
- APPROACH
- Define allowed components, properties, data shapes, and actions in a versioned schema.
- BOUNDARY
- Schema validity is not equated with usability or task correctness.
Generated screens must be validated, audited, and replayed
Storing only prompt output cannot reproduce which data and rules created a screen.
- APPROACH
- Constrain model output to a parseable, policy-validatable ViewSpec rather than executable code.
- BOUNDARY
- Unapproved code, URLs, and actions cannot escape the renderer boundary.
§ 05
Review gains and costs in the same table.
| Decision | Gain | Cost | Watch |
|---|---|---|---|
| Screens must adapt to work context within an allowed UI system | Define allowed components, properties, data shapes, and actions in a versioned schema. | Schema validity is not equated with usability or task correctness. | Schema and policy pass rate |
| Generated screens must be validated, audited, and replayed | Constrain model output to a parseable, policy-validatable ViewSpec rather than executable code. | Unapproved code, URLs, and actions cannot escape the renderer boundary. | Accessibility and visual regression |
ViewSpec Rendering: system plate
Is ViewSpec Rendering the next justified intervention?
- Screens must adapt to work context within an allowed UI systemProceed to design
Define allowed components, properties, data shapes, and actions in a versioned schema.
- A few fixed screens fully meet the requirementUse the alternative path
Schema validity is not equated with usability or task correctness.
- The workflow begins with Define allowed components, properties, data shapes, and actions in a versioned schema..
- It reaches an acceptance decision through Schema and policy pass rate.
§ 07
Agree on measurement conditions before publishing a result.
| Measure | Method | Pass condition | Caveat |
|---|---|---|---|
| Schema and policy pass rate | Define allowed components, properties, data shapes, and actions in a versioned schema. | Repeated runs satisfy the acceptance threshold agreed during discovery | Schema validity is not equated with usability or task correctness. |
| Accessibility and visual regression | Constrain model output to a parseable, policy-validatable ViewSpec rather than executable code. | Repeated runs satisfy the acceptance threshold agreed during discovery | — |
| Rendering reproducibility and failure isolation | A deterministic renderer applies authority, data binding, and accessibility defaults. | Repeated runs satisfy the acceptance threshold agreed during discovery | — |
§ 08
Conditions for not applying the capability are part of the design.
A few fixed screens fully meet the requirement
Schema validity is not equated with usability or task correctness.
No team owns component, data, and action schemas
Unapproved code, URLs, and actions cannot escape the renderer boundary.
§ 09
Proceed through diagnosis, design, and validation gates.
- 01
Diagnosis
PattyAnalyze the current system and its failure signals.
ClientProvide representative work, data boundaries, and operating constraints.
Schema and policy pass rate - 02
Design
PattyConstrain model output to a parseable, policy-validatable ViewSpec rather than executable code.
ClientConfirm owners and acceptance criteria.
Accessibility and visual regression - 03
Validation
PattyA deterministic renderer applies authority, data binding, and accessibility defaults.
ClientMake the production-transition or stop decision.
Rendering reproducibility and failure isolation
§ 10
Artifacts remain with the operating organization after the engagement.
- ViewSpec Rendering decision record
- Generative UI should produce a validated view specification executed by a deterministic renderer—not improvise pixels.Client-owned · Patty-reviewed
- Validation harness and acceptance criteria
- Schema and policy pass rate · Accessibility and visual regression · Rendering reproducibility and failure isolationJointly maintained
- Operations and recovery runbook
- Schema validity is not equated with usability or task correctness. · Unapproved code, URLs, and actions cannot escape the renderer boundary.Operating-team owned
§ 11
Use shared terms with explicit operating meaning.
- ViewSpec Rendering
- Place typed component vocabulary, data binding, accessibility rules, policy validation, and visual regression at the rendering boundary.
- Acceptance criterion
- Schema and policy pass rate
- Operating boundary
- Schema validity is not equated with usability or task correctness.
REFERENCES
References and primary material
- JSON Schema
Primary material for the method and terminology.
- WAI-ARIA Authoring Practices
Primary material for the method and terminology.
Begin by determining whether ViewSpec Rendering is the justified next step.
We define scope and validation against representative work, data and infrastructure boundaries, and explicit failure conditions.