Foundations

1. Why contemporary interfaces become difficult to maintain

1.1 A small visual change can expose a large architectural problem

Imagine a person writing an event invitation. The title and description are complete, a location is selected, and the message is almost ready to send. The person switches to a dark theme. The screen looks different, but the description disappears. Nothing about a dark theme requires losing text. The failure occurs because changing appearance also replaced the object that owned the draft.

A similar problem appears when a tablet rotates. A single-column screen becomes a two-pane screen, and the application opens the conversation again as though it were new. It may reestablish a connection, reload history, jump to the newest message, and clear the text selection. The layout changed, but the implementation treated it as a change in application identity.

These examples are not arguments against themes or adaptive layouts. They reveal an ownership problem. Several independent decisions have been placed behind one convenient operation called “build the screen.” The operation creates state, chooses layout, acquires resources, installs listeners and draws components. Repeating it therefore repeats more work than intended.

Figure 1. A theme change should replace presentation values, not the owner of a draft. The upper sequence illustrates an unwanted coupling; the lower sequence separates appearance, layout and retained state. See the illustrated PDF for the diagram.

The first challenge is to identify what is allowed to change independently. A theme may alter colors. A larger text setting may alter geometry. A navigation operation may introduce a new route entry. A graph update may replace a supported feature implementation. None of these operations automatically means that the person's unfinished work should be discarded.

1.2 A visual component is often less complete than it appears

A button can be drawn with a rounded rectangle, an icon and a label. That makes it recognizable to many sighted pointer users, but it does not define its behavior. A keyboard user needs to reach it. An accessibility service needs a name and an action. A pointer press can begin inside the control and end outside it. A disabled control must not accidentally invoke its operation through an alternative event path.

A custom component therefore carries obligations that are invisible in its default screenshot. A menu must manage focus and dismissal. A text field must cooperate with input methods and editing services. A dialog must define where focus enters and where it returns. WAI-ARIA's guidance emphasizes that assigning a role also makes a behavioral promise; the role itself does not implement that behavior. 1

The architectural problem becomes worse when two platforms independently implement components with similar names. Both may have a Button, a disabled property and a loading property, yet interpret their combinations differently. Shared names are not a shared contract. A design system needs an executable definition of behavior, not only a matching palette.

Figure 2. The visible button is the meeting point of four responsibilities. Meaning identifies the operation, behavior interprets interaction, appearance expresses the design language, and the graph governs application authority. See the illustrated PDF for the diagram.

1.3 Cross-platform reuse is not the same as identical rendering

A phone, a desktop window and a browser page do not impose the same conditions. A phone may lose a substantial part of its available height when the keyboard appears. A desktop user may expect menus, shortcuts and several windows. A web user may expect an ordinary link to support browser navigation and opening in another tab. Reusing application meaning is valuable; erasing these differences is not.

The difficult question is where to share and where to adapt. Sharing too little produces divergent implementations. Sharing too much can force every platform through the least capable abstraction. A component whose contract assumes only a mouse click cannot naturally describe touch cancellation, keyboard activation or a television's directional focus.

A better boundary shares intent and obligations while allowing the platform implementation to remain competent. “Choose one date” is shared meaning. The exact date picker may differ. “Open this resource” is shared meaning. A browser realization can preserve link behavior while a native realization uses the application's navigation contract.

Portability consequently needs a scope. It applies to a supported component on a supported renderer with a declared behavior profile. It is not a property that every arbitrary Kotlin or JavaScript function acquires merely because it belongs to a multiplatform project.

1.4 Adaptation has become more than a few screen-width breakpoints

A device category is a poor description of available space. A desktop inspector can be narrower than a phone. A tablet can have a small application window. A foldable display may contain an occlusion. A large text preference may make a two-column arrangement unusable even though the outer width did not change.

Android's adaptive guidance uses the application's available window and canonical layout patterns rather than a permanent device label. CSS container queries provide a corresponding way to respond to a containing region on the web. 2 3

The deeper problem is not choosing a threshold. It is preserving meaning while rearranging the interface. When a conversation moves from a full screen to a detail pane, the selected conversation remains the same. When a supporting panel becomes a sheet, its workflow state should remain associated with the same feature. Layout must be a presentation decision over application state, not a second navigation system that continually tries to synchronize itself with the first.

1.5 Responsiveness involves time as well as geometry

An interface can fit the screen and still feel unresponsive. A press may wait for a network result before changing appearance. Typing may stall because each keystroke updates a large shared object. A decorative background may keep rendering while hidden. An image may arrive after the text has been positioned and move the sentence the person is reading.

These failures involve different kinds of work. Some require less composition. Others require fewer layout passes, smaller image decodes, bounded queues or better ownership of animation. Treating all of them as “too many rerenders” conceals the actual cause.

A UI architecture must therefore describe the execution path, not merely the component hierarchy. It must distinguish immediate feedback from application results, and it must make resource use visible. A design language that looks elegant in a static preview may still be unsuitable if its blur, shadows or continuous effects exceed the budget of a supported device.

1.6 Generative interfaces increase the cost of unclear boundaries

A developer usually changes a screen before it is released. A runtime agent can propose a different arrangement while the person is already using it. That creates a new class of continuity problems. A field might be replaced after the person starts typing. A new suggestion might move a primary action beneath the pointer. A generated control might name an operation that the current user is not allowed to perform.

The answer is not to give generated interfaces a separate set of components and permissions. That would multiply the number of systems that must remain consistent. The same catalogue, state owners and application capabilities should constrain both human-written and agent-composed interfaces. Generation proposes a change to an approved graph-owned region. The graph's checked update mechanism activates it, and the renderer presents the result.

The objective is a system whose variability is controlled rather than suppressed. Themes, adaptation, tactile effects and generation remain powerful, but none is allowed to blur the ownership of application state or the authority to perform an operation.

1.7 Recognize the kind of failure before choosing the remedy

The same visible symptom can have different causes. A control that appears late may be waiting for data, an asset decode, a large composition, or an unnecessary feature initialization. A control that loses its value may have been assigned a new identity, disconnected from its draft owner, or overwritten by a stale acknowledgment. Adding a loading spinner or memoizing the nearest function does not distinguish these cases.

A useful first classification asks whether the failure concerns meaning, ownership, geometry or execution. Meaning concerns what the control communicates and can do. Ownership concerns which object is responsible for state and resources. Geometry concerns the space and position assigned to content. Execution concerns when and at what cost the work happens.

The categories interact, but they suggest different corrections. A missing keyboard action requires a behavior and semantics correction. A lost draft requires a lifetime or identity correction. A jumping message requires a geometry and anchor policy. A slow press requires investigation of the immediate execution path. Surface gives each correction a place instead of treating every defect as another component-specific exception.

2. The concepts that connect application meaning to pixels

2.1 State, events and the difference between them

State describes what is true now. A form contains a title. A conversation has unread messages. A button is currently pressed. An event describes something that happened: a title was edited, a message arrived, or a press began.

This distinction matters because the same state may be observed many times. Drawing a button repeatedly while it remains pressed must not produce a new haptic every time. The haptic belongs to the event that began contact, not to the fact that the control is still pressed.

Application state and interaction state also have different owners. The submitted message belongs to the conversation domain. A pointer's current contact belongs to a local interaction controller. Both are state, but one may need to survive a view replacement while the other should disappear when its pointer capture ends.

A component's public inputs describe controlled facts supplied by its owner. Its local state describes the interaction session needed to realize those facts. The component emits events to request meaningful changes; it does not silently redefine the application's records.

2.2 Composition chooses the interface's structure

Composition answers a question such as: given this application state, which components should exist and how should they be nested? A conversation page may contain a header, a timeline and a message composer. An empty timeline may contain explanatory text instead of message rows. A feature setting may permit an event-planning region.

Kotlin composables and React components are programming models for expressing these choices. They provide ordinary control flow and reusable functions. A loop over messages is still a loop; a conditional region is still a conditional expression. Surface does not need to invent a second general programming language merely to describe those operations.

