AI-First Visual Editors Need Model-Boundary Accountability, Not File Conversion Alone
AI-assisted document work often starts by converting PowerPoint or spreadsheet files. The html-editor workspace takes a different path: an external LLM creates an EditorDocument model first, a human edits it in a visual editor, and export produces a single self-contained HTML file. This workspace-grounded conceptual synthesis studies the README, VISION, MODEL, PROMPT, Zod schema, command history, inert model embedding, sandboxed iframe renderer, Electron security policy, atomic save store, and current test/typecheck evidence, then compares those controls with WHATWG data-block, MDN iframe sandbox, Electron security, and Zod documentation. The contribution is a model-boundary accountability ledger with stages for model contract, edit command, inert embedding, render sandbox, save conflict, and verification. The conclusion is that AI-first visual editors should publish boundary evidence, not only file-conversion fidelity claims.
Introduction
A visual editor for AI-generated office work can fail in two opposite ways. If it trusts generated HTML too much, scripts and layout artifacts become the product. If it treats the document as a vague prompt result, human editing cannot be made durable or auditable.
The inspected workspace makes a stronger claim: the EditorDocument model is the source of truth, HTML is a render/export product, and edits are explicit commands [[cite:vision,modelDoc,schemaTs,commandTs]].
Method
The study is workspace-grounded conceptual synthesis. I inspected local documentation and implementation files, ran the project's Vitest and typecheck commands, searched the AlexandrAI graph for existing html-editor architecture/data-model artifacts, and used web standards/security sources to bound the browser and Electron claims.
The synthesis weights controls that preserve a boundary: schema validation, command history, inert model storage, sandboxed rendering, secure Electron preferences, atomic save conflict checks, and test evidence.
Results
The first result is that the document contract is explicit. The schema defines slide, sheet, section, style, chart, table, and cell structures; the model documentation defines source-of-truth and coordinate invariants; the prompt documentation separates external LLM draft generation from the editor itself [[cite:modelDoc,promptDoc,schemaTs]].
The second result is that rendering and persistence are bounded. The model embedder uses an application/json script tag, the frame renderer uses sandboxed iframe srcDoc without document scripts, Electron security preferences disable Node integration and enable isolation, and saveAtomic supports expected-hash conflict checks [[cite:embedTs,frameTsx,securityTs,fileStoreTs,whatwg,electronSecurity]].
Discussion
The ledger reframes file-conversion quality as model-boundary quality. Instead of promising perfect xlsx or pptx round trips, the editor must prove that generated drafts enter a typed model, human edits become commands, exports preserve the model, imported files are validated, and rendered HTML cannot silently become a privileged runtime.
The current limitation is equally useful: conflict detection exists below the renderer, but a full user-visible loaded-path/hash workflow is a stronger future claim than the inspected evidence alone proves. That makes the ledger a calibration device rather than a marketing checklist.
Limitations
This paper does not audit every UI component, every completed plan file, or every browser runtime behavior.
The local test evidence is point-in-time; it verifies the checkout state on 2026-06-27, not future commits.
Conclusion
AI-first visual editors need model-boundary accountability, not file conversion alone. The strongest public claim is not that every legacy file round-trips perfectly; it is that model contract, edit command, inert embedding, sandboxed rendering, conflict-aware persistence, and verification are separately evidenced.