Semantic Grammar

Most design starts by drawing screens. But when interfaces generate themselves at runtime, there are no screens to draw. This essay proposes starting one layer down: define what your system means, its actors, objects, states, and the conflicts between them, then let the interface be derived from that meaning rather than hand-drawn. A grammar for the layer underneath the layout.

Two faster ways in, if the full essay feels like a lot up front.

The same idea in plain language, told through an everyday context you pick: planning a trip with friends, your media diet, or staying on top of your health. It skips the design jargon.

A skill that runs the framework as an interview. It walks an AI agent through the five sections against a real product of yours and hands back a semantic grammar document. You find out fast where your uncertainty is.

Interfaces are getting smarter, but design practice still starts with screens. A designer draws layouts, connects them into flows, and hands off specifications. This worked when every surface was authored by hand. It breaks when interfaces adapt at runtime, generate elements on the fly, or serve actors whose needs are structurally in tension. A hospital tracking board that renders a critical lab result in the same muted row it uses for a routine medication refill has the right data and the wrong response, because no one designed what should happen when a result is urgent, so it looks like every other result.

This essay proposes a different starting point. Instead of designing screens and extracting patterns from them, begin with what a system means: the objects that persist, the states that matter, the conflicts between the actors involved. Call this the semantic layer. Above it, a signal layer encodes what shapes that meaning for its audience, drawing on brand, regulation, user context, and editorial judgment. Expression is then derived from the interaction of meaning and signal rather than authored directly. Three layers, then: what the system means, how that meaning should come across, and what you finally show. Each one derives from the layer below it.

The framework raises more questions than it settles. Can derivation produce interfaces that feel designed, not just functional? What vocabulary describes register without collapsing into visual properties? Where does the designer's authority sit when form is no longer fully specified? These are open problems. The goal here is not to close them but to make them precise enough to work on.

Most interaction design still begins with screens. A designer opens a canvas, draws rectangles, fills them with content, and connects them into flows. Components get extracted, systematized, documented. The output is a specification: this screen, this layout, these states, this behavior.

This worked when designers controlled the adaptation. Responsive design and multi-platform systems already broke the one-screen assumption years ago, but the response was to multiply specifications: breakpoints, platform-specific layouts, device-targeted components. The designer still authored every variant. What is changing now is that adaptation itself is moving beyond what a designer can specify in advance. Interfaces adapt to user histories, situational contexts, and content states in combinations no designer anticipated. Generative UI produces interface elements at runtime. Adaptive systems reorder, summarize, and prioritize content without a designer touching a layout.¹

The response so far has been to systematize the surface: design tokens, component libraries, multi-platform design systems. These help, but they solve the problem at the wrong layer. They make the visual expression consistent and portable. They don't address what the interface means.

What holds across every adaptation, every surface, every context is not a component or a layout. It's the meaning underneath: what the system is about, who it serves, and where their interests collide. That layer needs its own grammar.

The semantic layer describes what a system is about: the meaningful entities, relationships, and tensions that persist regardless of how or where the system is rendered. Not the look, not the behavior, the substance underneath both.

This is the layer most design practice skips. A team jumps from a problem statement to wireframes, treating the space between as "discovery" or "synthesis" rather than as a designable structure in its own right. The semantic layer makes that structure explicit.

It consists of five elements:

Actors

These are agents, not users: they have distinct motivations, stakes, and structural relationships to each other.

In an emergency department, several people act on the same patient at once: the patient wants relief and answers, the triage nurse has to rank how urgent this case is so the waiting room stays safe, the senior doctor has to rule out the worst before moving on, the charge nurse needs a bed freed for the ambulance already on its way, and the hospital's back office needs the visit documented well enough to account for it. These are agents whose goals are structurally in tension, not personas with different demographics. The design problem lives in that tension, not in any individual actor's journey.

Objects

Things with persistence and meaning beyond a single interaction.

A patient's emergency visit exists before they are seen (just a name and a reason for coming, waiting to be called), while they are being worked up (vitals taken, blood drawn, scans ordered), as one shift hands the case to the next (same patient, new team), and after they leave (sent home, admitted upstairs, or moved elsewhere, but still a medical and legal record). It is the same visit the whole way through. What it means changes at every stage, but it never stops mattering. Objects like this are the stable anchors of the semantic layer. If a system loses track of them, no amount of UI polish compensates.²

States

What an object can be, and what those states mean to each actor involved.

A blood test can be ordered, drawn, back from the lab, flagged critical, or cancelled. A result flagged "critical" means something different to the patient (something is seriously wrong with me), the nurse at the bedside (I have to act on this now and find the doctor), and the senior doctor (does this change the diagnosis, and who else needs to know?). The state is one fact. Its meaning fans out across actors. Designing for the state without designing for that divergence produces interfaces that are technically correct and semantically useless.

Events

What changes state, why it matters, and who triggers it.

A badly injured patient arrives by ambulance. For the patient, it is the worst moment of their life: pain, fear, no control. For the nurse at the bedside, it is a sequence to execute under pressure: lines, monitors, medications, all in the next few minutes. For the charge nurse running the floor, it is a resource problem: who treats this patient, which waiting patient now waits longer, is there a free bed if a second one rolls in. One event, three divergent meanings, each demanding a different response within minutes. Events are where the system moves. They are also where misalignment between actors becomes visible.

Conflicts

Where actor interests collide. This is the element most often missing from design work, and the one that matters most.

A crowded emergency department sits on a three-way conflict over a single decision: discharge or admit. The senior doctor wants to be cautious, keep the patient for observation, and not miss the diagnosis that comes back to haunt them. The charge nurse needs the bed, because there are nine people in the waiting room and an ambulance inbound. The patient wants to go home, or is too sick to want anything at all. The design problem is not "how should the send-home-or-admit button look." It is: whose pressure gets expressed in the moment of the decision, and how do you keep a rushed discharge from looking exactly like a safe one? Every meaningful design decision in that system traces back to this conflict. The visual form is downstream.

Conflicts are what make the semantic layer more than a data model. A database schema can capture objects, states, and events. It cannot capture the fact that two actors need incompatible things from the same object at the same time. That is a design problem, and it requires design judgment.

Meaning is contextual

One more property of this layer: the same object, state, or conflict can carry different meaning for different actors, or in different situations. This is not a problem to resolve. It is a condition to design with. The semantic layer does not flatten these differences. It makes them visible so the signal and expression layers can respond to them.

If the semantic layer describes what a system is about, the signal layer describes what shapes how that meaning reaches its audience. A red notification badge in a Western app means "attention needed." In Chinese financial apps, red signals prosperity. Same visual element, opposite meaning, and the difference is a signal the designer either reads or ignores. These are not signals as in data inputs: sensor readings, system events, user actions. Those are events in the semantic layer. Signals here are closer to the concept in foresight research: observable forces that shape what is emerging, like a cultural shift, a regulatory climate, or a brand's accumulated voice. These forces exist whether or not anyone is designing with them. You cannot author them from scratch, but you can read them, and then amplify, dampen, or override them. The designer's job in this layer is distinguishing signal from noise and orchestrating how the signals that matter shape what gets expressed.

Signals come from multiple sources: the semantic layer itself (a patient whose blood pressure has dropped twice in ten minutes generates urgency no designer needs to inject), brand and organizational identity, domain and regulation, cultural context, user behavior and preferences, and the designer's own editorial judgment. These sources feed the layer, but they are not its structure. The structure is what signals act on: five dimensions along which every signal, regardless of origin, shapes expression.

Gravity

What is at stake. Confirming the dose of a drug that could stop a heart if it is wrong is not the same as confirming a fix to a misspelled name. High gravity narrows the range of acceptable expression toward the unambiguous, the legible, the predictable. Low gravity opens the range, leaving room for visual richness, surprise, and play. Gravity is often inherent to the semantic layer: a conflict involving health, money, or legal standing generates it. But it can also be imposed. A hospital may require two nurses to check a risky drug at the bedside and both sign for it, a seriousness the task does not have on its own, but that the rules impose.

Tempo

How much time pressure exists. An emergency notification compresses everything: fewer elements, higher contrast, immediate action. An onboarding flow expands: more explanation, lower commitment per step, room to explore. Tempo runs deeper than clock time. A nurse glancing at a stable patient's vitals during a quiet round, and the same nurse looking at the same vitals panel as the numbers start sliding, have different tempos on the same screen, on the same patient, seconds apart.

Intimacy

How personal the content is. A patient's HIV status, a psychiatric history, a positive pregnancy test on a minor: these demand a different expression than a heart rate or a room number. Intimacy affects what can be shown on a shared screen, what should be spoken aloud, what belongs behind an extra tap. A tracking board that prints the visit reason in plain view at the nurses' station treats it as routine. One that shows "see chart" and keeps the sensitive reason a tap away treats it as intimate. Same data, different judgment about exposure, and in a corridor full of strangers that judgment is also a matter of dignity and law. That judgment is culturally situated: what feels private, what feels routine, what demands discretion varies across contexts and audiences.

Authority

Who is speaking and with what standing. A warning meant for the doctor can be blunt and specific: this patient's kidneys are weak, so lower the dose. It speaks to a colleague who already knows what that means, as a peer, not a gatekeeper. The same fact shown to the patient on their bedside screen has to speak differently: plainer, calmer, without the numbers that mean nothing to someone who was not trained to read them. Authority is also shaped by the relationship between system and user. A first interaction carries different authority than a five-year relationship. And authority can be imposed from outside: when a legal requirement speaks through the interface, it overrides the brand's own voice.

Reversibility

How easily an action can be undone. Once a drug is in the patient, there is no taking it back. Ordering a test you change your mind about is nothing: you cancel it before anyone draws the blood. Reversibility calibrates friction: irreversible actions demand confirmation, deliberation, sometimes intentional slowness. Reversible actions invite directness, speed, low ceremony. A system that gives the nurse a few seconds to cancel after they confirm a dose, before it is truly given, can stay fast and light. Take that window away and every single confirmation has to feel as heavy as the one that cannot be undone.

Mixed signals

These five dimensions make signal conflicts precise. A patient has asked that their alcohol-use history not be displayed where visitors might see it, but the medication about to be ordered interacts dangerously with alcohol and the doctor ordering it needs that context now. This is not a vague disagreement. It is a conflict between intimacy (the history is sensitive, the patient has asked for distance) and gravity (a dangerous interaction raises the stakes of hiding it). The designer's role here is to make the trade-off explicit and defensible rather than silently pick one signal: surface the interaction warning to the doctor without printing the history on a screen the room can read.

When sources produce contradictory pressures on the same dimension, the result is mixed signals. When nobody resolves them, the system oscillates: playful in contexts that demand seriousness, rigid in contexts that invite exploration. This looks like inconsistency, but the root cause is a missing editorial decision. The designer's role in the signal layer is closer to orchestrator than to traditional author. The agency does not shrink, it shifts. The designer still makes consequential choices: which signals take priority, what tensions are acceptable, where the system should resist adaptation and hold firm. That is a stance, not a neutral coordination task.

Register

The combined effect of signals along these dimensions produces register: the appropriate expression for this meaning in this moment. Register is not a single axis. It is the composite of gravity, tempo, intimacy, authority, and reversibility as they converge in a specific context. The tone of a clinical system shifts between noting a calm patient's hourly readings (low gravity, low tempo, routine) and confirming an emergency drug as a patient stops breathing (high gravity, high tempo, low reversibility). Both are the same product, the same brand, the same user. The difference is register.

Register is what gives a system range without losing coherence. A product that sounds the same in every context is rigid. A product that sounds different in every context is incoherent. The signal layer defines the range of acceptable registers and the conditions that move between them.

The expression layer is derived from the semantic layer by orchestrating the signal layer.

This is the claim that separates Semantic Grammar from conventional design practice. It is also where the framework faces its hardest test: showing that derivation can produce coherent, appropriate interfaces, not just technically functional ones.

How derivation works

Take a critical lab result landing while the doctor who ordered it is mid-procedure with another patient. The semantic layer says: a patient's blood result is dangerously abnormal, time-bound, tied to a specific doctor, life-threatening if missed. The signal layer says: high gravity, high authority, low reversibility (an untreated value can stop the heart), tempo compressed by the fact that the doctor is gloved and cannot tap a screen.

A well-derived form: a high-contrast alert that names the patient, the value, and the one action that matters, escalated to the nurse beside the doctor and read aloud rather than left to be tapped. No decorative elements, no soft "FYI" framing, no burying it in the same feed as routine results. Every element traces back to a signal.

A badly derived form: a small grey pop-up in a calm color, the number shortened, sitting in line behind four normal results. The signals were all there. The derivation ignored the register. The result is technically correct (right data, right time) and semantically wrong (wrong tone, wrong priorities, wrong assumptions about the moment).

Derivation heuristics

Not every derivation decision needs to be made from scratch. Certain patterns hold across contexts:

High gravity, less adaptation. When the consequences of misunderstanding are severe, the system should reduce ambiguity, increase legibility, and resist adaptation. The confirmation for a dangerous drug should look the same every time, on every screen, no matter how busy the shift. Predictability is the point.

Exploratory contexts, more surface area. When the user is browsing, discovering, or comparing, the interface can show more, assume less, and lower the commitment required per action. A doctor paging through a stable patient's history to work out what might be wrong can afford a richer, denser, more open-ended view than the screen used to confirm a blood transfusion.

Repeat use, progressive compression. As a user returns to the same object or flow, the interface can compress: show less context, assume more familiarity. A nurse charting their first admission of a shift needs full prompts. By the tenth, the same flow can collapse to the few fields that change.

First encounter, full semantic disclosure. Before asking for action, show what this is. A doctor opening an unfamiliar set of pre-filled orders for the first time needs to understand what it will do before they can safely sign off on it. Name the thing. Show its state. Make the actors visible.

Conflicting signals, make the trade-off visible. When signals from different sources pull in opposite directions, the worst response is to silently pick one. Surface the tension. If the system blocks a drug the doctor ordered, it should say so plainly, not quietly drop it as if the order were never placed.