The result of composition is not the final image. Text still needs measurement, containers still need placement, and the renderer still needs to draw. React's own explanation separates the rendering calculation from the commit that applies changes. Compose likewise distinguishes composition from layout and drawing. 4 5

Figure 3. Application data becomes a component structure, then measured geometry and drawing. Input returns through an explicit behavioral path. The arrangement is a conceptual pipeline; an implementation can skip stages whose dependencies did not change. See the illustrated PDF for the diagram.

2.3 Layout assigns space; drawing realizes appearance

Layout determines the size and position of each region. A parent offers constraints, such as a maximum width. A child measures its content within those constraints and reports a size. The parent then places it. Text, media aspect ratios and intrinsic sizing can influence the result.

Drawing uses the resulting geometry. It paints text, images, borders and surfaces, possibly into composited layers. A decorative translation can sometimes be applied without changing the space allocated by layout. Expanding a paragraph, by contrast, changes the space that following content needs.

Keeping these stages separate explains an important performance choice. Moving a button face down by a few pixels to suggest contact should not ordinarily cause the entire form to measure again. Changing the font size legitimately does require new text measurement. Efficient execution means invalidating the work that depends on a change—not denying that the change has consequences.

2.4 A design system supplies decisions, not only components

A component library provides reusable controls. A design system also explains the choices behind them: what different text roles mean, which actions receive emphasis, how errors are expressed, how much spacing belongs between related elements, and how movement communicates change.

Tokens give names to reusable values. A reference token might name a palette color. A semantic token names a purpose, such as primary-action background. A recipe explains how a particular component uses those roles in its variants and states.

This separation makes a design system themeable. A primary action does not need to know the hexadecimal color assigned by a brand. It needs the semantic role that the selected design package resolves. The same control can then participate in several visual languages without duplicating the operation it invokes.

2.5 A lifecycle describes an owner's existence

A lifecycle is not a synonym for “visible.” A conversation session can exist while its pane is hidden. A view can remain visible briefly during an exit animation after it has stopped accepting new actions. A texture can be released even though the document that used it remains open.

Lifecycle design answers when an object starts owning resources, when it can perform work, and when that ownership ends. The useful unit is the owner, not a universal list of lifecycle events copied into every class.

For example, a route-entry owner can retain a draft. A mounted renderer session can own a focus target and a decoded image lease. Hiding the view may pause its effects and release the image while leaving the draft untouched. Destroying the route entry can release its retained presentation state without deleting the underlying conversation record.

2.6 A graph makes relationships explicit

Reaktor Graph represents application structure using nodes, node-owned ports and connections. A node can own a repository, a workflow, a route or another capability. A port exposes a typed value or operation. Connections state which consumers rely on which providers. The graph's runtime also provides application scopes and navigation mechanisms. 6

The graph is useful because an interface does not operate in isolation. A Send action depends on a conversation operation. A participant picker depends on permitted people. A theme preference depends on a setting owner. These relationships can be explicit instead of being rediscovered through globals inside every control.

Graph-native UI does not require a graph node for every painted shape. A whole screen or reusable feature region can be owned by a graph node while its internal text and layout remain normal renderer structures. The application graph, the component hierarchy and the drawing scene answer different questions.

2.7 Contracts are promises; implementations are mechanisms

A contract states what a caller may rely on. An implementation states how that promise is achieved. “This control emits one activation for an admitted semantic action” is a contract. “This implementation uses a native button and observes its interaction source” is a mechanism.

This distinction makes reuse more precise. Two implementations may satisfy the same promise using different mechanisms. An implementation change is safe only to the extent that the required promises still hold. Reusing an interface name does not establish that equivalence; tests and qualification provide evidence.

A boundary also needs failure behavior. A requested image may be unavailable. A component version may be unsupported. A layout may not fit. Returning a structured finding allows the surrounding owner to choose a known fallback or alternative. Silently drawing an empty region makes the failure harder to diagnose and can remove an essential operation.

The same reasoning applies to optional effects. “This action remains usable without haptics” is a meaningful guarantee. “Every target has a vibrator” is an assumption the component should not require. Contracts describe what the application needs while capabilities describe what the current realization can supply.

