UI View: Model-Projected Wireframing

Create conceptual wireframes that are fully connected to the architecture model. Every field on a UI View traces back through the intent graph, showing exactly where data comes from. Changes to the model propagate through to the wireframe via impact analysis.

March 19, 2026

UI Views solve this by treating the user interface as a projection of the model, the same way a Data View projects the model onto a database schema or an API projects it onto endpoints. Each field on a UI View is bound to a property path through the central model, and the full lineage is visible at a click.

This is not a high-fidelity UI design tool. It is an architecture communication tool that shows how data flows from the model to the screen, keeping wireframes aligned with the architecture rather than drifting as a separate, manually maintained artefact.

Core Capabilities

Grid Layout Editor

A 4-column grid where sections can be created, moved, and resized by dragging. Each section represents a region on the screen - a form, a detail panel, a list, or a dashboard widget.

Model Binding

Select an entity from the central model, then pick which properties appear on the screen. The binding path is stored and resolved at publish time, creating full data lineage.

Control Type Inference

Controls are automatically inferred from property shape: strings become text inputs, booleans become toggles, enums become dropdowns. 18 scalar and 6 list control types, all swappable.

Field Lineage

Click the lineage icon on any field to see its full path through the model graph. Entity hops, relationship traversals, terminal type, key role, and governance classification are all visible.

Impact Analysis

When a model property is renamed or deleted, impact analysis shows every UI View that references it. Migration cards are created automatically, and the architect can trace the exact binding path.

Multi-Page Flows

A single UI View can contain multiple pages with navigation buttons between them. Buttons link by UUID, so renaming a page does not break the flow.

API Annotations

Link sections to API operations via a dedicated API tab in the data picker. Two-step drill-down: select an API, then select an operation. Annotations create references edges in the intent graph, connecting screens to the endpoints that serve them.

Field Coverage Matrix

A cross-cutting report in Project Reports showing per-property coverage across Data View, Search, API, and UI View layers. Includes summary cards, layer bars, a filterable matrix table, and a gaps-only filter. Included in PDF export.

How It Works

The architect creates a .ui-view.json file and composes it using a grid-based editor. The workflow is:

Control Type System

Controls are abstract archetypes, not real UI components. They communicate the intent of each field without prescribing a specific implementation.

Data Shape	Default Control	Compatible Alternatives
String	Text input	Text area, label, password, rich text, search lookup
Integer / Decimal	Number input	Label, slider, rating
Boolean	Toggle	Checkbox, label
Date / DateTime	Date picker	Text input, label
Enum	Select	Radio group, button group, label
UUID	Text input	Label
Foreign Key	Select	Search lookup, label
Primary Key	Label	(read-only by default)
One-to-Many	Table	Card list, accordion, simple list, chips, timeline

Published Wireframes

When published, UI Views appear as interactive wireframes in the documentation site. The viewer provides:

Responsive Layout

The 4-column grid collapses to 2 columns on tablets and 1 column on mobile. Sections reflow automatically - no manual responsive configuration needed.

Smart Fake Data

Fields show contextually appropriate placeholder values. A field called 'Email' shows '[email protected]', 'Price' shows '149.99', and 'FirstName' shows 'Alex'.

Lineage Popovers

Click the lineage icon on any field to see its full binding path through the model. Entity names are clickable - they open the model explorer dialog for that entity.

Page Navigation

Buttons switch between pages within the viewer. Page tabs appear when a UI View has multiple screens, allowing the viewer to explore the full application flow.

Example: Order Detail (multi-page with payment flow)

This Order Detail screen demonstrates a multi-page flow with customer lookup, line items, and a payment processing page. Click the page tabs to navigate between Order Detail and Payment. Click any lineage icon to trace a field back through the model.

Example: Customer List (master-detail with orders)

A customer search and list screen with a side-by-side detail panel. The second page shows a customer's orders. Notice how the same Customer entity is used in both read-only list fields and editable detail fields, demonstrating different control types for the same data.

Full-Stack Lineage

UI Views complete the model-first lineage chain. A property change in the central model can now be traced through every layer of the architecture:

Layer	Projection	Edge Type
Model	Central entity/property definition	(source of truth)
Persistence	Data View with database profile	projects-to-db
Search	Data View with search profile	projects-to-search
API	REST/GraphQL/gRPC endpoint schemas	projects-to-api
User Interface	UI View with bound fields	projects-to-ui

Lookup Fields

Lookup fields represent reference data sourced from a different entity. For example, a Customer dropdown on an Order form pulls its options from the Customer entity.

Each lookup specifies three things: the source entity, the value property (usually the primary key), and one or more label properties (the text the user sees). The lineage popover shows all three, and clicking the entity name opens the model explorer.

Intent Graph Integration

UI Views are first-class citizens in the intent graph. Each UI View creates: