Architect the System
The interface is not the system.
An interface is one expression of a system. It exposes selected objects, states, choices, and consequences to a person at a particular moment. The system also includes everything the screen cannot show at once: policies, dependencies, permissions, memory, services, and other people.
When teams treat the interface as the whole product, local design decisions accumulate without a shared architecture. Each screen may appear sensible on its own while the overall operation remains fragmented and brittle.
A coherent interface is the visible consequence of a coherent operating model.
Architect work, decision, and intelligence together.
These are not separate workstreams. Each changes the meaning and safety of the others.
Work architecture describes how value moves from request to completion. Decision architecture describes who decides, which evidence supports the decision, and where judgment or escalation belongs. Intelligence architecture defines where AI may participate, what tools and context it can use, and the limits of its authority.
A weakness in any one layer appears elsewhere. Unclear work produces confusing interfaces. Unclear decisions produce inconsistent outcomes. Unclear intelligence boundaries produce systems that feel powerful in a demo and unsafe in practice.
Work
Map the stages, dependencies, handoffs, and recovery paths.
Decision
Make evidence, judgment, authority, and accountability visible.
Intelligence
Define context, tools, limits, memory, evidence, and escalation.
Make the structure explicit.
Define the objects and states the system recognizes. Decide what information and context must travel with the work. Establish roles, permissions, ownership, and authority. Map handoffs, dependencies, safeguards, and recovery mechanisms.
This model becomes a shared language for product, design, engineering, operations, and leadership. It helps the team reason about changes before committing them to screens or code, and it gives every interface decision a larger purpose.
Can the system explain itself?
A strong architecture makes the current state legible. People can see what has happened, what is expected next, who has authority, and what to do when the normal path no longer applies.
If the team cannot explain those relationships without pointing at a screen, the system probably needs more design before the interface does.
Give every screen a system worth expressing.
The next field note continues the BFL framework from evidence to lasting capability.