3. The load-bearing ideas

The central reusable object is the component contract. It defines inputs, outputs, slots and behavioral obligations. An implementation realizes that contract using a renderer. A design recipe determines its appearance within a supported design language.

For a button, the contract includes an accessible name and an activation event. The recipe may produce a filled Material-like treatment or a hard-edged contact plate. The Compose and React web implementations need not draw identical pixels, but they must agree on whether the button can activate and what event activation produces.

This rule prevents design language from becoming business logic. A destructive action remains destructive in every palette. A disabled operation cannot become enabled because an alternative skin omitted the disabled check. A transparent surface cannot make its label optional to assistive technologies.

The practical consequence is that tests are shared at the semantic level. Each renderer runs equivalent interaction traces, while visual comparisons permit declared platform differences. A font's metrics may differ. Losing the component's name or invoking its operation twice is not an acceptable rendering difference.

3.2 Give each structure and state an owner

A React boundary owns its React composition. A Compose boundary owns its Compose composition. A graph workflow owns the application state that must survive presentation changes. A renderer session owns immediate editing and physical feedback.

Ownership prevents competing writers. A visual editor cannot independently mutate the inside of a live React component while React continues producing a different tree. An agent submits a change through the owner. A parent can mount a child, supply its declared inputs and receive its events, but does not acquire arbitrary mutation rights over the child's internal state.

The same principle applies to resources. An image lease has an owner that can release it. A field registration ends when the participating component leaves its scope. A callback belongs to one runtime generation, so an old callback cannot accidentally resolve to a new control that reused its numeric slot.

Explicit ownership is also what makes the system understandable. When a draft disappears, the relevant question is not “which framework is broken?” It is “which owner was replaced, and why was the draft attached to it?”

3.3 Keep the fast feedback loop local

A person should feel contact before a remote operation finishes. Press compression, local focus treatment and immediate editing therefore run inside the local presentation boundary. They consume already-bound capabilities and local input rather than traversing the application graph each frame.

Meaningful operations still return through the graph. A button's activation may send a message or change a route. The resulting state is observed by the affected UI scope. This separation allows the control to be responsive without pretending that the operation has already succeeded.

Figure 4. The presentation loop handles contact and motion locally. The application loop invokes a capability and observes its result. A renderer can provide immediate feedback during latency without misrepresenting the outcome. See the illustrated PDF for the diagram.

The rule applies to both renderer families. It does not mean that every animation is written in Kotlin on every target. It means that frame-level work stays in the runtime best placed to execute it. A CMP implementation can use Compose's animation and drawing paths; a React web realization uses its qualified platform mechanisms.

3.4 Treat adaptation as a projection of existing state

An adaptive layout chooses how much of the interface is visible at once. It does not decide what the conversation means or create a second set of route entries. A presentation policy reads navigation state, environment and preferences, then assigns entries to panes.

A compact window may show the conversation alone. An expanded one may show its list and supporting details. The same route-entry and workflow owners remain. This is why the layout policy can be a pure function while the stateful navigation owner stays in the graph.

Theme changes follow an analogous rule. A new theme snapshot changes recipes and, where necessary, measurements. It does not automatically create a new route or a new draft owner. When a structural implementation change cannot preserve transient state directly, the boundary declares what must be transferred or restored.

3.5 Make tactility causal and bounded

Tactility means that the interface responds as though its elements have material relationships. A press has a location and a duration. The button face may move toward a stationary support. A neighboring card may respond to the same impulse. A procedural background may reveal a wave-like disturbance.

The relationship is causal: a particular input produces a particular response. It is also bounded: the effect has a scope, maximum amplitude and lifetime. A receiver does not automatically emit another input that starts an endless chain. A quiet theme can reduce the response without removing the component's meaning.

This model is richer than attaching unrelated animations to controls. The components and background share an interaction signal, but remain decoupled from each other's implementation. A card does not call a shader function directly. Both consume the field within their local scope.

3.6 Define dynamic UI as graph-owned change

