The Invariant: One Model, Several Projections

Pascal Editor's graph, core store, rendering flow, spatial rules, and viewer/editor split now support one practical judgment: a scene is trustworthy only when each boundary preserves the meaning it owns. This checkpoint connects those ideas so the reader can test a feature or client against Pascal's model instead of judging it from a screenshot or a successful API response. The question is not whether every consumer looks identical; it is whether they remain faithful to the same semantic building data.

Consider the wall with a door again. In the graph, the wall belongs to a level and the door belongs to the wall. In the store, an edit becomes document state and history. In the browser, the registry and geometry systems turn that state into meshes and openings. In a plan view, the same relationships become lines, handles, and dimensions. In a query, they become a report about hosts, lengths, and bounds. These outputs can differ in form without being different models.

The invariant is a chain of ownership

The most useful invariant is simple to state: one semantic scene graph remains authoritative while different consumers derive their own representations from it. The graph owns the identity and relationships of the building. The core store owns the current document state and its history. Rendering systems own disposable visual projections. The viewer owns presentation state. The editor owns interaction tools. MCP owns a protocol boundary for reading and changing the graph, not a second architecture hidden behind it.

This division explains why a flat node map can serve both a direct manipulation tool and an agent. Both can locate a wall by identity. Both can follow its relationship to a level and its hosted door. Both can ask the relevant layer to perform a mutation. The browser may immediately show a new mesh, while a headless process may only hold the changed nodes and a pending dirty set. Their runtime states differ, but they are still talking about the same wall.

The invariant is not “all projections are always synchronized.” A projection can be unavailable, stale, or intentionally simpler. A browser renderer may not have mounted yet. A headless MCP process has no renderer. A floor plan presents two-dimensional geometry rather than the full Three.js scene. What must remain stable is the meaning crossing the boundary: IDs, ownership, units, host frames, and authored-versus-derived distinctions.

This is a stronger and more useful standard than visual sameness. If two consumers draw slightly different labels but agree on which level owns a wall, they may still share a model. If they draw the same wall but one treats a wall-local door position as a world coordinate, they do not. A polished picture can hide a broken relationship; the invariant makes the relationship inspectable.

flowchart LR I["Authored building intent"] --> G["Validated semantic graph"] G --> S["Core state and history"] S --> D["Invalidation and dependency context"] D --> V["Derived geometry and floor plan"] G --> H["Human editor and viewer"] G --> A["Agent and MCP consumer"] G --> C["Spatial and semantic checks"] V --> H C --> J["Judgment with stated scope"]

The diagram shows why the graph sits before, not after, the viewer. Human and agent consumers may enter through different interfaces, but both must meet the same data contract. The state and invalidation path explains how a committed change reaches a projection.