What Pascal's Architecture Enables—and Where It Stops

Pascal Editor asks a practical architectural question: can one building model serve human editing, read-only viewing, third-party extensions, AI-agent operations, and local project management without losing the meaning of the building? The answer supported by the repository is yes, within carefully defined boundaries. This final chapter connects the graph, rendering, plugin, MCP, persistence, and CLI designs into a decision-ready judgment: use Pascal when shared semantic data is the problem, and add another renderer, merge system, measurement process, or human review when the requested assurance lies outside that data.

The distinction is easiest to see in the running example. A person or agent wants a small home with two rooms, a door, a window, furniture, and a roof. Pascal can represent those things as related nodes, turn them into browser projections, expose semantic operations, preserve local edits, and report several kinds of checks. The architecture is valuable because the same wall remains a wall as it crosses those boundaries. It is limited because no one boundary answers every question about that wall.

The enabling chain is the product

The scene graph is the center of Pascal's usefulness because it gives each surrounding surface something stable to consume. Schemas define what a node means and how it survives version changes. The core store owns document state, history, and invalidation. The viewer turns semantic nodes into a visual projection without taking ownership of editor-specific behavior. Plugins add new semantic kinds through the same registry contract. MCP gives an agent a protocol path to inspect and change the graph. Storage and the CLI give the graph a local lifecycle.

These are not independent features placed next to one another. Each one makes the next possible. A schema-defined wall can be created by a browser tool or an agent. Because the wall has an identity and a host level, a renderer can find it, a floor plan can draw it, and a verifier can ask whether its door remains within its bounds. Because the agent operates on the same graph, a person can open the result rather than reconstructing it from an AI-specific export. Because the scene has a durable storage boundary, the browser and MCP service can share a project without treating a process-local object as the project itself.

The graph-centered design also makes extensions cumulative. A new node kind can declare its schema, capabilities, relationships, geometry, floor-plan behavior, interaction tools, and MCP description. If those declarations use the host's context and ownership rules, the new kind can participate in generic selection, rendering, support resolution, and agent workflows. The host does not need a new branch for every possible object. This is not unlimited modularity: the plugin must still respect the public contract, and the host retains responsibility for project installation, application panels, routes, and durable configuration.

The same reasoning explains why Pascal keeps the viewer separate from the editor. A read-only viewer is not a crippled editor; it is a consumer with a narrower responsibility. An embedded application can mount a 3D canvas or a synchronized 2D view without importing private tool state. The full editor can inject selection, snapping, and manipulation systems where they belong. The graph provides shared meaning, while the surface chooses how much interaction to expose.

What the repository can guarantee

Pascal's guarantees become clearer when they are stated as layers rather than as one broad promise.

Schema validity is the first layer. Zod parsing checks node shape, applies permitted defaults, and generates proper identifiers for new objects. Load-time migrations preserve older scenes when fields or structures change. The bridge can reject malformed graph imports and the scene validator can report node, path, and message errors. This is a meaningful guarantee about data shape and compatibility, not about whether the building is well designed.

Mutation integrity is the next layer. The MCP patch path simulates creates, updates, and deletes before applying them. It checks schema validity and references, permits later operations to use earlier-created IDs, and can group a coherent phase into one undoable step. This gives an agent a safer way to make a batch change than sending a sequence of unrelated low-level writes. The scope remains the in-memory mutation boundary. A patch can be accepted without a browser renderer being present or a durable save having completed.

Layout evidence adds domain checks. Higher-level scene verification can identify missing or empty story content, inappropriate mixing of roof and occupied-story content, openings outside walls, stair problems, and certain suspicious wall-height patterns.