# Cluster 0 — Immediate-Mode Paradigm (Philosophical Anchor)

**Sub-report for Section 2 of the main report: "Intent-Based Scripting Languages"**
**Track: `intent_dsl_survey_20260612`**
**Author: Tier 2 sub-agent (research dispatch)**
**Sources: John O'Donnell — `https://johno.se/book/` (IMGUI / The Pitch / MVC / IM-MVC roadmap)**

---

## Introduction

This sub-report covers the single entry for Cluster 0: John O'Donnell's *Immediate Mode Model/View/Controller* (2007–2008), a working manuscript published across four interconnected pages at `johno.se/book/`. Cluster 0 is the philosophical anchor for the entire report — the four anchor claims in Section 1 (widgets are method invocations, reads are free/writes are formalized, IEventTarget, no scene-graph abstractions) all derive from O'Donnell's work and must be understood before the other clusters can be properly situated.

O'Donnell's book was written in the context of game development (specifically Massive Entertainment's Ground Control series), but its core arguments are framework-agnostic. The central thesis — that visualization is not inherently stateful, and that retained-mode UI toolkits impose a synchronization burden that is unnecessary given modern GPU capabilities — applies directly to the DSL's Meta-Tooling tier. The DSL's verbs (sandbox, audit, intent_mapping, sandbox_execute) are not merely "secure" or "auditable" — they are architecturally faithful to O'Donnell's invariants.

---

## Entry: John O'Donnell — IMGUI / The Pitch / MVC

### What the Work Is

John O'Donnell's in-progress book (*Immediate Mode Model/View/Controller*, 2007–2008) lays out a unified paradigm for game UI and application architecture. The core claim across all four pages is that **visualization is not inherently stateful** — the dominant assumption in OOP toolkits (MFC widgets, Ogre scene graphs, HTML DOM) is a historical artifact, not a technical necessity. O'Donnell calls this the "broken paradigm" and argues it is the root cause of synchronization complexity between application state and UI state.

The four pages serve distinct roles in the overall argument:

- **`imgui.html`** — The canonical IMGUI essay: defines widgets-as-method-invocations, presents a complete C++ `Gui` class with buttons/radios/edit boxes/tree controls/combo boxes/sliders/drag-and-drop, and distinguishes deferred vs. direct display. This is the most concrete page — it has actual code for every widget type.
- **`pitch.html`** — "The Pitch": frames IMGUI as a paradigm shift, attacks the retained-mode premise in detail, introduces the Controller as the per-frame "programmer" of View, and argues that GPU advances have eliminated the performance justification for retained mode. It traces the history from DirectX 3's Retained/Immediate Mode split through to modern GPU batch rendering (Jungle Peak's 800,000-vertex single-draw-call).
- **`immvc.html`** — The book roadmap: maps the six-chapter structure (IMGUI → MVC/E → Persistence), explicitly names `IEventTarget` as central to multiplayer and async design, traces the author's design journey from Ground Control via Josephine/GC2 to MVC/E, and outlines the experience progression that led to the architecture. This page also contains the design rationale for why a single event interface is superior to separate read/write interfaces.
- **`mvc.html`** — The MVC chapter proper: defines `Model` (const-only access), `View` (procedural, stateless), `Controller` (per-frame orchestrator), formalizes the **"reads are free, writes are formalized"** invariant via a single `IEventTarget` interface, shows how the pattern extends transparently across a network, and details the Director pattern for managing local/listen/dedicated server modes.

### What We Take From It

The DSL's Meta-Tooling tier builds on O'Donnell's immediate-mode philosophy in four specific ways:

1. **Widget identity is an illusion.** A widget is a method call, not an object. This maps directly to the DSL's treatment of verbs (sandbox, audit, intent_mapping) as stateless procedure calls, not stateful resources. The execution context is created fresh at call time and torn down at return time.
2. **Reads are free, writes are formalized.** Every write to Model state must pass through `IEventTarget`. The DSL inherits this invariant: every Tier 4 verb that mutates state must be a formal event, not a direct write. The const Model reference is the only handle the execution context holds.
3. **The IEventTarget pattern is a universal event bus.** O'Donnell shows that a single interface covering all state-change events (including visualization callbacks) works better than separating read and write interfaces. The DSL's verb dispatch inherits this pattern: one interface, multiple implementations (local Model, audit logger, remote proxy).
4. **View must not expose scene-graph abstractions.** The MVC chapter explicitly forbids exposing mesh/transform pair abstractions in View's public interface; instead it must be `view::drawMesh(mesh, transform, ...)`. The DSL's sandbox/execute verbs enforce this: the sandboxed execution context is a flat procedure, not a hierarchical object graph.

---

## Background: The Intellectual Lineage

### The MVC Origins

O'Donnell traces MVC to Trygve Reenskaug's original 1979 work at Xerox PARC, where the pattern was conceived for the Smalltalk environment. O'Donnell notes the key separation:

> "multiple views example: Model, PieChart, SpreadSheet, BarChart — Model is state; Views (potentially many) visualize state; Controller reacts to user input in order to manipulate Model." — `pitch.html`, "Origins" section

The classic MVC pattern, as implemented in Smalltalk's MVC and later in MFC's Document/View, assumed that Views are stateful — implemented as objects with encapsulated state and behavior. O'Donnell accepts the premise of MVC (the separation of Model, View, and Controller as distinct roles) but rejects the stateful View assumption as the root cause of synchronization complexity.

### MFC's Document/View as the Cautionary Example

O'Donnell singles out MFC's Document/View as a particularly harmful instantiation of the stateful View assumption:

> "Compare to MFC's Document/View, where MFC's View acts as both Controller (handles input) and View (output/visualisation)... Document/View is quite useful, because very often the context in which user input is applied depends on visualisation (i.e. a scrolling view of a document)." — `pitch.html`, "Origins" section

MFC's approach collapsed the Controller into the View, eliminating the per-frame compositional role that O'Donnell's Controller plays. The result was a widget toolkit where every window was simultaneously a View (visualizing state) and a Controller (handling input), with no clean separation between the two roles.

### The DirectX 3 Historical Irony

O'Donnell notes a striking historical irony in the evolution of graphics APIs:

> "Observe, somewhat ironically, that DirectX 3, ca. 1996 had 2 modes of operation for graphics, namely Retained Mode and Immediate Mode. At least before DirectX 6 in 1998, Retained Mode was dropped from the API, because game devs simply did not use it. They wanted more control." — `pitch.html`, "Origins" section