When derivation fails

The framework should be honest about its failure modes.

Under-specified semantic layer. If the team skipped the semantic work, derivation has nothing to derive from. The result is generic UI that looks functional but carries no meaning. Intake forms that take a full history but never say who will read it or whether it changes anything. Dashboards full of numbers no one on the floor acts on. The system works, technically. It means nothing.

Unresolved signal conflicts. When nobody decides which signals take priority, the system oscillates. It is playful in contexts that demand seriousness, or rigid in contexts that invite exploration. This looks like inconsistency, but the root cause is a missing editorial decision in the signal layer.

Over-derived expression. Adaptation without constraint. The system tries to be so responsive to context that it loses identity. Every surface looks different, every interaction feels unfamiliar. Users cannot build a mental model because the interface never holds still long enough to become recognizable. In a setting where staff rotate between rooms and workstations all shift, an interface that rearranges itself for every context is not adaptive, it is dangerous. This is the failure mode of context-sensitivity without a stable semantic core.

These questions test whether a team has done the semantic work. They are useful in product conversations, design critiques, and stakeholder alignment. A surface-level answer reveals a surface-level understanding of the system.

1. Describe your product without naming a single UI element.

Surface answer: "We help emergency departments manage their patients." Semantic answer: "We track how sick each patient is, show where too many patients are competing for too few staff and beds, and flag the moments when someone needs a decision before they get worse." The first answer could describe a spreadsheet. The second describes a system with objects, states, events, and conflicts.

2. What are the objects in this system that have a life beyond one interaction?

This question separates meaningful objects from UI artifacts. A "row" on the tracking board is not an object. The patient's visit it represents is. A standalone drug-dose calculator, by contrast, has no such object at all: enter the weight, read the dose, close it, and nothing is kept. If nothing persists beyond the session, the system is a tool that runs and forgets. That is fine, but it changes what needs to be designed.

3. What states can those objects be in, and what do those states mean to each actor?

If every actor experiences the same state the same way, either the system is simple or the team hasn't looked closely enough. A patient in "awaiting results" means worry (to the patient), a held bed (to the charge nurse), and a decision they can't make yet (to the senior doctor). The state is one phrase. The meaning is three different concerns.

4. Where do your actors' interests conflict?

Surface answer: "Doctors want to be thorough, management wants patients moved through faster." Semantic answer: "The senior doctor wants to keep the patient another hour to be safe. The charge nurse needs that bed for the ambulance pulling in. The patient just wants to go home." If a team says its actors don't really conflict, it hasn't looked past a quiet shift yet.

5. If the interface was rebuilt from scratch tomorrow, what would have to stay the same for it to still be the same product?

This question isolates the semantic core. Not the brand, not the layout, not the component library. The things that, if removed, would make the product a different product. Those things belong in the semantic layer. Everything else is derived.

Semantic Grammar is not a method you adopt on Monday. It is a lens: a way of looking at product and system work that makes certain problems visible that screen-first practice obscures. The claim is that meaning, not form, is the stable layer. That signals from multiple sources compete for expression, and that managing that competition is the designer's core work. That form follows from both, not from a canvas.

If you work on a system where multiple actors need different things from the same object, the semantic layer gives you a way to map that tension before anyone opens a design tool or writes a line of code. If you work on a system that adapts across contexts, the signal layer gives you a way to define what holds and what flexes without specifying every variant by hand. If you build design systems, the framework suggests that tokens and components solve the problem one layer too late.

None of this is proven. The diagnostic questions are testable. The derivation heuristics are falsifiable. What this text offers is not answers but structured questions: specific enough to guide work, open enough to survive contact with real systems. The useful response is a better version of the argument, tested against a domain this essay did not cover.

To build on:

Semantic layer. Objects, states, and conflicts persist across every surface. They are more stable than any interface built around them. Start there.

Signal layer. Meaning does not shape itself. Signals from brand, regulation, culture, users, and editorial judgment compete for influence along five dimensions: gravity, tempo, intimacy, authority, reversibility. The designer orchestrates that competition.

Expression layer. Expression is what results when meaning meets signal in a specific context. Gravity narrows the range. Exploration widens it. Repetition compresses it.

Diagnostic questions. Can you describe the product without naming a screen? Can you say where your actors' interests collide? If not, the layer underneath is missing.

Designer's role. Less direct authorship, but no less authority. The shift is from specifying the form to shaping the conditions that produce it.

There is a guided interview skill for AI agents. It runs the five sections as a conversation and produces a semantic grammar context document at the end. Install it, open your agent, and see where the vague answers are.

npx semantic-grammar

Requires Node.js. Run this in your terminal. No install needed.

studiostoll/semantic-grammar

Read the source or open an issue.