A dynamic interface can change its content, arrangement or supported implementation. These changes still belong to an application owner. Surface assumes that Reaktor can activate supported subgraph updates using the existing graph, FFI and Hermes infrastructure.

The UI-facing contract is intentionally smaller than the update system. After a compatible subgraph is active, affected Surface bindings observe the new definition or state. The relevant renderer updates the region. Unchanged owners retain their state, and retired callbacks cannot enter the new generation.

Human authors and agents therefore use one change model. An agent does not directly install a private UI runtime beside the application. It proposes a change to an approved region whose capabilities and component catalogue are already constrained by the graph.

4. High-level architecture

Figure 5. The graph provides ownership, state and application capabilities. Surface adds component contracts and presentation policies. Local execution realizes those contracts through Compose Multiplatform or React web/JS, with a portable host for shared Kotlin authoring. See the illustrated PDF for the diagram.

4.1 The graph is the application foundation

Every running Surface application has Reaktor Graph. A Surface boundary attaches to an application owner and receives a checked view of its state and operations. It does not create another dependency-injection container, router or authorization service inside the design system.

This assumption simplifies component composition. A feature can declare the capabilities it consumes, and an inspector can explain those bindings. A child control does not need the entire graph object merely to invoke one operation. Generated or handwritten adapters can expose a small typed action interface.

For a conversation, that interface might contain send, retry and openProfile. The renderer sees the operations appropriate to the screen. The graph remains responsible for finding their implementations and enforcing authoritative policy. An in-process call need not be serialized simply because it travels between graph-owned capabilities.

4.2 Surface owns presentation contracts

Surface's shared definitions describe component meaning, theme roles, behavior policies, layout decisions and resource requirements. They are independent of Compose UI classes and DOM objects. A component can therefore be described before either renderer implementation is chosen.

The catalogue connects each definition to its implementations and tests. The theme resolver produces a coherent appearance snapshot. The presentation policy assigns route entries to visible regions. Together, these mechanisms determine what a mount needs to render without taking ownership of the application's business records.

A mount is one attachment of a Surface implementation to a host, such as a window or a region within a screen. It has an address and a lifetime. Several mounts can present the same business object while retaining separate focus, scroll and editing-session details.

4.3 The renderer owns platform realization

The renderer translates neutral meaning into platform behavior and drawing. For CMP, it can reuse Compose Foundation, Material components and platform integrations. For React web/JS, it uses ordinary React components and browser controls. Kotlin React supplies the Kotlin/JS bindings for the Manna realization. React Strict DOM is an optional web substrate experiment; its native support does not add a Surface target. React Native and custom React-to-Compose reconciliation are deferred. 7

The renderer also supplies measured constraints, input normalization, resource handles and frame timing. It knows how local logical coordinates map into actual drawing space. Shared algorithms can use those services without assuming a particular window toolkit or graphics backend.

Capability differences remain explicit. A renderer may support a component fully, support a declared reduced treatment, or report it unavailable. An opaque surface is a reasonable fallback for unavailable blur. Omitting an essential consent control is not.

4.4 Different representations answer different questions

The application graph answers who owns state and operations. The composition program answers which controls should exist. A portable host tree, when used, records the committed instances produced by that program. Layout and drawing structures describe geometry and rendering. The accessibility tree describes semantic operation.

Figure 6. The architecture contains several related representations because each has a different job. None is allowed to silently become a competing owner of the application state represented elsewhere. See the illustrated PDF for the diagram.

A drawing layer can be absent from the accessibility tree because it is decorative. A single semantic button can contain several visual layers. A graph-owned screen can contain thousands of virtualized item instances without giving each item its own actor and application scope.

Inspection relates these representations through stable identities and source mappings. It does not claim that the rendered output contains enough information to reconstruct every source-level loop or conditional. A visual editor changes supported declarations or asks the source owner to change code.

4.5 Compile decisions that do not need to remain dynamic

Token aliases, static component definitions and supported recipe variants can be validated before rendering. The runtime then consumes compact resolved values rather than repeatedly interpreting the same authoring document.

Other inputs remain live. Application state changes. A window is resized. A person presses a control. Surface binds these changing values at the smallest useful scope. It does not rerun every graph analysis whenever a pointer moves.