The industry already rejected retained mode at the API level in 1998, but then re-created it as an application-level pattern (scene graphs, instance abstractions) on top of the immediate-mode GPU interface. O'Donnell's argument is that game developers should have gone all the way — not just to a low-level immediate mode API, but to an application architecture that is also immediate-mode at the UI level.

### The Ground Control Experience Progression

O'Donnell traces his own intellectual journey through three major projects at Massive Entertainment:

**Ground Control (GC):** Introduced the client/server model with separate local and remote representations of game entities. The initial architecture used message-based communication between IGame (server) and IPlayer (client) implementations.

**Josephine and GC2:** The persistence system (Juice) evolved into a data definition language, persistence scheme, and runtime memory format. The realization grew that there is great value in being able to inspect data and **derive** other data from this, and also visualize data in a number of different ways. The experience with GC2's unit relations (bi-directional pointers, entity state caches) showed how duplicated state across IPlayer implementations became a maintenance burden.

**MVC/E:** The final architecture that emerged: Model (singleton with const-only access), View (procedural, stateless), Controller (per-frame composer), and IEventTarget (single formal interface for all state changes). The key realization was that state duplication — even within a single application — is the source of synchronization bugs.

This progression is documented in detail on `immvc.html`, which contains O'Donnell's "experience progression" narrative from GC through Josephine/GC2 to MVC/E.

### GPU Batch Rendering as the Performance Vindication

O'Donnell provides an empirical result that directly falsifies the performance argument for retained mode:

> "In DirectX9 is possible to render very large batches of primitives per draw call. At Jungle Peak we rendered 800 000+ vertices in a single call on nVidia GeForce 6 class hardware, with good performance. The meant a number of things, such as discarding the concept of camera culling. We simply batched together all instances of a particular mesh into a single huge vertex/index buffer pair (one per texture basically), and sent them all to the hardware with very few calls." — `pitch.html`, batch rendering section

If 800,000 vertices can be rendered in a single draw call, there is no performance justification for the complex state management that retained-mode scene graphs require. The GPU is not the bottleneck; the CPU-side state management is. This empirical result is the quantitative foundation for O'Donnell's claim that the retained-mode premise "no longer holds."

---

## Terminology Glossary

To make the Connections section legible, the following O'Donnell-specific terms are defined here:

**IMGUI (Immediate Mode GUI):** A UI paradigm where widgets are method calls, not persistent objects. The client application passes all state required for a widget at call time; the widget has no internal state that persists between calls. Contrast with "retained mode" where widgets are objects with encapsulated state.

**Retained Mode:** The dominant UI paradigm where widgets are objects that persist across frames and cache application state internally. Requires explicit synchronization between the application's state and the widget's cached state. The target of O'Donnell's critique.

**Model:** The authoritative source of application state. In O'Donnell's MVC/E, Model is a singleton with const-only external access (`const Model&`). All state that needs to survive across frames lives in Model. URL: `https://johno.se/book/mvc.html` — "Model" section.

**View:** The input/output layer. From a client (Controller) perspective, View is completely stateless — it exposes only a procedural interface (`drawMesh`, `drawRect`, etc.) with no retained state accessible to the client. View may cache internally for performance, but this cache is invisible to the client. URL: `https://johno.se/book/mvc.html` — "View" section.

**Controller:** The per-frame orchestrator. Each frame, Controller traverses Model's state and "programs" View to produce the current visualization. Controller is the only component that holds both a View reference (for writing output) and an IEventTarget reference (for writing to Model). URL: `https://johno.se/book/pitch.html` — "MVC revisited" section.

**IEventTarget:** The single formal interface through which all state changes flow. A pure virtual C++ class defining all possible events (`CreateEntity`, `DestroyEntity`, etc.). Both local Model and network proxies implement this interface identically. URL: `https://johno.se/book/mvc.html` — "Writing to Model state" section.

**MetaController:** A parent Controller that manages switching between multiple child Controllers (e.g., PlayController and EditController). Enables instant switching between radically different input schemes and visualizations without any cleanup. URL: `https://johno.se/book/mvc.html` — "Controller" section.

**Director:** The top-level orchestrator that manages local/listen/dedicated server modes. Encapsulates the configuration of Model, View, Client (remote proxy), and Server. URL: `https://johno.se/book/mvc.html` — "The Director" section.

**Frame shearing:** A phenomenon in real-time IMGUI where a user interaction (resolved on frame N) changes application state that controls the UI appearance, but the UI drawn on frame N was generated before the interaction occurred, resulting in parts of the displayed image reflecting the old state and parts reflecting the new state. O'Donnell's solution is a "shearing exception" that restarts GUI generation for the current frame. URL: `https://johno.se/book/imgui.html` — "Frame shearing" section.

**Deferred display:** A display strategy where widget drawing calls are buffered (e.g., into a vertex buffer) and flushed all at once, rather than rendering immediately. Used in hardware-accelerated applications where batching primitives is more efficient than immediate rendering. URL: `https://johno.se/book/imgui.html` — "Deferred display" section.

---

## Detailed Analysis

### Anchor Claim 1: "Widgets Are Method Invocations, Not Objects"

**Source:** `https://johno.se/book/imgui.html` — "Immediate Mode applied" section, third paragraph:

> "Widgets, logically, change from being objects to being method invocations."

#### The Broken Paradigm

O'Donnell opens the essay with a direct attack on the foundational assumption of all major UI toolkits:

> "There is a dominant paradigm within programming since (forever?), and that simply: ***The user interface and / or visualization of any program is inherently stateful.*** I maintain that this is a broken paradigm. Not that such things CANNOT be stateful; the current state of various software technlogies are indeed based upon this paradigm. I will however argue that avoiding such statefulness **significantly** simplifies software." — `imgui.html`, "The broken paradigm" section

