A runtime artifact
A screen is usually treated as a product object.
It has a name such as Accounts, Transactions, or Monthly report. It appears in a design file, becomes a route in the application, receives a component tree, and enters a test plan. When the product is deployed, the screen waits for users to visit it.
Its data will change at runtime. Its loading, empty, error, and permission states may change too. Its reason for existing was decided earlier.
An intent-first application introduces another possibility. The screen may not exist when the software is shipped. It may be formed only after the system knows the present task:
intent + context + data + capabilities + constraints
↓
interaction model
↓
interface
The resulting interface is a runtime artifact: a concrete interaction created during the use of the system rather than a permanent screen selected from it.
More than runtime rendering #
Browsers already construct interfaces at runtime. A server may generate HTML for a request. A React application may calculate a new component tree after every state change. Conditional rendering may add, remove, or rearrange controls. Calling those interfaces runtime artifacts would make the phrase too broad to be useful. But what would make it useful is the question: when was this interaction decided?
A conventional accounts component might contain rules such as:
if there are several currencies, show the currency column
if an account is frozen, show a warning
if the user can transfer money, show the transfer action
The browser selects among authored variations. The designers and developers have already decided that the interaction is an accounts table, which concepts deserve columns, and which actions belong beside each row.
A runtime-composed interface makes a decision at a different level:
The user is assessing whether a holiday is affordable.
An accounts table alone does not support that decision.
Combine a cash-flow forecast, known obligations,
adjustable assumptions, and a savings-plan action.
The distinction is between generating the state of a known screen and determining which screen—or combination of representations—should exist at all.
Dynamic rendering changes an authored interface. Runtime composition determines the interaction to render.
From source object to produced object #
In the predefined model, a screen is part of the application's source structure:
route
↓
component tree
↓
data bindings
↓
rendered screen
The route gives the screen a durable identity. Documentation can point to it, analytics can name it, and support staff can ask a customer to open it. In the runtime model, the durable objects sit below the screen:
task model
↓
available information and actions
↓
interface description
↓
rendered surface
The system still has stable parts. It knows how to retrieve financial obligations, calculate a forecast, prepare a transfer, display a warning, render a timeline, and request confirmation. What is not necessarily stable is their arrangement into a page.
The page becomes closer to a query result. It is a projection created for a question, from current state, under current rules. Another question over the same system can produce a different projection. The durable product objects are the domain capabilities and valid interaction elements, not every arrangement in which they may appear.
A representation between intent and pixels #
The simplest implementation would ask a model to write HTML, CSS, and JavaScript for each task. That would make the output dynamic, but it would also make every generated surface responsible for security, accessibility, behavior, visual consistency, and correct action handling.
A more useful boundary places a semantic description between interpretation and rendering:
intent
↓
task and data planning
↓
semantic interface description
↓
validation
↓
web or native renderer
For the holiday example, the description might resemble:
{
"type": "decision_workspace",
"purpose": "assess_holiday_affordability",
"sections": [
{
"type": "affordability_summary",
"data": "holiday_scenario.summary"
},
{
"type": "cashflow_timeline",
"data": "holiday_scenario.cashflow",
"range": "45_days"
},
{
"type": "assumption_editor",
"data": "holiday_scenario.assumptions"
}
],
"actions": [
{
"type": "prepare_savings_plan",
"requiresConfirmation": true
}
]
}
This description states what the interaction means. The exact markup, focus behavior, type scale, or appearance of a confirmation control are outside of its decisions.
The renderer maps those meanings onto approved components. On the web it produces HTML, CSS, DOM behavior, and an accessibility tree. A native renderer could produce another surface from the same description. A compact device might use fewer visible regions while preserving the task and its actions.
This separation creates two different kinds of dynamism:
| Composition | Rendering |
|---|---|
| Chooses what belongs in the interaction | Determines how approved elements behave and appear |
| Responds to intent and context | Responds to platform and design-system rules |
| May be probabilistic | Should be substantially deterministic |
| Produces a semantic structure | Produces the final user interface |
The compositional layer can be flexible without requiring the final interface to be arbitrary.
A negotiated artifact #
Runtime composition has its limits. The resulting interface is negotiated among several inputs:
user intent
+
available data and capabilities
+
permissions, policy, and risk
+
device and accessibility requirements
+
product interaction language
↓
valid interface description
Intent determines what the interaction is trying to accomplish. Capabilities determine what the product can truthfully retrieve, calculate, or do. Policy and permissions limit which information and actions may be offered. The device affects how much can be shown at once. The product's interaction language supplies approved meanings, components, and behavior.
Some properties may adapt freely: the choice between a table and a timeline, the grouping of supporting information, or the amount of explanation shown. Other properties should be invariant: the meaning of an action, the source of a value, required warnings and confirmations, keyboard and assistive-technology behavior, and the visual identity of the product.
The runtime negotiates how the relevant facts and authorized controls should be assembled for the present task. Validation is the boundary that turns a plausible composition into one the product is willing to render.
Shapable parts #
With the absence of the final screens, the application still ships something. It ships the means from which valid screens can be produced.
That may include:
- domain capabilities that retrieve information, calculate results, and prepare actions;
- semantic components such as forecasts, comparisons, timelines, warnings, and confirmation panels;
- rules describing which components accept which data and how they may be combined;
- visual, behavioral, and accessibility conventions;
- permissions, policies, and required control points;
- deterministic renderers for each supported platform;
- stable interfaces for fallback, recovery, and repeated work.
The runtime adds the situational structure. It determines that a forecast and an assumption editor belong together for this task, binds them to current data, and offers only actions that the user can take.
The production artifact therefore moves up a level:
predefined model:
product team ships screens
runtime model:
product team ships an interaction language
system uses that language to produce screens
The distinction resembles other software layers. A database provides a language for forming queries rather than storing every possible result. A browser provides layout and interaction systems rather than containing every document it will display. A runtime interface system provides the vocabulary and rules from which a particular surface can be assembled.
The analogy has limits. Interfaces influence judgment and can initiate consequential actions. Their production cannot be treated as neutral formatting. The generated structure must remain inspectable, constrained, and connected to authoritative data and capabilities.
Product lifecycle #
A predefined screen usually has a product lifecycle: design, implementation, release, revision, and eventual removal.
A runtime interface also has a user-facing lifecycle:
form → refine → use → save, share, or discard
The first surface may be incomplete because the intent is incomplete. As the user changes an assumption or selects an item, the system can extend or recompose the relevant part of the interface. A comparison may gain a chart. An explanation may become a dispute workflow. A hypothetical payment may become a review and confirmation form.
Replacing the entire interface after every action is unnecessary. A useful runtime maintains continuity. Stable regions remain in place; selected values persist; changes are visible; and the user's work is not lost when the system's understanding improves.
Nor does runtime artifact mean temporary. Origin and duration are separate properties.
A surface created for a one-off question may disappear when the question is answered. A weekly payroll workspace may be saved and reopened. A carefully constructed investigation may be shared with a colleague. A generated view that repeatedly proves useful may become a template or a permanent product feature.
The model allows interfaces to move along a continuum:
ephemeral answer → active workspace → saved view → shared pattern
Routes can still exist. They may identify saved artifacts and ongoing tasks rather than only screens conceived during product development.
The screen after the situation #
Treating the interface as a runtime artifact changes the order of authorship. The product team authors capabilities, meanings, constraints, and a rendering language. The runtime authors an arrangement within that language. The user authors the goal and refines the result through interaction.
HTML remains essential on the web. Buttons remain buttons. Tables, charts, forms, and dialogs do not become obsolete. Their role changes from parts of a single predefined page to elements selected for a particular situation.
The shift can be summarized as:
document web: HTML is the delivered document
application web: JavaScript renders an authored application
intent-driven web: a runtime composes the interaction, then renders it
The interface is the visible result of interpreting one intention in the current state of the world.
Making that result valid is not enough to make it usable. People must still be able to orient themselves, discover what is possible, understand what changed, and recover when the composition is wrong. The more fluid the surface becomes, the more carefully the system must preserve trust, control, and familiar ground.