The distinction is similar to preparing a route before using it. The binding step determines which operation the Send action refers to. The next press uses that binding; it does not repeat global discovery. Authorization is still checked at the operation's authoritative boundary, because an old binding is not permanent permission.

4.6 Read the architecture through one change

Suppose a setting increases the application's text scale. The application owner records the preference. The affected Surface environment changes. Recipes resolve the required text roles, and layout measures the content again. A supporting pane may collapse because the larger text needs more room. A collection restores the item being read after remeasurement.

Notice which owners did not change. The conversation record is still the conversation record. The draft is still associated with the same workflow. The navigation entry is not replaced just because the pane moved. Only resources and cached results that depend on the changed typography or constraints become invalid.

This provides a practical way to use the HLD. Begin with the changed input, identify its owner, follow the dependencies that consume it, and stop where those dependencies end. An architecture is easier to understand when its arrows explain the consequences of a concrete event rather than merely connecting every subsystem to every other subsystem.

5. Platforms, composition languages and rendering families

5.1 Two terminal families

The finalized renderer targets are React for web in a JavaScript runtime and Compose Multiplatform. CMP has the existing production adapter foundation and direct access to the Compose ecosystem. React web realization is planned. React Native and additional renderer or reconciler tracks are outside the current plan. Neither target name establishes that every platform profile or editor engine is already qualified.

A renderer family is not the same as a single platform. Each family still has target-specific behavior, input, graphics and lifecycle concerns. CMP integration with platform facilities is distinct from claiming that every control is an operating-system widget. The documented relationship between Compose Multiplatform and Jetpack Compose provides the relevant toolkit boundary. 8

Figure 7. Platform profiles identify the conditions an implementation must handle. The shared design vocabulary does not erase different navigation, input, lifecycle and delivery expectations. See the illustrated PDF for the diagram.

The shared API is designed so that adding the React web renderer does not require changing what a button or field means. It will still require platform implementation work. Minimal architectural change is not zero engineering work.

5.2 Authoring and realization are separate choices

HLD — Authoring and renderer choice are separate. Manna requires the portable Kotlin path; direct CMP remains available. Open the diagram for full size.

A developer can write Kotlin composables that directly use the CMP implementation. This is the shortest path for the first application. It avoids a portable host tree and cross-runtime transport when neither is needed.

A developer can use the React web realization through Kotlin/JS bindings. Other Surface consumers may use generated TypeScript-facing contracts; Manna's final product is authored in Kotlin. The Kotlin behavior kernels compile to JavaScript, while the DOM adapter normalizes platform input and satisfies the same semantic traces.

Manna needs one portable Kotlin Surface composition. A Surface-specific Compose Runtime Applier emits a keyed host structure, which either the React web adapter or the CMP adapter realizes. This is planned framework work and an early migration gate. Direct Compose remains available to other consumers. Ordinary Compose UI functions cannot be inserted into that portable vocabulary without an explicit compatible island. A custom React-to-CMP renderer is not needed for this path.

Figure 8. Direct Kotlin-to-CMP remains available. Manna's portable Kotlin composition requires a common host with React web and CMP realizations. The inline HLD reflects the 6 October target decision; the linked PDF is an earlier design snapshot.

5.3 Portable composition is an explicit vocabulary

A composable function is not automatically portable to any possible tree. Ordinary Compose UI functions create the kinds of nodes expected by Compose UI's own machinery. A custom Surface Applier creates Surface host nodes instead. Only functions written for that portable vocabulary, or explicit compatible islands, belong inside that composition.

This matters for honest API design. A public SurfaceButton can have a CMP implementation and a portable host declaration. An arbitrary third-party Compose canvas cannot be promised to appear in a browser DOM merely because it was called from Kotlin.

The restriction preserves expert implementations. A specialized editor can remain a native island on CMP. A corresponding React web profile can supply another editor implementation or a deliberate unavailable result. The component contract specifies the boundary; it does not require translating the editor's internal rendering code.

5.4 Platform differences should be explained at the boundary