The word "broken" is used deliberately: O'Donnell is not saying stateful UIs are impossible or that they don't work — he is saying they carry a structural complexity burden that is unnecessary. The complexity is not in the problem domain (building user interfaces is genuinely hard) but in the solution domain (retained-mode toolkits amplify that difficulty by adding a synchronization layer that the problem doesn't require).

#### The State-Copy Problem

The mechanism by which retained mode introduces complexity is the state copy / cache:

> "I maintain that much of the complexity associated with the design and use of of traditional user interface systems is a direct result of the tendency of such systems to retain state. The programmer is typically required to actively copy state back and forth between the application and the user interface in order for the user interface to reflect the state of the application, and conversely, for changes that happen in the user interface to affect the state of the application." — `imgui.html`, "The woes of caching state" section

This is the core observation: retained-mode UI toolkits don't just happen to have state — they *require* the programmer to actively manage a copy of application state in the UI layer. The copy is not a side effect; it is the design contract. O'Donnell names this explicitly:

> "This is the basic problem; this state (inherent to the user interface system) is a COPY / CACHE of the REAL state, which is owned by and resides with in the specific application itself." — `imgui.html`, "The woes of caching state" section

The emphasis on "COPY / CACHE" and "REAL state" is O'Donnell's terminological choice. The UI system has its own copy; the application has the real copy; the two must be kept in sync. Every synchronization point is a potential bug source: missed updates, stale reads, circular dependencies in the update direction.

#### The Three-Way Synchronization Burden

O'Donnell describes the synchronization burden in detail:

> "The user interface, from the point of view of the client application, most often looks like a collection of objects, typically one per 'widget', which encapsulate state that needs to be frequently synchronized with that of the application. Such synchronization goes both ways; state moves from the application to the user interface in order for that state to become visible to the user, and state moves from the user interface back to the application when the user interacts with the interface in order to change the state of the application." — `imgui.html`, "The woes of caching state" section

The "both ways" synchronization is the key burden. In a typical retained-mode toolkit:
1. Application → UI: application pushes state to widget objects so the widget can display it
2. UI → Application: widget fires events; application pulls state from widget objects to update application state

This bidirectional push/pull is the synchronization overhead O'Donnell targets. It is not a bug in any particular toolkit — it is a structural consequence of the retained-mode design choice.

#### The Callback Complexity Layer

On top of the synchronization burden, retained-mode toolkits add callback complexity:

> "Additionally, the manner in which the application is notified of user interactions with the interface (which in turn signals a need for re-syncing of state) often takes the form of callbacks. This requires the application to implement 'event handlers' for any low-level interaction that is of interest, often by subclassing some toolkit baseclass either manually or via various code generation tricks; in either case further complicating the life of the client application." — `imgui.html`, "The woes of caching state" section

The callback pattern is itself a form of indirection that O'Donnell identifies as a source of complexity. The callback fires when the widget state changes; the application must then pull the new state from the widget object and reconcile it with the application state. This is a third synchronization point (widget → callback → application → widget → application) layered on top of the bidirectional sync.

#### The IMGUI Alternative: No State to Synchronize

O'Donnell's alternative eliminates the problem at the root:

> "**IMGUI** does away with this type of state synchronization by requiring the application to explicitly pass all state required for visualization and interaction with any given 'widget' in real-time. The user interface only retains the minimal amount of state required to facilitate the functionality required by each type of widget supported by the system." — `imgui.html`, "Immediate Mode applied" section

The phrase "only retains the minimal amount of state" is precise. O'Donnell is not claiming IMGUI is completely stateless — edit boxes need to track which string has focus, sliders need to track the drag handle position, tree controls need to track expand/collapse state. But the retained state is *minimal* and *internal to the widget type*, not a copy of application state. The application state lives in one place (the application), and the UI visualizes it by receiving it as call parameters.

#### The Conceptual Shift: Widgets as Method Calls

O'Donnell states the conceptual shift in the clearest possible terms:

> "With **IMGUI**, a conceptual shift occurs. Widgets are no longer objects at all, and can't really be said to 'exist'. They take instead the form of procedural method calls, and the user interface itself goes from being as stateful collection of objects to being a real time sequence of method calls." — `imgui.html`, "Immediate Mode applied" section

The phrase "can't really be said to 'exist'" is the key: a widget in IMGUI is not an entity that persists in memory, has identity, and holds state. It is a procedure that runs, does its work, and returns. The "widget" is the call; the call is the widget.

#### The Enabling Mechanism: Real-Time Loop

O'Donnell identifies the real-time application loop as the enabling mechanism:

> "Fundamental to this approach is the concept of a real-time application loop, where the application processes logic and draws its display at real-time rates (30 frames per second or more). In the context of games, this is already common practice." — `imgui.html`, "Immediate Mode applied" section

The real-time loop is what makes IMGUI feasible: at 30+ fps, the cost of re-creating widget state each frame is negligible compared to the cost of maintaining synchronization between retained-mode widget objects. The loop also means the UI is always displaying the current application state — there is no "last drawn" state that can become stale between frames.

#### Code Evidence: The button() Implementation

The most concrete evidence for the "widgets as method calls" claim is the actual code. O'Donnell's complete `button()` implementation:

```cpp
const bool Gui::button(const int aX, const int aY,
                       const int aWidth, const int aHeight,
                       const char* aText)
{
    drawRect(aX, aY, aWidth, aHeight);
    drawText(aX, aY, aText);

    return mouse::leftButtonPressed() &&
           mouse::cursorX() >= aX &&
           mouse::cursorY() >= aY &&
           mouse::cursorX() < (aX + aWidth) &&
           mouse::cursorY() < (aY + aHeight);
}
```

Three lines of code. No button object. No state map. No event subscription. The return value is a `bool` — the interaction result — computed directly from the mouse state at call time. This is a method invocation, not an object.

#### Empirical Evidence: UfoPilot II Collapse

O'Donnell provides a quantitative before/after from his own project:

> "In one of my games, UfoPilot II : The Phadt Menace, the entire 'front-end' user interface was initially implemented in classic retained mode style. This was more or less equivalent to how MFC dialog boxes worked, in that I had a class for each specific 'screen', and instantiated an object of each of these classes as the user navigated throughout the interface. Each 'screen class' had multiple widget members, and layout was part of construction and much a manual issue where I would run the program, look at the placement of things, shut it down, edit the code, and repeat." — `imgui.html`, "An example of simplification" section

After porting to IMGUI:

> "Upon porting this user interface to **IMGUI**, with toolkit-methods being implemented as needed during the porting process (I built my Gui class as I went along, moving code from Widget classes to the Gui class), I gained several things: Firstly, in each case where there was a class for a 'screen', this collapsed from a class to a single method in a Menu class (which represented the entire collection of front-end screens and code). So where I had previously had about 10-15 classes I now had a single class. All of the widgets classes collapsed into methods of the Gui class, so again, where I previously had several classes I now had one." — `imgui.html`, "An example of simplification" section

10-15 classes → 1 class. The mechanism: widget state that was previously stored in per-widget objects is now passed as call parameters by the client code.

#### The List Box: Strongest Example

The list box example is the clearest demonstration of the "widgets as method calls" principle:

> "Most user interface toolkits support the concept of a list box / list control. Interestingly this widget type is largely obselete with **IMGUI** (unless you explicitly require scrolling support; see the section on advanced features). Since a list is often simply a bunch of text labels, you can support that by simply doing the following... At this point it should be clear that the list box / list control concept doesn't exist per-se in **IMGUI**, as you can simply iterate application state and 'do a widget' per item in your collection." — `imgui.html`, "Hey, where's the list box?" section

The retained-mode list control is an object that manages selection state, scroll position, and item rendering internally. The IMGUI alternative: iterate the application data directly and call `radio()` per item. The selection state is stored in the application (`mySelection`), not in the widget. The widget call is the visualization; the data is the Model.

#### The Radio/Check/Tab Equivalence

O'Donnell notes a surprising consequence:

> "An interesting aspect of **IMGUI** is that the classic widget types radio button, check box, and tab (i.e. like in a property sheet) are functionally equivalent from a client perspective. The various methods are here only for aesthetic reasons, i.e. depending on your application one or the other may be more applicable." — `imgui.html`, "Radio buttons, check boxes, and tabs" section

This is a direct consequence of the "widgets as method calls" claim: if widgets are just method calls, then the distinction between radio, check, and tab is purely a presentation choice made by the caller (which method to call, and with which visual parameters), not a property of the widget itself. The widget has no internal state distinguishing radio from check from tab.

**Take bullets (for Tier 1 copy into Section 1 anchor claims):**

- **[Anchor Claim 1 — primary]** "Widgets, logically, change from being objects to being method invocations." — `imgui.html`, "Immediate Mode applied" section, third paragraph. URL: `https://johno.se/book/imgui.html`
- **[Anchor Claim 1 — root cause]** "This is the basic problem; this state (inherent to the user interface system) is a COPY / CACHE of the REAL state, which is owned by and resides with in the specific application itself." — `imgui.html`, "The woes of caching state" section.
- **[Anchor Claim 1 — mechanism]** The IMGUI `button()` is three lines: `drawRect`, `drawText`, return mouse-poll bool. No widget object, no state map, no ID. — `imgui.html`, "Implementing basic interactions" section.
- **[Anchor Claim 1 — empirical]** UfoPilot II front-end collapsed from ~10-15 classes to 1 class after porting to IMGUI. — `imgui.html`, "An example of simplification" section.
- **[Anchor Claim 1 — list box dissolution]** "The list box / list control concept doesn't exist per-se in **IMGUI**, as you can simply iterate application state and 'do a widget' per item in your collection." — `imgui.html`, "Hey, where's the list box?" section.
- **[Anchor Claim 1 — conceptual shift]** "Widgets are no longer objects at all, and can't really be said to 'exist'. They take instead the form of procedural method calls." — `imgui.html`, "Immediate Mode applied" section.
- **[Anchor Claim 1 — real-time loop]** "Fundamental to this approach is the concept of a real-time application loop, where the application processes logic and draws its display at real-time rates (30 frames per second or more)." — `imgui.html`, "Immediate Mode applied" section.
- **[Anchor Claim 1 — radio/check/tab equivalence]** "An interesting aspect of **IMGUI** is that the classic widget types radio button, check box, and tab... are functionally equivalent from a client perspective." — `imgui.html`, "Radio buttons, check boxes, and tabs" section.
- **[Anchor Claim 1 — three-way sync burden]** "State moves from the application to the user interface... and state moves from the user interface back to the application when the user interacts with the interface." — `imgui.html`, "The woes of caching state" section.
- **[Anchor Claim 1 — callback complexity]** "This requires the application to implement 'event handlers' for any low-level interaction that is of interest, often by subclassing some toolkit baseclass." — `imgui.html`, "The woes of caching state" section.

---

### Anchor Claim 2: "Reads Are Free, Writes Are Formalized"

**Source:** `https://johno.se/book/mvc.html` — "Writing to Model state" section, second paragraph:

> "Writes to Model are formalized through the addition of IEventTarget. This is a pure virtual interface that defines all possible state changes / events on a system wide level. Controller will be passed an IEventTarget each frame, and any changes it wishes to make to Model must go through this interface."

#### The Type-Level Access Matrix

O'Donnell enforces the read/write asymmetry at the type level. The full access matrix from `mvc.html`:

> "First of all, View and Controller may only access Model in a const fashion. This has numerous repercussions. Firstly, exposing central Model state as public is ok, as it can only be read. Also, only const methods may be called, so state changes cannot be made internally as a result of a bad function call. This allows for a clear grouping of aspects of the Model into read and write categories." — `mvc.html`, "Reading Model state" section

The phrase "exposing central Model state as public is ok" is counterintuitive in the context of traditional OOP wisdom, where encapsulated state is considered sacred. O'Donnell's argument is that with const-only access, encapsulation is irrelevant for reads — anyone can read public state, but no one can modify it without going through the formal channel. The encapsulation concern shifts entirely to writes.

O'Donnell's own code structure:

> "I personally let View hold a const Model&, and have the Controller baseclass supply a View&. This way View can access model in a const way, and Controller can access View in a non-const way, and via it Model in a const way. From the top of the App this is: App owns a Model, a View and a MetaController; View has a const& to Model; MetaController has a & to View, and passes this to each IController implementation." — `mvc.html`, "Reading Model state" section

The access paths are:
```
Controller → View& → const Model& (read)
Controller → IEventTarget& → Model (write)
View → const Model& (read)
```

No component holds a non-const Model reference. This is the complete access matrix — enforced by types, not by convention.

#### Why Writes Are Formalized

O'Donnell doesn't just state the invariant; he explains the rationale:

> "Writes to Model are formalized through the addition of IEventTarget." — `mvc.html`, "Writing to Model state" section

The word "formalized" is precise: a write is not merely a memory mutation, it is a formal event with a defined signature, a defined semantics, and a defined recipient (the IEventTarget implementation). The formalization enables:
1. **Auditing:** every write is recorded in the event stream
2. **Network transparency:** writes can be routed to a remote Model transparently
3. **Re-entrancy:** writes trigger re-entrant callbacks through the same interface
4. **Verification:** the event stream can be replayed against a verification Model

#### Why a Single Interface Beats Read/Write Separation

O'Donnell explicitly argues against separating the write interface from the notification interface:

> "Experience dictates that there only be a single IEventTarget interface that is responsible for all 'system events', rather than a 'write interface' and a 'notification / read' interface (for callbacks). Most often, the exact information that causes a change is the information required to visualise that change, and in other cases this information can be derived and looked up in the Model (by Controller or View)." — `mvc.html`, "Why only a single event interface" section

The argument has two parts. First, empirical: O'Donnell tried the separate-interface approach in GC2 (with IGame/IPlayer having separate "command" and "notification" methods) and found it led to state duplication and invariant violations. Second, theoretical: the data that drives a state change is the same data needed to visualize that change, so separating the "write" channel from the "notification" channel is redundant.

#### The Ground Control 2 Lesson: State Duplication Is the Problem

O'Donnell traces the architecture to its origins in Ground Control 2's client/server model:

> "The architecture used in Ground Control 2 (which evolved into this architecture) was a plain remote proxy architecture, involving an IGame and IPlayer pair. IGame represented the 'server' (which is analogous to Model), while IPlayer represented a 'client' (which is analogous to both View and Controller, with no real clear definition in between, as well as a cache of state that can be viewed as a subset of Model)." — `mvc.html`, "Why only a single event interface" section

The problems O'Donnell encountered with the GC2 approach:

**Problem 1 — Forced conceptual leakage:** "the server/Model was forced to have an internal concept of 'players' in order for the remote cases to work, even though the concept of a 'player' had no real logical place in the context of the game."

**Problem 2 — State duplication with implicit invariants:** "there was no shared state between a 'game' and a 'player'. This implied many invariants that were difficult to maintain. For example, IPlayer::EntityCreated(id) implied that some later IPlayer method call could reference that id and have it implicitely refer to a unit that was assumed to have been created."

**Problem 3 — IPlayer cache pollution:** "Due to the fact that we had several implementations of IPlayer (Player, RemotePlayer, ScriptPlayer, and AIPlayer), the amount of duplication of similar 'stateful' concepts, such as the above mentioned 'entity' was enormous and ridiculous."

**Problem 4 — Visualization coupling:** Adding a minimap view required "invading" the internal state representations of each IPlayer implementation, because each implementation had tightly coupled caches specific to its visualization pattern.

The lesson: every cache of Model state in View or Controller is a source of bugs. The only way to eliminate the bugs is to eliminate the caches. The only way to eliminate the caches is to formalize all writes through a single interface and give all components const-only access to Model.

#### The Reads Are Free Corollary

The read path has no constraints — any component can read any part of Model at any time:

> "Exposing central Model state as public is ok, as it can only be read." — `mvc.html`, "Reading Model state" section

This is the "reads are free" corollary: because the type system prevents writes through the const reference, reads can be arbitrarily frequent and arbitrarily complex without coordination overhead. There is no locking, no subscription, no observer pattern needed for reads. The Model is a shared read-only data structure.

**Take bullets (for Tier 1 copy into Section 1 anchor claims):**

- **[Anchor Claim 2 — primary]** "Writes to Model are formalized through the addition of IEventTarget." — `mvc.html`, "Writing to Model state" section. URL: `https://johno.se/book/mvc.html`
- **[Anchor Claim 2 — type enforcement]** View holds `const Model&`, Controller holds `IEventTarget&`. Every write routes through the interface; every read is unconstrained. — `mvc.html`, "Reading Model state" section.
- **[Anchor Claim 2 — access matrix]** "View has a const& to Model... MetaController has a & to View, and passes this to each IController implementation." — `mvc.html`, "Reading Model state" section.
- **[Anchor Claim 2 — single interface rationale]** "The exact information that causes a change is the information required to visualise that change." — `mvc.html`, "Why only a single event interface" section.
- **[Anchor Claim 2 — free reads]** "Exposing central Model state as public is ok, as it can only be read." — `mvc.html`, "Reading Model state" section.
- **[Anchor Claim 2 — GC2 lesson]** Multiple IPlayer implementations each had tightly coupled caches; adding minimap required "invading" these representations. — `mvc.html`, "Why only a single event interface" section.
- **[Anchor Claim 2 — const-only access]** "Only const methods may be called, so state changes cannot be made internally as a result of a bad function call." — `mvc.html`, "Reading Model state" section.
- **[Anchor Claim 2 — event merge]** "CreateEntity() and EntityCreated() can for example be merged into CreateEntity()." — `mvc.html`, "Why only a single event interface" section.

---

### Anchor Claim 3: The IEventTarget Pattern

**Source:** `https://johno.se/book/mvc.html` — "Writing to Model state" section, opening paragraph:

> "Writes to Model are formalized through the addition of IEventTarget. This is a pure virtual interface that defines all possible state changes / events on a system wide level."

#### The Pure Virtual Interface as Event Bus

IEventTarget is a pure virtual C++ interface. O'Donnell describes it as defining "all possible state changes / events on a system wide level." The key properties:

1. **Pure virtual:** No implementation in the interface itself; all implementations (local Model, network proxy) are substitutable
2. **System-wide:** All state changes in the entire application flow through this one interface
3. **Event-based:** Each method call is both a state mutation and a notification; there is no separate notification channel

#### The Re-Entrancy Mechanism

O'Donnell extends IEventTarget beyond simple write formalization. Model itself stores an IEventTarget& for re-entrancy:

> "To do this, it is typical to have Controller/MetaController also implement IEventTarget, and extend the interface to include these 'visualisation callbacks'. App supplies a reference to IEventTarget to the Model (which is the Controller / MetaController on construction, and Model stores this reference for later callback during runtime." — `mvc.html`, "Event callbacks" section

The re-entrancy flow:
1. Controller calls `Model.IEventTarget_StartGame()` to start the game
2. Model performs the state change (sets game state to running)
3. Model calls the stored `IEventTarget&` (which is the Controller) to notify of the state change
4. Controller's IEventTarget implementation triggers visualization (plays intro sequence, etc.)

This is the closed event bus: all state changes route through IEventTarget, and IEventTarget can re-enter through the same interface. No event can escape without being formally dispatched.

#### Network Transparency

O'Donnell's original motivation for IEventTarget was network transparency:

> "The initial motivation for the IEventTarget / const Model& formalization was to completely abstract the locality of the IEventTarget implementation (i.e. remote proxy). Using this pattern, network code is completely external to the system. Controller transparently writes to some implementation of IEventTarget (either a Model or a network proxy), and both View and Controller transparently see any changes to Model that may have come from across a network." — `mvc.html`, "Remote proxies and Network abstraction" section

The key property: Controller never knows whether it is writing to a local Model or a network proxy. The IEventTarget reference is identical in both cases. This is the location-agnostic property that makes the pattern powerful.

#### Controller Isolation Across the Network

O'Donnell makes the isolation property explicit:

> "Note that this allows the 'reads are free, writes are formalized' paradigm be extended across a network. A Controller client who is talking to a remote server is completely isolated from the code that updates the local Model, and can 'read for free', but must still write via an IEventTarget. As this formalization is also useful in the local case, it is nice that all components of MVC see the world in the same way regardless of the existence of a network." — `mvc.html`, "Remote proxies and Network abstraction" section

The phrase "completely isolated" is the key: the Controller does not know whether it is talking to a local or remote Model. The isolation is achieved by the IEventTarget interface being the same in both cases.

#### The CreateEntity / EntityCreated Merge

O'Donnell shows how the IEventTarget pattern simplifies API surfaces:

> "CreateEntity() and EntityCreated() can for example be merged into CreateEntity(), and a client who calls CreateEntity() can gracefully react to a future CreateEntity() and understand it to mean that an entity has been created." — `mvc.html`, "Why only a single event interface" section

In the GC2 architecture, `CreateEntity()` was the client-side call and `EntityCreated()` was the server-side callback — two separate methods with a bidirectional dependency. In the IEventTarget architecture, there is one method: `CreateEntity()`. The caller issues the command; the callee (Model or proxy) performs the state change and the same call is re-delivered to all IEventTarget implementations (including the caller's own re-entry) as a notification. The API surface is halved; the semantics are preserved.

#### The Director Pattern for Multi-Mode Deployment

O'Donnell addresses the practical question of how to deploy the same architecture across local, listen, and dedicated server modes:

> "The Director encapsulates the details of the various modes, with when aggregated together are: Model, View, Controller; Client (the proxy to a remote Model, i.e. a 'server'); Server (the proxy to all remote Controllers, i.e. 'clients')." — `mvc.html`, "The Director" section

The Director is the top-level assembler that wires together Model, View, Client, and Server based on the deployment mode. In local mode, there is no Client or Server — Controller talks directly to Model. In listen mode, there is a Client (proxy to remote server) and a Server (proxy to remote clients). In dedicated mode, there is no local Controller — Server handles all client connections.

**Take bullets (for Tier 1 copy into Section 1 anchor claims):**

- **[Anchor Claim 3 — primary]** "Writes to Model are formalized through the addition of IEventTarget. This is a pure virtual interface that defines all possible state changes / events on a system wide level." — `mvc.html`, "Writing to Model state" section. URL: `https://johno.se/book/mvc.html`
- **[Anchor Claim 3 — re-entrancy]** Model stores `IEventTarget&`; when Model logic fires an event, it re-enters through Controller via the same interface for visualization. — `mvc.html`, "Event callbacks" section.
- **[Anchor Claim 3 — network transparency]** "Controller transparently writes to some implementation of IEventTarget (either a Model or a network proxy), and both View and Controller transparently see any changes to Model that may have come from across a network." — `mvc.html`, "Remote proxies and Network abstraction" section.
- **[Anchor Claim 3 — network isolation]** "A Controller client who is talking to a remote server is completely isolated from the code that updates the local Model, and can 'read for free', but must still write via an IEventTarget." — `mvc.html`, "Remote proxies and Network abstraction" section.
- **[Anchor Claim 3 — single interface]** "Experience dictates that there only be a single IEventTarget interface that is responsible for all 'system events'." — `mvc.html`, "Why only a single event interface" section.
- **[Anchor Claim 3 — event merge]** "CreateEntity() and EntityCreated() can for example be merged into CreateEntity()." — `mvc.html`, "Why only a single event interface" section.
- **[Anchor Claim 3 — Director pattern]** "The Director encapsulates the details of the various modes." — `mvc.html`, "The Director" section.

---

### Anchor Claim 4: View Must Not Expose Scene-Graph Abstractions

**Source:** `https://johno.se/book/mvc.html` — "View" section, fourth paragraph:

> "This also means that the popular 'scene-graph' design may not be exposed from the View. You are free to do anything you want internally when it comes to clever caching of things, but this may not be exposed to clients. For example, any type of 'instance abstraction' to represent a mesh-transform pair in the public interface is illegal. The corresponding interface should be of the form: `view::drawMesh(mesh, transform, anyOtherRenderState);`"

#### The Scene-Graph Prohibition

O'Donnell issues an explicit prohibition:

> "This also means that the popular 'scene-graph' design may not be exposed from the View." — `mvc.html`, "View" section

The scene-graph design (popularized by Ogre and similar engines) is a hierarchical object model where every mesh-transform pair is a node in a tree. The tree enables parent-child transforms, hierarchical culling, and state sorting — but it also exposes a hierarchical object model to the client (Controller). O'Donnell forbids this in View's public interface.

#### Internal Caching Is Allowed

O'Donnell explicitly permits internal caching:

> "You are free to do anything you want internally when it comes to clever caching of things, but this may not be exposed to clients." — `mvc.html`, "View" section

View may cache vertex buffers, state batches, sorted draw lists — anything — internally. But the cache is invisible to the client. The client never sees handles, nodes, instances, or any other persistent abstraction. This is the key constraint: View's internal implementation can be as complex as needed, but its public interface must be flat and procedural.

#### The Correct Interface Form

O'Donnell specifies the exact interface signature that is legal:

> "The corresponding interface should be of the form: `view::drawMesh(mesh, transform, anyOtherRenderState);`" — `mvc.html`, "View" section

This is a free function signature, not a method on a stateful object. The parameters are all the data needed to render the mesh this frame; there are no handles, no IDs, no references to previously created objects. Each call is self-contained.

#### The Procedural Interface Definition

O'Donnell defines what a non-stateful View looks like from the client's perspective:

> "What is a non-stateful view? Basically it is a procedural interface (as opposed to a collection of objects with methods), in essence very much to what DirectX 9 is." — `pitch.html`, "MVC revisited" section

DirectX 9 is O'Donnell's reference for a procedural graphics API: a collection of free functions (`DrawPrimitive()`, `SetRenderState()`, etc.) that receive all required state at call time. There are no persistent objects representing meshes, textures, or transforms — those are all handles or indices passed to the draw calls.

#### The Retained-Mode Attack

O'Donnell names the specific problem with stateful Views:

> "The main issue is that Views implicitely cache Model state (as private object members), which brings rise to sync issues. I believe that the premise that visualisation is/should be a stateful thing is false." — `pitch.html`, "However!" section

The word "implicitely" is important: the caching is not explicit in the client's mental model — it is implicit in the toolkit's design. The client creates a widget object, and the widget object implicitly caches the application state it needs to display. When the application state changes, the client must remember to push the new state to the widget object. When the widget state changes, the client must remember to pull the new state from the widget object. The implicit caching is the synchronization burden.

#### The Historical Performance Justification

O'Donnell traces why scene graphs became dominant:

> "Historically, this classic architecture was REQUIRED in order to deliver any kind of performance, i.e. heirarchical routing trees for heirarchical frustum culling, matrix transform caches, etc. The premise was to 'retain much state, and only update this state when absolutely required'." — `pitch.html`, "However!" section

The scene graph was a performance optimization for a specific hardware era: CPUs were slow, GPUs were simple, and the bus between them was the bottleneck. By retaining hierarchical state on the CPU, the renderer could avoid resubmitting geometry that was culled by the CPU-side hierarchical culling. Matrix transform caches avoided recomputing world matrices for every object.

#### GPU Advances Eliminate the Justification

O'Donnell argues the performance justification is obsolete:

> "However, due to the rapide advances in GPU based rendering over the past 10+ years, this premise no longer holds." — `pitch.html`, "However!" section

The premise was: "retain much state, only update when absolutely required." The modern GPU era: state is cheap, bandwidth to the GPU is the bottleneck, and batch rendering is more efficient than culling. The scene graph's performance justification — hierarchical CPU-side culling — is no longer the dominant factor in rendering performance.

#### Jungle Peak: Empirical Evidence

O'Donnell provides a concrete empirical result:

> "In DirectX9 is possible to render very large batches of primitives per draw call. At Jungle Peak we rendered 800 000+ vertices in a single call on nVidia GeForce 6 class hardware, with good performance. The meant a number of things, such as discarding the concept of camera culling. We simply batched together all instances of a particular mesh into a single huge vertex/index buffer pair (one per texture basically), and sent them all to the hardware with very few calls." — `pitch.html`, batch rendering section

800,000 vertices in a single draw call. If that many vertices can be submitted at once, there is no performance justification for the complex state management that scene graphs require. The CPU-side hierarchical culling that scene graphs exist to enable is not necessary when you can just batch everything and let the GPU handle it.

**Take bullets (for Tier 1 copy into Section 1 anchor claims):**

- **[Anchor Claim 4 — primary]** "The corresponding interface should be of the form: `view::drawMesh(mesh, transform, anyOtherRenderState);`" — `mvc.html`, "View" section. URL: `https://johno.se/book/mvc.html`
- **[Anchor Claim 4 — scene-graph prohibition]** "The popular 'scene-graph' design may not be exposed from the View." — `mvc.html`, "View" section.
- **[Anchor Claim 4 — procedural not object-oriented]** "What is a non-stateful view? Basically it is a procedural interface (as opposed to a collection of objects with methods), in essence very much to what DirectX 9 is." — `pitch.html`, "MVC revisited" section.
- **[Anchor Claim 4 — GPU eliminates retained-mode justification]** "However, due to the rapide advances in GPU based rendering over the past 10+ years, this premise no longer holds." — `pitch.html`, "However!" section.
- **[Anchor Claim 4 — empirical]** Jungle Peak rendered 800,000+ vertices in a single draw call on GeForce 6 hardware, eliminating the need for scene-graph culling. — `pitch.html`, batch rendering section.
- **[Anchor Claim 4 — stateless View definition]** "This part of the application is completely stateless from a client perspective (immediate mode), the client being the Controller." — `mvc.html`, "View" section.
- **[Anchor Claim 4 — internal caching allowed]** "You are free to do anything you want internally when it comes to clever caching of things, but this may not be exposed to clients." — `mvc.html`, "View" section.
- **[Anchor Claim 4 — implicit caching is the problem]** "Views implicitely cache Model state (as private object members), which brings rise to sync issues." — `pitch.html`, "However!" section.

---

## Connections: DSL Tier 4 Verbs to O'Donnell's Claims

The following mappings connect the DSL's Tier 4 verbs (sandbox, audit, intent_mapping, sandbox_execute) to the four anchor claims derived from O'Donnell's work. These are the specific hooks the Tier 1 will use when writing Section 6, Claims 9 and 10.

### Connection 1: `sandbox` verb → "Reads are free, writes are formalized" (Anchor Claim 2)

The `sandbox` verb isolates execution and enforces that all state observations by the sandboxed code are *reads* — they can occur freely against the const Model view. State mutations by sandboxed code, however, must be routed through the formal event channel. O'Donnell's architecture achieves this by giving Controller a `const Model&` and an `IEventTarget&` — reads against the former are unconstrained, writes through the latter are gated.

The DSL's `sandbox` verb maps directly to this architecture: the sandbox receives a read-only snapshot of state (the `const Model&` equivalent), and any write attempt is intercepted and routed as a formal event through the verb dispatch layer (the `IEventTarget` equivalent). This is not a policy choice added later — it is a structural invariant derived from O'Donnell's const-only Model access rule. The sandbox cannot hold a non-const reference to state because no such reference exists in the architecture.

The practical implication: sandboxed code can observe any part of the Model it has access to, as frequently as it wants, without coordination overhead. But it cannot mutate state without going through the formal channel. This is exactly the "reads are free, writes are formalized" invariant applied to the DSL's verb execution model.

The parallel extends to the access matrix. In O'Donnell's architecture:
```
Controller → View& → const Model& (read)
Controller → IEventTarget& → Model (write)
View → const Model& (read)
```

In the DSL's sandbox:
```
sandboxed code → read-only state snapshot (read, free)
sandboxed code → formal event channel → verb dispatch (write, formalized)
```

The structure is identical: one read path (unconstrained), one write path (formalized). The DSL's sandbox is the Controller role; the state snapshot is the `const Model&`; the event channel is the `IEventTarget`.

**Section 6 Claim 9 hook (Tier 1):** "The sandbox verb enforces 'reads are free' by providing a const snapshot as the only state handle; all writes are forced through the formal event channel, directly mirroring O'Donnell's `const Model&` / `IEventTarget` split (source: `mvc.html`, 'Reading Model state' and 'Writing to Model state' sections)."

### Connection 2: `audit` verb → IEventTarget pattern (Anchor Claim 3)

The `audit` verb records every formal state-change event for later replay and verification. O'Donnell's `IEventTarget` is itself an event log: it is the single interface through which all writes flow, and both local Model and remote proxies implement it identically. A Controller writing to a remote Model uses the same `IEventTarget` call it would use for a local Model — the interface is location-agnostic.

O'Donnell explicitly notes that this allows Controller to be completely isolated from the code that updates Model:

> "Controller transparently writes to some implementation of IEventTarget (either a Model or a network proxy), and both View and Controller transparently see any changes to Model that may have come from across a network." — `mvc.html`, "Remote proxies and Network abstraction"

The `audit` verb is the DSL's implementation of this same pattern: it wraps the verb dispatch interface, records every call (the event), and replays it against a verification Model. No write can bypass the audit because no write can bypass the interface. The audit log is a first-class artifact — it is the `IEventTarget` trace, equivalent to the network proxy's event stream in O'Donnell's architecture.

The `audit` verb also inherits O'Donnell's re-entrancy mechanism: when Model logic fires an event that re-enters through the Controller, the audit log captures both the initial write and the re-entrant callback as separate events in the same trace. This enables complete replay: running the audit log against a fresh Model reproduces the exact sequence of state changes that occurred in the original execution.

Furthermore, O'Donnell's principle that "the client is in no way dependent on ANY IEventTarget callbacks in order to operate correctly" maps to the DSL's guarantee that the audit log is for observability, not for correctness: the sandboxed code's behavior is determined by the Model state, not by whether the audit verb is present.

**Section 6 Claim 10 hook (Tier 1):** "The audit verb is the DSL's `IEventTarget`: a single interface that all state mutations must route through, enabling complete replay and verification — exactly as O'Donnell describes in `mvc.html`, 'Remote proxies and Network abstraction' and 'Event callbacks' sections. The audit log is the event trace; the verification Model is the replay target."

### Connection 3: `intent_mapping` verb → Controller-per-frame procedural composition (Anchor Claims 1 + 4)

O'Donnell's Controller is not a callback handler, not a state machine, and not a retained-mode widget host. It is a per-frame procedural composer of View. From `pitch.html`, "MVC revisited" section:

> "Controller has 2 jobs: (1) doInput(): react to used input and direct how that input is allowed to change Model state; (2) doOutput(): dynamically, in real time, compose the current 'view' of the application using View."

This is the key architectural move: Controller *programs* View each frame, procedurally, with no retained state between frames. The "view" that appears on screen is the result of the Controller's per-frame composition — not a cached state that persists across frames. If the Controller changes its strategy mid-session (e.g., switching from play mode to edit mode), the entire View changes immediately because View has no retained state to clean up before restarting.

The `intent_mapping` verb does exactly this at the DSL level: it takes a high-level intent description (e.g., "refactor this function to use early return") and procedurally composes a sequence of lower-level verb calls (sandbox, audit, edit operations), frame by frame, without retaining any intermediate widget state. The result of one frame's composition becomes the input to the next frame's composition — exactly O'Donnell's "dynamic, procedural" Controller.

The flat, stateless execution context required by `sandbox` and `sandbox_execute` is the same constraint O'Donnell imposes on View: no scene-graph abstractions, no persistent handles, only the current call frame's arguments. The `intent_mapping` verb's output is a sequence of flat verb calls, not a hierarchical object graph. Each call is self-contained: it receives all context at call time, executes, and returns. There are no handles to intermediate results that persist between calls.

**Section 6 Claim 9/10 cross-hook (Tier 1):** "The `intent_mapping` verb is the DSL's Controller: per-frame procedural composition of verb calls, with no retained state between frames, directly inheriting O'Donnell's Controller role from `pitch.html`, 'MVC revisited' section, and the flat procedural View constraint from `mvc.html`, 'View' section."

### Connection 4: `sandbox_execute` verb → Deferred display / frame-shearing awareness (Anchor Claims 1 + 4)

O'Donnell discusses a subtle but important phenomenon called "frame shearing" (`imgui.html`, "Frame shearing" section):

> "One aspect of IMGUI to be aware of in the context of real-time applications (constantly rendering new frames many times per second) is that user interactions will always be in response to something that was drawn on a previous frame... There is a chance that the result of any given widget interaction changes some application state that controls the appearance of the user interface itself, and such discrepancies can result in parts of the user interface reflecting the 'old' state while some reflect the 'new' state. I call this 'frame shearing', in that the displayed image represents parts of two different logical images at once."

The solution O'Donnell proposes is a "shearing exception" — when interaction changes application state that controls UI appearance, the GUI generation restarts for the current frame:

> "The main technique to utilize is to have any code that changes the appearance of the user interface generate a 'shearing exception' which breaks out of the method that generates the gui for the current frame and restarts the entire process for the current frame. Theoretically a 'shearing exception' must be thrown for each interaction that could change the appearance of the user interface, but in practice this usually only happens once per frame (i.e. the gui is at most generated in full more than once but less than twice)." — `imgui.html`, "Frame shearing" section

The `sandbox_execute` verb's frame-bound execution model maps to this: each execution frame is isolated, and the verb dispatch layer can detect when a state change invalidates the current composition and restart. The sandbox does not retain state between frames, so there is no stale state to clean up before restarting — exactly the "shearing exception" mechanism. The restart is clean because the execution context is stateless by construction.

This also maps to O'Donnell's "immediate mode" principle from `imgui.html`: the real-time application loop redraws at 30+ fps, and each frame's GUI is generated from scratch. The DSL's `sandbox_execute` verb similarly generates each execution frame from scratch, with no retained state between frames.

**Section 6 Claim 9/10 extended hook (Tier 1):** "The `sandbox_execute` verb's frame-isolated execution model maps to O'Donnell's 'shearing exception' mechanism (`imgui.html`, 'Frame shearing' section): each frame's composition can be restarted without stale state cleanup because the execution context is stateless by construction."

---

## Summary of Anchor Claims

| # | Anchor Claim | Source | Key Quote |
|---|-------------|--------|-----------|
| 1 | Widgets are method invocations, not objects | `imgui.html` — "Immediate Mode applied" | "Widgets, logically, change from being objects to being method invocations." |
| 2 | Reads are free, writes are formalized | `mvc.html` — "Writing to Model state" | "Writes to Model are formalized through the addition of IEventTarget." |
| 3 | IEventTarget is the single event interface for all state changes | `mvc.html` — "Writing to Model state" + "Event callbacks" | "Experience dictates that there only be a single IEventTarget interface that is responsible for all 'system events'." |
| 4 | View must not expose scene-graph abstractions | `mvc.html` — "View" section | "The corresponding interface should be of the form: `view::drawMesh(mesh, transform, anyOtherRenderState);`" |

---

## Source URLs

| Page | URL | Key Claims |
|------|-----|-----------|
| IMGUI essay | `https://johno.se/book/imgui.html` | Widgets as method invocations; state-copy problem; deferred display; frame shearing; complete C++ Gui class code |
| The Pitch | `https://johno.se/book/pitch.html` | Broken paradigm; GPU advances eliminate retained-mode justification; Controller as per-frame procedural composer; Jungle Peak 800K vertex single-draw-call |
| IM-MVC roadmap | `https://johno.se/book/immvc.html` | Book structure; IEventTarget centrality; experience progression from GC to MVC/E; single interface rationale |
| MVC chapter | `https://johno.se/book/mvc.html` | Reads free/writes formalized; IEventTarget pattern; re-entrancy; network transparency; scene-graph prohibition; Director pattern; GC2 lessons |