A portable date value, a logical length and an asset identity are useful shared values. A platform image object or DOM element is not. Local adapters convert the shared values into the objects their toolkit requires.

Behavior follows the same pattern. The shared button machine recognizes focus, contact, cancellation and activation. A platform adapter decides how its native input events become those normalized inputs. This allows the implementation to preserve platform conventions without putting operating-system checks inside every shared reducer.

The architecture consequently combines a small shared meaning with rich local realization. It avoids two opposite failures: duplicating the entire design system per platform, and forcing every platform into an abstraction too weak to express its normal behavior.

5.5 Portability has a useful floor and explicit extensions

The portable floor contains the concepts that can be given reliable shared meaning: text, actions, fields, selection, layout relationships, resources and application bindings. A product can build a substantial interface from that floor without knowing the internals of either renderer.

Extensions preserve the cases that do not fit the floor. A map may need a native engine. A scientific model may need custom drawing. A rich editor may need its own text services. The extension exposes the boundary required for sizing, actions, lifecycle and inspection, while keeping its internal machinery intact.

This is different from a least-common-denominator design. The shared layer does not forbid advanced features; it requires those features to declare where they work and how the application behaves when they do not. A supported native picker can coexist with a supported web picker. The application asks for a value under a contract rather than insisting that every platform reproduce one platform's internal widget structure.

6. A worked example: one Send action through the whole system

6.1 Before interaction

The conversation owner exposes a presentation model and a typed action interface. The model contains the draft and the state needed to show whether sending is available. The Surface mount subscribes to that model and resolves the selected theme.

Composition creates a message composer organism. The organism contains an editing field, an attachment control and a Send button. The button receives controlled properties such as its label, emphasis, enabled state and busy state. It does not fetch the conversation repository itself.

The selected recipe determines the button's visual treatment. In a quiet desktop language it may be a restrained solid control. In an expressive language it may have a moving face above a fixed contact plate. Both implementations expose the same semantic action.

6.2 Contact begins

The renderer receives a pointer press or the equivalent platform input. Its adapter normalizes the event and sends it to the independent behavior machine. The machine records the active press and emits a contact cue.

The local motion driver responds to that cue. The face moves toward the support. If the recipe permits it, one field impulse is emitted into the composer's effect scope. The surrounding plate and background can respond without calling the conversation service.

An optional haptic acknowledges contact. It does not mean that the message was sent. The cue is executed once by the effect path; it is not replayed when the pressed state is drawn again.

6.3 Activation is admitted

The platform's semantic activation path produces one normalized activation. The behavior machine checks current controlled availability and emits a typed button event. The composition owner translates it into the bound conversation operation.

The graph's application boundary checks the current principal, conversation and operation arguments. It then performs the send workflow. A local pending message may appear immediately if the workflow supports optimistic delivery, but that state is owned by the application and is labelled as pending.

The control does not infer delivery from the completion of its spring. A failed send can return a recoverable state with retry and discard operations. A successful send can update the timeline and, if appropriate, produce a separate result cue.

6.4 The layout changes during the operation

Suppose the window becomes wider while the send is pending. The presentation policy now has room for the conversation list beside the timeline. It changes pane assignment but preserves the route entry and conversation owner.

The pending operation continues. The draft's declared state survives. Local focus and scroll restoration are handled by the relevant mount. No second send occurs, because rendering is not the action path.

Suppose instead that a supported subgraph update adds an event summary to the conversation. The graph activates the new region. Surface rebinds and renders that region through CMP or React web. The new region does not acquire arbitrary authority over the draft.

6.5 Why this example is the architectural test

The example combines the most important boundaries: application state, independent behavior, atomic composition, theming, tactile feedback, layout, authorized operations and dynamic change. Each subsystem performs one job and exposes its connection to the others.

The result is not merely an animated button. It is a component whose behavior remains intelligible while its appearance, context and implementation vary. The same reasoning applies to a form submission, a node-editor command or an offline evidence capture.

The foundational rule is to preserve meaning and ownership while allowing presentation to change. The rest of the architecture turns that rule into interfaces that can be implemented and tested independently.