Workbook Surfaces

Surfaces are workbook tabs that turn model data into a purpose-built interface. A sheet is the most familiar surface: it shows cells. Other surfaces show the same model as a table, map, chart, board, document, app, or custom React view.

The interface-layers development preview also presents these same surfaces in App, with routes to their source in Code and their values in Data. A layer selects how you work with a model; a surface selects a view of its data. Documents and notebooks retain their own editing and execution capabilities. The interface layers guide describes this candidate experience and its current limits.

The Pro Research Workspace is deliberately different: it is one top-level, model-scoped workspace with five research workflows, not another persisted workbook surface tab. Experiments, Molecule, and Document surfaces can open it with bounded context, while the workspace retains one shared model research state. See Research Workspace.

Why Surfaces Exist

Models often need more than a grid. A sales pipeline may want an Airtable-like table and a Monday-style board. A location model may want a map. A forecast may want charts, controls, and a polished dashboard for people who should not have to inspect every formula.

Surfaces let those interfaces live inside the model instead of beside it. The spreadsheet remains the source of truth for formulas, inputs, and calculations; surfaces give that same state a richer user experience.

The UI Model

A workbook has a tab strip. Some tabs are sheets, and some tabs are surfaces. Both are backed by model state.

For a sheet, the tab name is a namespace and the visible items are cell addresses:

Sheet1!A1 = 100
Sheet1!B1 = A1 * 1.2

For a surface, the tab name is also a namespace, but the visible items are named slots:

Map_1!type = "map"
 
Map_1!config = <toml>
  version = 1
  kind = "map"
  title = "Stores"
</toml>
 
Map_1!data = ""

The important slots are:

New configurations use explicit language blocks. The standard templates use <toml>…</toml>; <yaml>…</yaml> and <json>…</json> can express the same configuration object. For example, the Map configuration above can also be written as:

Map_1!config = <yaml>
  version: 1
  kind: map
  title: Stores
</yaml>

The language tag identifies the data format. The surface still checks the configuration fields against its own schema. New persisted document seeds use <json>, and authored Component source uses <jsx>. Ordinary labels and empty optional slots remain strings.

Saving a configuration retains its TOML, YAML, or JSON encoding. YAML setting edits preserve comments on unchanged content; renaming and duplicating a surface retain the block format. Older models with plain TOML strings continue to work and use typed TOML on their next configuration save.

For embedded code, <jsx> and <html> preserve source verbatim. JSX braces retain their JavaScript meaning. Quoted markup can instead interpolate Grid expressions, so the formatter keeps that spelling when interpolation is used. See the literal reference for delimiter rules and the distinction between source text and DOM values.

The UI reads those slots and chooses the matching renderer. A surface can be native, custom, or ejected:

This is the foundation for Grid's application layer. Built-in surfaces provide familiar app-like views over model data. Custom surfaces use the same tab, binding, and persistence model, so a workbook can grow from spreadsheet to application without moving state into a separate front-end project.

Sharing editing behavior

Custom React can reuse an owning tool's editing capabilities. In a Component or ejected View source program, ui.useSurfaceHistory() returns the enclosing editor's Undo/Redo service; ui.useSurfaceActions() returns its declared action service; ui.useSurfaceForm() returns its existing Form draft service. The View element namespace const G = ui.view exposes the same hooks as G.useHistory(), G.useActions() and G.useForm().

ui.useSurfaceActionState(name) and G.useActionState(name) observe a declared action's status and message from the same execution engine. A requesting control updates when that outcome changes; surrounding layout does not need another state store. The result is null without an admitted outcome service, for an undeclared name, or in a disabled scope. The optional attemptId identifies that action attempt across Form rebinding. It changes for a later click, even when the failure message is identical. An author-selected recovery guard can use it as a checkpoint and acknowledge one failed effect without authorizing departure after a later failure. It adds no persistence or retry; absent IDs must not authorize acknowledgement. See examples/canonical/surface-navigation-controls.jsx.

Put these hooks in a child React component rendered inside the View tree. Page and root factories run before that View's services are installed. A standalone Component returns null for capabilities whose owner is absent.

Stage values in model units. The field's current declared type remains authoritative at Check and Submit; an optional typeTag hint cannot override it. Explicit reapply retains the proposed value and refreshes its source revision. Submission validates it against the current host before saving.

form.read(symbol) returns the same plain JavaScript presentation used by inline JSX. Published records and arrays reuse the existing decoded-value cache; repeated reads retain identity until a new published value arrives. A staged proposal is returned directly, so custom and inline controls observe the same draft. Discard returns to the current published presentation. Scalar values retain their existing behavior; this adapter adds no model evaluation.

A custom Form control can use form.canStage?.(symbol) to query the same current write permission that protects built-in fields and form.stage. The query is false while that Form is saving, after its owner retires, or when the host refuses that symbol. A model write restriction can still permit a declared View local. form.state.enabled describes owner availability, so it alone does not establish field permission. The query is optional for other Form providers; absence means permission is unknown. The canonical quantity control disables field editing when that query is absent or false. Staging, validation and the native commit remain authoritative even after a positive query.

For a custom component's own local draft, ui.useSurfaceNavigationGuard({ dirty, canLeave }) and G.useNavigationGuard(...) use the existing owner’s navigation protection. The hook returns true when that host offers registration. Return false from canLeave until the user explicitly saves or discards work that must remain open. A View’s page navigation and registered host transitions then honor that refusal. The hook creates no storage or recovery; shared Form drafts already have their own guard. Print offers no registration.

An owner that permits leaving after a host discard prompt can also supply confirmLeave: confirm => dirty ? confirm() : Promise.resolve(true). The callback must leave the draft intact: approval is only a decision, and the actual transition may still fail. A host prompt never substitutes for another owner’s refusal. Published View controls check local owners before requesting another destination or Back, then leave the final discard decision to the host. Host-initiated layer changes, outer navigation and closure still use the sandbox’s dirty-state mirror; the same child-refusal guarantee is not yet available for those transitions. See the reusable local draft example.

When an asynchronous host close decision includes a packaged frame, its dirty mirror shares the host's discard question. A changed dirty report or frame load cancels that pending approval; loading does not clear protection. This does not let the host observe a child's private refusal or draft changes that keep its dirty flag unchanged.

function UndoControls() {
  const history = ui.useSurfaceHistory();
  const [failure, setFailure] = React.useState("");
  const run = async action => {
    if (!history || history.state.busy) return;
    setFailure("");
    try { await history[action](); }
    catch (error) { setFailure(error.message || "History could not complete."); }
  };
 
  return <>
    <button disabled={!history?.state.canUndo || history.state.busy}
      onClick={() => void run("undo")}>Undo</button>
    <button disabled={!history?.state.canRedo || history.state.busy}
      onClick={() => void run("redo")}>Redo</button>
    <p role="status">{failure}</p>
  </>;
}

Within a View, built-in surface events, declared JSX callbacks and custom React action controls use the same checked action execution and acknowledged undo history. actions.has("save") checks whether that name is declared; actions.run("save", payload) invokes it asynchronously. Handle a rejected promise in the custom control. Host permissions and action conditions still apply, and arbitrary model writes do not gain automatic action Undo.

An action result describes the last admitted arrow. Guards or declined confirmation keep that result. Handle the invocation's rejected promise too; the result can later report a failure of effects after model state committed. During Form submission, form.state.submitting covers the earlier input-save stage. A shared arrow's done result alone does not mean a Form was saved. An arrow that only navigates stays running until navigation finishes and reports rejected when the owner refuses it. A saved model or local change keeps its successful result if later navigation fails, with a follow-up notice. Neither result reverses a separate input save or an earlier viewer side effect.

Inside a View Form, custom controls can use form.read(symbol) and form.stage(symbol, value) to share the same draft as standard controls. form.error(symbol, controlId?), form.setError(controlId, message?) and form.state.failure expose validation; form.conflict(symbol), form.reapply(symbol) and form.discard() support explicit conflict recovery. form.check() uses the host's existing input validation when available. Declare targets in the Form tree and View binding contract. A staged edit does not change the model until submission.

actions.submit?.("save", payload) is available when the admitted action port shares that Form's owner. It follows the same draft validation, input commit and action path as a standard Submit button. actions.run() continues to run an event without saving the Form. Custom controls should observe the service's enabled/busy state and handle rejected submissions. The input batch and action remain separate commits: action Undo reverses its declared targets, rather than automatically reversing all saved Form fields.

History commands can complete asynchronously or reject; custom controls should await them and display failure, as in the example above.

Code Builder's source Undo/Redo controls use this same contract over the retained Monaco editor. They follow its current history and become unavailable while saving, read-only or without a source writer. Changing between Code and Builder retains the source editor's history. A running View retains its separate action history; this sharing creates no global stack or new persistence.

Sheet model editing also exposes its existing history through the shared owner contract. Header commands follow the selected Sheet or nested editor; formula text and source keep their own editing history. Cell editing and inactive panes retain their current restrictions. Resetting a model's edit history retires callbacks from the preceding editing session. These adapters preserve each tool's stack and do not add cross-editor transactions or durable recovery.

App design and Document editing expose their existing specialized histories through the same optional history contract. The focused nested editor owns Undo; separate editors retain separate stacks. Print disables interaction, and App Run/Preview does not expose App design history. Independently hosted Views and Apps clear inherited Form services and action authority.

Closing a desktop window also consults its in-process surface guards. An editor that requires Save, Discard or recovery can keep the window open before the native close question appears. Cooperating drafts, Live source and a private scenario share one question. Approval keeps drafts intact and applies only to the checked editing session; changed protected work cancels a stale close retry. Packaged iframe children still expose only their existing dirty-state mirror to an outer close. This adapter adds no durable recovery for local drafts.

For in-process Grid Views, changing a staged Form or table proposal cancels a pending departure approval, including when that View has accepted and another surface is still deciding. The proposals remain available; a fresh departure request checks the current work again. Nested components keep their existing owner protection through the containing View.

Code Builder source edits share one history across the source toolbar, focused workspace header and keyboard Undo/Redo. Builder retains the mounted source editor while presenting its visual tools. Text fields and nested editors keep their own commands; saving or read-only source editing disables the source history. Running View actions retain their separate history. Grid Views and Builder share visible-owner keyboard routing. Hidden or inert content cannot redirect its keys to a visible parent. A printed/read-only View blocks the enclosing editor's keyboard and header history; normal View action history remains available when returning to its editable run presentation.

Custom React navigation guards can supply checkpoint with their local draft identity or revision. This lets an isolated published View report another edit while it remains dirty, so the host cancels a pending departure decision. Checkpoint values stay local; the connector sends only dirty state and a counter. Selected checkpoint protection requires an exact host receipt tied to the loaded frame. Reload invalidates old reports and approvals; mounted owners re-report protection without clearing their drafts. Built-in and exported connectors share this lifetime behavior. Once a shell accepts framed protection, dirty reports must keep that contract across reloads; a boolean-only update receives an explicit refusal. Legacy-only shells retain their existing reporting behavior. An explicit shell replacement starts a new admission. It does not yet carry private child vetoes into host-initiated navigation.

Grid Apps

Grid Apps are the application layer that sits on top of the reactive spreadsheet model. The model remains the state/program; App Mode is the end-user runtime; Dev Mode is the workbench for inspecting and changing the model behind it.

Surfaces can run in two product contexts:

In the interface-layers candidate, the existing workbench is named Data, Code groups source and surface authoring, and Chat expands the agent conversation. App remains the model's presentation. The old gridMode=dev URL and model.enterDevMode() bridge action continue to return to Data. This terminology change does not replace surface identities or change their model bindings.

App Mode is not a separate model format. The spreadsheet model remains the reactive state engine, while the active Surface or packaged model UI is the presentation layer. A promoted Surface can become an app entry point, navigate to sibling surfaces, and push browser history so Back/Forward behaves like app navigation. A model can also carry a portable ui/ package inside its .gridoc; when present, Grid can render that package as the model-owned app entry instead of the workbench. Packaged apps may declare a homePath in ui/manifest.json so the model's default App Mode launch opens a logical app route such as dist/dashboard while the physical HTML entry document remains dist/index.html. Explicit deep links still use ?gridMode=app&appPath=<path> and win over the declared home route. They may also declare an app block in the same manifest: app name, short name, description, package-relative icon, safe theme hints, and shell chrome. That is the piece that lets a model opened from the Models page behave like a custom application. Generated App Builder packages publish frameless app chrome by default, with a small floating Dev Mode affordance and the keyboard escape chord preserving the path back to the workbench. Generated App Builder packages also write dist/app-meta.json, a package-local metadata sidecar that describes the app as an app: pages, home route, declared model reads and writes, requested connector capabilities, component families, layout primitives, conditions, commands, row-scope usage, and higher-level features such as navigation, responsive layout, record views, filters, charts, feedback, model writes, and the app-framework readiness state. It also records detected app patterns such as routed app, dashboard, records workflow, input workflow, or static screen. The sidecar is not the launch manifest; it is the inspection contract that lets Builder tools, custom UI tooling, audits, and future app catalogs understand the UI framework sitting on top of the reactive model without parsing generated JavaScript. They also include dist/GRID_APP.md, a short package-local handoff guide for authors replacing or extending the generated UI. It lists the app home, pages, read/write model contract, features, connector module, and state helper in the same ui/ package that Grid serves. Its starter snippet is generated from the app's declared reads and writes, so custom UI starts from the actual model contract rather than a blank template. Generated packages also include a custom-ui/ handoff project. Its custom-ui/manifest.json declares the custom project contract, custom-ui/README.md explains the replacement flow, custom-ui/index.html is the replacement entry path, custom-ui/main.jsx is a React entry over the generated React adapter, custom-ui/vue-main.js is a Vue entry over the generated Vue adapter, and custom-ui/grid-app.d.ts re-exports generated app-specific symbol/type helpers. The default app still launches from dist/index.html; the custom project is the explicit handoff folder for replacing or building over that generated entry. Generated packages also include dist/custom-app-starter.js, a runnable plain-JavaScript starter over dist/grid-app.js and the app's declared symbols. It is not the default entry; it is a concrete replacement starting point for authors who want to take over app.js. They also include the stable framework interface modules dist/grid-app.js, dist/grid-react.js, and dist/grid-vue.js, with matching declaration files. grid-app.js exports the generated app contract, symbol constants, write guards, and action helpers such as setAppValue, setAppBatch, appendAppRow, routeApp, runAppJob, and callAppConnector. grid-react.js exports a React useGridApp hook over that contract; grid-vue.js exports the Vue useGridApp composable. The dist/custom-react-starter.jsx and dist/custom-vue-composable.js files are now examples that consume those adapters rather than being the interface custom code has to copy. Generated packages also emit dist/grid-connector.js, an ES module exporting the same grid connector object used by the generated app renderer, plus dist/grid-connector.d.ts with the connector's TypeScript shape. Custom React, Vue, or hand-written UI inside ui/ can import that module instead of re-implementing the grid:model-ui:v1 postMessage protocol, so generated and custom apps sit on the same typed reactive model connector. The module also exports createGridStore(symbols), a framework-neutral reactive store over grid.subscribe. React can adapt it through useSyncExternalStore, Vue can subscribe to it from a composable, and plain JavaScript can listen directly, while all state still lives in the spreadsheet model. For app code that wants fewer moving parts, createGridState(symbols) wraps that store with value, rows, set, setBatch, appendRow, setFormula, location, onLocation, route, runJob, callConnector, dev-mode escape, and lifecycle helpers. The generated App renderer uses that same app-state helper internally, so the visual Builder path and fully custom UI path share the same reactive state adapter, including optimistic local updates for set, setBatch, and appendRow. Generated and starter apps also handle Shift/Cmd/Ctrl+Escape inside the app frame by calling model.enterDevMode(), so takeover UI retains a predictable return path even when keyboard focus is inside custom UI.

When a model has both a packaged ui/ app and a promoted Surface entry, the packaged app is the default model-owned app entry. Explicit Surface URLs still win: ?gridMode=app&surface=Table_1 opens that Surface takeover even when the model also has ui/. If an explicit Surface target is missing, Grid falls back to Dev Mode rather than silently opening the packaged app.

The workbench is always recoverable. Older app shells expose a Dev mode control; the interface-layers candidate exposes Data in its layer selector. Explicit URLs can force ?gridMode=dev, and the escape chord Shift+Esc / Cmd+Esc / Ctrl+Esc returns the user to the workbench. For packaged custom UI, Grid injects the iframe-side escape listener when serving HTML so the shortcut still works even if focus is inside arbitrary app code.

Built-In Surfaces

Built-in surfaces are ready-made interfaces for common model workflows. They are designed for direct manipulation: filter a table, edit a board card, inspect a map layer, shape a dataset, or arrange a dashboard without leaving the workbook.

Current built-in surface families include:

These are the surfaces to reach for when the model fits a familiar product shape: tables, boards, dashboards, documents, maps, calendars, and charts.

Predict

The Predict surface owns the lifecycle of a model-backed prediction workflow. It lets a user choose a learner, pick feature data from a range or file, train or register a model artifact, and expose a callable prediction function back to the workbook.

Use it when a spreadsheet model needs a prediction step but the user should not manage training files and function wiring by hand. The surface keeps the model name, learner family, feature source, target column, deployment status, exposed function name, and last metrics together in one tab.

Training requires finite numeric features; missing or categorical feature values must be prepared explicitly. K-Means and PCA use every selected feature column and do not remove a target. A truncated file preview cannot start training: the selected native Dataset/Train development path captures complete input. The quick, balanced and thorough budget profiles default to 10, 60 and 300 seconds; host limits may lower them. The selected Train view reads and shows the resolved host limits.

The development suite separates Train, inference-focused Predict, Evaluate and Process. Those new execution paths are not yet available in the standard build; existing Predict workbooks retain their training interpretation and authored JSX. The explicitly selected development suite has retained-data prediction, snapshot training, mapped few-shot prompt adaptation and case evaluation. It retains row membership, reports known training overlap, and supports bounded pure Grid checks against output_value and case_data. Prompt adaptation does not change model weights. The development Process surface uses the same compiled-plan owner and model/human controls as Agent → Tasks → Processes. Opening the surface performs no execution. Source editing remains in Code; Run and Print expose observation only. Compiler-backed visual editing and saved native Process evaluation use this canonical owner. Bundled AI workflow adapters are a selected native preview; fresh Process-case execution remains unfinished; the retired prototype is not an execution fallback. Ordinary saved-result evaluation makes no model calls; fresh inference evaluation supports explicitly selected rubric judges and retained manual ratings. Retained output publication uses the receipt-backed native input owner when that capability is selected. The balanced V2 release and full native/UI and Performance evidence remain unfinished.

Retained AI publication now uses typed native Frames and exact readback before binding. The selected native Document journey verifies all three structured extraction outputs without converting them to JSON text. Native contracts also verify lists, nulls, exact integer extremes and refusal of lossy representations. Existing published Frames are not rewritten. General formula operations on complex Frame columns and the complete suite's durability and Performance evidence remain unfinished.

The development App saves AI run, attempt and plan references through an explicit native durability acknowledgement. It waits for confirmation before starting work. If the save result is uncertain, reopen the workbook to inspect its saved selection before continuing. This source change still requires native failure and crash verification; it does not change the general configuration/embed save contract. Legacy Predict keeps its existing interpretation.

Predict, Train and Evaluate now wait for confirmed setup saves on App hosts that support them. A matching workbook update alone does not enable Run while the save is still pending. Newer edits and keyboard focus remain in place; use Retry save after the current save completes to save those newer fields. An uncertain reply retains the fields and keeps Run and further saves blocked until the workbook is reopened for inspection. Training also waits for the current saved configuration to finish resolving; failed configuration directs inspection in Code before starting. Live native restart/failure verification and recovery after closing the app remain unfinished.

In the development Predict surface, a single example shows its answer beside the input. Next run groups the model, input and run controls and explains that changes apply to the next Run; retained results stay unchanged. Text stays readable, numbers are prominent, and structured output shows named fields. Inspect result opens the captured input and model details; Run details reveals identifiers and counts. Editing the next input leaves the saved answer tied to its original model. Run on rows uses a paged result table. Opening or editing either view does not run a model. Before batch Run, map every named input to a retained column. Configure → Execution limits shows the row, model-call and time budgets; missing mappings or an over-budget selection keep Run unavailable with a specific correction. The selected rows are never silently sampled, and Run uses the reviewed limits instead of increasing them to fit.

The selected native batch owner supports at most 1,024 rows and logical model calls in sequential chunks of up to 32; each row consumes one call. Legacy requests and Evaluate/Process retain their 64-call limits. A same-owner archive path for original batch history is being integrated. It preserves the original attempts, rows and receipts and refuses older, changed or foreign history; ordinary workbook deletion remains unavailable while that evidence is retained. Four actual-host archive tests pass, including replacement and rollback; 133 focused owner contracts cover the final schema/disposal hardening. Paired Performance and full-suite verification remain pending.

Predict and Evaluate provide History as a secondary destination. Open it to page through runs for the current surface, or choose This workbook to find runs from other or renamed surfaces. Selecting a run changes the retained result selection without changing the current setup or executing a subject. History loads only while open, refreshes explicitly, and does not observe unselected runs. Print keeps the selected snapshot without history controls.

Evaluate's retained classification measures expose Class performance on demand. Per-class scores shows precision, recall, F1 and actual case counts; Confusion matrix uses actual labels as rows and predictions as columns. Unavailable measures stay distinct from zero. Larger class sets page ten labels at a time, preserving exact label identity and the full retained population. Print includes both tables and identifies a partial window for larger reports. Opening these details performs no model calls.

In Train, Create Evaluate surface uses the completed version’s retained feature mapping, target and task, even after the training editor has changed or the workbook is reopened. It compares the exact candidate with the pin recorded in that result. A held-out snapshot is reused only while its source and retained membership still match; otherwise choose cases in Evaluate. Older results without retained mapping require explicit setup. Creating the surface runs no evaluation.

Process source can import the exact bundled ops:grid/ai-workbench@1.0.0 declarations to type-check pipeline steps. Importing the package does not grant data/publication authority. An explicit native installation now selects a preview for all six operations: capture, Predict, Train, Evaluate, publication and explicit version selection. Train consumes the retained dataset, fits through the existing training service, and returns the exact registered version. It preserves an existing selected version. Queued and running work retain the original workflow cancellation control; reopening or checking an uncertain outcome never repeats a fit. The native bridge under development preserves original operation identities and accepts result artifacts only after the owning execution has drained. This does not yet complete the full AI pipeline from the Process surface. The Dataset capture adapter uses the existing native snapshot owner. Predict consumes that retained dataset with explicit field mapping and a model-call limit shared with the whole Process. It retains the selected model identity, results and row failures. Each operation requires an administrator's startup grant for the exact principal and workbook and Unix recoverable Process storage. Ordinary workbooks retain their existing behavior. Full Process journey verification remains in development. Evaluate consumes retained cases and either saved predictions (zero model calls) or an exact trained version (new case runs). It retains checks, case coverage, comparisons and trial identities. Optional model judgments count separately and share the workflow call limit. Cancellation also reaches subject and judge calls. Publication requires a reviewed existing workbook input, source identity and expected input revision. Version selection requires the expected current pin and an exact trained artifact; a concurrent change is refused. Both actions are explicit steps and retain their original receipts. A lost response or later pin change cannot cause another write. Live Capture, Predict, Train and Evaluate operations now notify their waiting Process after the owner work drains. The shared executor checks the original receipt before advancing, even when the surface is closed. The panel identifies automatic progress when that live capability is present. Check remains available for an explicit lookup. A completion notification alone cannot prove success, repeat execution, extend limits or revive cancelled work. For an uncertain retained AI operation, Check original outcome explicitly reads the original native result under the current grant. It can clarify the outcome while leaving the workflow stopped; it never repeats work or refreshes input.

After a host restart, a known pending AI operation can return as suspended. Prepare to resume and Resume process restore its original wait, limits and owner identity under the current grant. Pipelines without participants need no model connections. Resume does not repeat the operation or check its outcome; Check operation outcome reads the original owner result before continuation. Unknown or interrupted dispatches remain stopped, and the original deadline still applies. Native restart verification remains in development.

In the selected native AI workbench, a fresh compiled Process comparison can use its reviewed profile choices with the saved AI connection or an explicitly named provider/model. The native owner reads the existing encrypted setup at operation admission; secrets are never authored into the workbook. Empty or local-only choices need no credential-store read. Missing or corrupt selected authority refuses. Original-parent recovery verifies the original responder identity and retained answer before continuation; changing setup cannot authorize repeating an accepted or unknown turn. Named compatible and saved-default local-server journeys now pass actual App restart/Resume checks. A selected compatible-profile key change also refuses original responder recovery without repeating the request. Interrupted in-flight requests stay unknown. The selected native owner now finishes recording that original unknown outcome while retaining its charged call; it starts no further comparison or model request. Actual App recovery checks pass for this interrupted compatible-model request. Broader provider recovery and credential-change recovery UX remain in development.

A workflow can ask a named person a typed question through a request channel and wait for the answer. When a run is waiting on you, the panel shows Requests waiting for your answer with what was asked, the time to reply by, and a control for the answer's type (Yes or No, text, a number, or JSON). Send answer delivers it and the run continues. Sending the same answer again after a lost response cannot count twice. An answer that arrives after the reply time, or after the run withdrew the request, is reported as closed and changes nothing. The section is absent when nothing waits for you, and only the people a channel names can see or answer its requests. Channels are set up by the host administrator.

A role can be answered by an agent that is not Grid. In AI setup, an administrator adds an External agent: its address and, if it needs one, a token. Check address lists the skills the agent offers. When you start a process, choose External agent for a role and enter one of those skills. The agent is sent only what each of its turns is given, and its token never reaches your browser. If the run is interrupted between the agent's turns, you can resume it with the same agent; it is asked only what it had not yet been asked. One external agent can be saved at a time.

A model role can be given tools. Open Tools for that role in the Process panel and tick what it may use. The model can look things up through them during its turns and cannot change anything. Two kinds are listed:

• Reads of the API services installed in Connectors.
• Read-only tools of MCP servers. In AI setup, an administrator adds an MCP server under a short name, with its address and, if it needs one, a token. Up to sixteen can be saved. The Process panel asks each saved server what it offers. A tool the server does not declare read-only is listed with the reason it cannot be chosen, and a server that cannot be reached is named.

Save setup keeps the tools chosen for each role with the plan, beside its model choices and limits. If a saved tool is no longer available when you start, the process is not started and the role is named, so a tool is never dropped without your knowing.

Each call counts against the run, and the run's conversation shows which tools a turn called and whether each returned a result. A run keeps the tools it was started with, so resuming it needs no further choice; a run with an MCP tool needs that server still saved, at the same address, to be resumed. A token never reaches your browser. An external agent and an installed local model are not offered tools.

A plan can perform a command on an installed API, such as opening a ticket. Its author imports the API's commands in Code, separately from its reads, and calls one as a step of the plan. A command is sent once. If the API answers with a clean success, the plan goes on with what it returned. If the reply is lost or is anything else, the run stops and says the outcome is not known; Grid does not send the command again, and the stopped command stays on the run for you to check against the other system. A model cannot choose to perform a command: only a step the author wrote can. Before you start such a process, the Start form lists the changes it can make. This needs a host that keeps run records.

For a completed or stopped run, Check saved record re-derives the run from its saved record and reports whether it reproduces the same outcome. Choose the model settings the run was started with; they only identify its participants, and no model is called. The check also lists what each turn was given: its starting instructions, shared material, question and earlier replies. It needs a host that keeps resumable run records, and it is not yet available for runs that used operations.

Run again from a turn starts a new run from a completed or stopped run's saved turns. Choose how many turns to keep, from the first, and the model settings the run was started with. The new run keeps those turns without asking any model for them, then carries on by itself. It uses the inputs the first run was started with, and has its own time limit. The first run stays as it is. In the new run's conversation the kept turns are marked. A run that stopped part-way can be continued this way from its last saved turn. A turn answered by a person, or one that used a tool, cannot be kept: choose an earlier turn, and the person is asked again in the new run. Runs that used operations, a population or a shared room cannot be started again this way yet.

If a Dataset, Predict, Evaluate or snapshot-publication submission loses its response, Check submitted run (or capture/publication) looks for the original work. If it stays missing, expand Submission still missing? and choose Recover submission. The host either returns the original run or durably closes a request that was never accepted. A delayed copy cannot start after closure. Recovery leaves existing work running and never retries it; starting again after confirmed closure is a separate explicit action. If recovery itself loses its response, the saved submission stays available for the same recovery.

XGBoost regression additionally offers Calibrate an automatic upper P90 bound. This selects a seeded held-out calibration, not a full predictive distribution. Automatic mode may still produce a point-only model with an unavailability reason. The deployment view exposes a bound formula only for an admitted exact registry version; bind a worksheet feature range to copy it. Follow Train and Use Calibrated Predictions for data requirements, candidate-versus-pinned versions, external artifacts, and failure handling. Training requests also support required calibration, temporal splits, and explicit probability levels.

Reuse prepared data

In Predict, open Evaluate these results beside a finished batch and choose Create Evaluate surface. The new surface selects Evaluate saved results with that run's original model, cases and configuration identity. Add a check and choose its reference column before Evaluate. Editing Predict's next model or input does not change this assessment. Scoring uses the retained results without another inference call, including failed and unattempted cases in coverage. This handoff requires a drained prediction with a retained cases snapshot; a standalone example without retained cases is not offered. Run/Print omit creation.

After native Dataset preparation completes, open Use this snapshot and choose Create Predict surface or Create Train surface. Only the chosen surface is created, with that complete retained snapshot selected. Predict asks you to choose a model and map its inputs. Train preselects numeric features; choose the goal and target before training. Later Dataset edits or preparation do not replace the snapshot in the new surface. These actions are available in Workbench only.

Predict, Train and Evaluate share a Dataset snapshot picker. Completed captures show their originating surface, row count and capture date. More snapshots and Previous snapshots browse older captures; Refresh snapshot list reads the latest list without refreshing a connector or source. Your selected snapshot stays available while browsing other pages.

Open Inspect selected data to read retained rows before running. The preview shows 25 rows and six columns at a time, with column types, stable row identities and snapshot/content/lineage details. Long text is shortened and structured values show their size. Page rows or columns explicitly; closing the preview stops its read. Execution still uses the complete selected snapshot unless you explicitly choose a row selection or sample. Preview limits never become execution limits.

Train

For a ready, registered candidate, Try this version → Create Predict surface opens one empty example with that exact candidate selected. Enter its inputs and choose Run explicitly. This does not replace the registry selection or any workbook binding, and it does not reuse training rows as an implicit example. The candidate identity comes from the completed training result even if you have edited the next training recipe. Use this version remains a separate action.

To compare more cases than fit in one fresh evaluation, run each subject on the same frozen cases, then choose Evaluate saved results and Add comparison. The comparison makes no new inference calls and keeps each common-case count beside its measure. Training another candidate leaves the existing model selection unchanged; choose Use this version only after reviewing the comparison.

New unnamed Train models are scoped to their workbook and surface. Two workbooks with a Train_1 surface therefore start separate models. Retraining a retained candidate continues its recorded model identity; an explicit model name remains your choice.

Use Train to prepare a model from selected dataset rows, review the chosen learner and resolved time budget, and start training explicitly. Keep the result's exact model version for evaluation before pinning it for prediction. Choose a goal first: number prediction, outcome classification, grouping, dimensionality reduction, or prompt adaptation. Each chooses a starting recipe; expand Recipe to use another algorithm. Classification starts with binary logistic regression. Opening an existing configuration preserves its recipe. The candidate appears beside setup with its exact version and saved metrics. Training details retains the job identity and complete metrics; editing the next recipe does not change the candidate. Evaluate independent cases before explicitly selecting Use this version. Prompt adaptation retains examples and does not update weights.

Open Data and model evidence beside a candidate to inspect its retained feature order, target, dataset identity, row-selection membership and sampling. Normalization parameters and artifact feature weights appear when retained; weights preserve the artifact's labels and signs. They describe model-level metadata, not per-case attribution or causation. Available predictive uncertainty shows its calibration and limitations. Older manifests label missing evidence instead of borrowing today's training setup. Tables show ten rows at a time; Print includes the evidence and labels partial windows. Opening evidence makes no model call and does not fit, sample or select a version.

This development surface requires the selected AI suite capability. Opening a tab does not start training; legacy Predict tabs retain their saved behavior.

For text extraction in Predict, open Configure, write the instructions, and choose Validated structured output. Add named fields with Text, Number, True / false, or Any value types. New fields are required; Allow null permits an explicit null value independently of whether the field must be present. Remove the initial value field if your output uses other names. Edit contract as JSON supports nested objects, lists and field renaming. Nested definitions are retained when editing other fields. Contracts show eight fields per page; paging never changes the contract. Invalid JSON stays editable and blocks Run. Evaluate uses the same editor for subject output contracts and schema checks. For example, map an invoice-text column to input, request company as Text and amount as Number, then explicitly Run. Failed output validation stays visible beside successful cases. Evaluate these results can compare the retained company field with an expected-company column without another inference call.

In Predict or Evaluate, select a case and open Data and model evidence to see its exact admitted model/version or profile, provider revision when retained, and ordered model inputs. Inputs are paged ten at a time. Case data identifies the captured inputs; a separate Training snapshot identifies the model's retained training selection, target, membership and explicit sampling when available. Expanding identities shows their source revision, content and lineage. Run identity and usage labels calls, tokens and reported cost as totals for the whole run. Missing usage fields are not treated as zero. All evidence comes from that retained run, without consulting the current model catalog or draft. Advertised uncertainty support is labeled separately from a case estimate; opening this disclosure never generates an explanation or runs a model.

For a retained native prediction or evaluation result, choose Use in workbook, select its columns and an existing declared input, then confirm the mapping. The local authoring host stores the resulting input and exact native receipt together. If delivery is lost, Check submitted publication inspects that original command without repeating inference or the write. Source or input revision changes require reviewing the destination again. Receipt authority stays with its native workbook owner: cross-owner imports and restores that omit or alter committed receipts are refused. A selected native coordination owner keeps its existing stronger admission requirements and never falls back to local authoring. This development increment's native recovery and end-to-end evidence are tracked in the built-in surface completion ledger.

A native one-example prediction retains its input snapshot while showing a single answer with Inspect result. The saved input mode controls this presentation; a one-row Dataset run remains a case table. Reopening does not infer again.

Evaluate

Subject selection compares the reference identity fields, independent of native TOML table-key order. Versions, installed digests and compiled plan identities remain exact; saving a setup still requires its acknowledgement before execution.

Use Evaluate to compare retained outputs or explicitly run selected cases. Choose the subject, case snapshot and checks, then inspect outcomes and known training overlap. Exact retained range bindings keep their existing comparison. New native captures also retain the resolved worksheet and complete column span; source-row lineage can then compare different row bounds in those same physical columns, including selected training rows and prepared descendants. Different columns, sheets, owners, unproved aliases and legacy cross-range records remain unknown. Matching row positions in unrelated columns do not prove overlap or independence. The current cross-range source implementation is connected; two focused native Frame/catalog contracts pass, including both legacy/current prepared comparisons. Complete native capture delivery and paired costs remain open. Saved Process results remain tied to their original admitted inputs. Unavailable original evidence or an unsupported input authority refuses without running the Process again. Saved-result evaluation makes no model calls; fresh inference and rubric judges require explicit selection.

Prepared aggregates and rows kept after duplicate removal use the retained membership of their contributing source rows. A case overlaps training when any contributing row was used for training; otherwise its known membership is held out relative to that selection. Invalid preparation lineage refuses the check. These labels describe source membership, not statistical independence.

In a retained case's inspector, Your review saves a human rating and note against that exact evaluation and case; computed scores stay unchanged. If the save result cannot be confirmed, the inspector keeps your draft and asks you to reload the saved review before saving again. Reload saved review reads the original saved state and preserves your drafted rating and note when they have not been acknowledged. Resizing the inspector keeps the focused review field, cursor and draft. Another Save rating is an explicit action; observing the saved review never retries the write. Review metadata from a different workbook, run or case is refused.

Before running, Evaluate identifies missing reference columns and stale slice selections. For fresh cases, map each named model input to a case column; text models expose an input mapping. An unavailable model or missing input metadata requires a different available model or saved-result evaluation. Evaluate stays disabled until these setup issues are corrected. Changing a mapping performs no execution. Native validation still checks the complete request when submitted.

When a subject cannot start inference, Evaluate retains the underlying model setup diagnostic with the subject and trial. Cases that were never attempted remain unattempted; an unavailable score does not mean zero error.

A saved evaluation opens on its results. Edit evaluation setup reveals the cases, subjects and checks for another evaluation without changing the saved report. Metric cards show scores alongside case coverage. Paired comparisons show baseline, comparison, signed difference and the number of common scored cases; these scores can differ from each subject's full-case measures. No single quality score or automatic winner combines unlike checks. Case rows identify subjects and repeated trials. Remove comparison drops a selected comparison from the next evaluation's setup.

Comparison and trial controls stay available when a retained report lacks paired scores. Missing summaries are labeled explicitly. Zero common cases retain unavailable scores rather than showing zero error. Subject measures identify their selected slice; paired comparisons identify the trial and cover all cases. Switching to Print preserves the selected subject, trial, slice and comparison. Print labels this as a selected view of the report; choose another view in Workbench to print it. Switching modes does not execute subjects.

New evaluations retain readable check names, versions and field mappings with their report. Measures, paired comparisons and case details use those retained names, even after you edit the surface setup. Coverage shows checks that could not be scored. Older reports keep their scores and use numbered check labels; the case inspector exposes their original IDs without guessing their meaning.

Exact-match and field-equality checks compare numeric values across integer and decimal JSON encodings, including inside structured results. They do not round large integers, apply a tolerance, or convert text to numbers. Numeric class labels use the same exact identity: 21 and 21.0 identify one class, while the text "21" is a separate class. Previously retained scores stay unchanged; explicitly Evaluate again to create a result with the corrected checks.

App mode shows the selected retained evaluation. Print Studio includes its run identity, coverage, measures and case results without execution controls. Opening or closing the preview does not create an evaluation or rerun a Process.

For a native Process, choose Evaluate saved results → Processes, a retained case snapshot, and the original settled run for each case. Map each argument in its original call order to a case column. Grid verifies the exact input digests retained at Start; selecting a different row or editing the source cannot relabel an earlier result. Trials and slices reveals repeated trials, with separate retained run selections for each trial. Unselected cases remain unattempted. Only runs owned by the current authenticated principal are offered.

Results retain the exact compiled plan, input identities and native counters. Counters describe lifetime reservations, not provider billing. Elapsed time and operation-outcome metrics are unavailable when the native snapshot lacks that evidence; nested model-call totals are unavailable for operation/tool runs. Remote responder outputs are not guaranteed reproducible. Nominal input values need an additional identity adapter. Fresh Process cases use the selected native isolation adapter and require reviewed argument mapping, exact compiled source, read-only effects and explicit limits. In the development native Process evaluate operation, a trained candidate can also be compared with a role-free or human-only Process. Stopping the parent stops its original case continuation; model connection choices require a separate native connection owner and refuse when it is unavailable. An unfinished nested evaluation cannot be resumed from the workbench without recovering its original parent control.

Process

Use Process to inspect a compiled team workflow, choose model settings and run limits, and start it explicitly. Design and start places the sequence beside run settings, stacking them at narrow widths. Selecting a run closes setup and puts its result or pending human question first; reopen setup to design the next run. Print identifies the selected run and its result or question, without the interactive history and conversation browser. Replies and human decisions remain associated with their run. Edit source in Code; opening the surface does not execute it. Sequence/diagram editing prepares reviewed Code drafts. The six bundled AI workflow adapters require explicit native installation; full journey verification remains in development. For the installed workbench.Train operation, declare positive timeoutMs and maxRows in its budget alongside the selected profile. A profile alone does not bound a Process training operation. The Demand development workbook declares 10 seconds and all 504 training rows for each candidate; this does not sample the selected snapshot. See the human review walkthrough.

Game

Use Game to configure chess, repeated matrix games, Kuhn poker or heads-up no-limit hold’em, assign competitors, and play or run a bounded comparison. The native owner validates actions and retains decisions, private observations and source identities. Replay makes no opponent calls; branching preserves the original match. Opening Game inspects retained state and starts no computation.

Custom Grid rules and trusted React renderers use the same authoritative action path. Embedded Game views inspect retained state; start and advance matches in the standalone surface. See Authoring a Game laboratory for canonical starters, Process budgets and the Nim extension example.

View

Use View for an interface declared in model source: pages, local state, reusable elements and actions. Edit it in Code and inspect it against the saved model or an explicit private preview. See Grid Views. Train, Evaluate and Process retain their native operation owners and are not admitted as embedded native View controls.

Dataset

The Dataset surface is for bringing tabular data into model shape. It can preview data from model values, files, or configured sources; show schema information; and apply a pipeline of transforms such as filter, select, rename, derive, sort, limit, dedupe, and aggregate.

Use it when raw data needs cleaning before it feeds formulas, tables, charts, or custom apps. Dataset is the surface that turns "we have a CSV or row array" into "we have a model-ready source."

In the preview-and-steps editor, results open in pages of 20 loaded rows. Use First, Previous, Next, Last, or enter a page number and press Enter to move through the result. Escape cancels an unfinished page number. Renaming the source or editing the output target keeps your page; a smaller result moves you to its last available page. For very large results, the first page appears before column type hints finish checking all loaded rows. Those hints still describe the full result once the check completes. URL, asset and native-table preview sources offer Refresh source in Result. A failed load offers Retry source; keyboard focus stays on that control through recovery. Refreshing clears the prior result until the current request finishes. CSV and Publish use the full prepared result, regardless of the page on screen. Browser text search covers the visible page. The printed preview retains its existing first-200-row limit. Native preparation has its own result controls.

After native preparation, Prepared data shows typed columns and stable row identities beside the source editor. It reads 25 retained rows at a time and displays six data columns, with separate row and column paging. Editing the next preparation leaves this snapshot unchanged. History opens capture history on request; selecting an earlier run restores its retained data without preparing again or changing the current setup. Print keeps the selected row/column window, labels partial output, and includes snapshot, content and lineage identities.

In the selected development AI suite, native Dataset preparation captures the complete range from the workbook's native calculation owner, including saved input overrides and rows outside the visible grid. It also works after reopening a cold workbook. Pending model calls or connector data require an explicit source refresh; capture does not submit those requests. Legacy Dataset previews keep their existing behavior until native preparation is adopted.

Table

The Table surface is the Airtable-like record view. It presents rows and fields with density, column, schema, and browsing controls that feel natural for record work rather than cell work.

Use it for operational data: customers, orders, tasks, inventory, leads, assets, or any other row set where users think in records. A Table can bind to a named row source or model-local table handle, infer fields when needed, and provide a familiar tabular interface over the live model.

In the workbench, Add native column… previews one ordinary column against the complete native catalog. Existing columns, units, choices and write rules are preserved, including fields hidden by the surface configuration. Apply additive migration checks the source hash and catalog version and uses the existing native source compiler and additive migrator. The table must have one object-shaped source declaration; conflicting source/catalog ownership is refused. Drops, conversions and new uniqueness/write-rule guarantees are outside this editor. Source previews admit 1 MiB and tables admit 256 columns. A lost reply enables Inspect after uncertain save, which reads source and catalog without replaying DDL. Existing Table views and Print retain read-only schema.

Pivot / Crosstab

Choose Pivot to group a native Table by row and column dimensions. Select up to four distinct dimensions and eight measures: count, sum, average, minimum or maximum. Save the configuration to reopen the same analysis. A Table binding or an explicit native table/saved view supplies the records.

The native table owner computes values and subtotals. Row and column pages show which groups are currently visible; totals preserve their labelled scope. Select a populated group to inspect its exact contributing records. Changed source revisions require a refresh before drill-through. Browser rendering does not regroup records or approximate missing groups. See the sales Pivot example.

Ledger

Choose Ledger to keep double-entry books as T-accounts. Accounts and posting lines live in two native tables, so formulas and the Table surface read the same records. Each entry is posted whole in one transaction, and only when its debits equal its credits. Amounts are stored as whole minor units, so totals are exact. Voiding an entry or archiving an account is a soft delete: rows stay, and voided lines leave every balance. The table store enforces these rules for every writer, including the Table surface and model rules: posted lines stay fixed, entries stay balanced and new lines must name a current account. Show all postings opens an account's full history with a running balance. The Ledger creates its table columns on first use and applies later schema versions as additive upgrades, never dropping or rewriting data. Ledger 2.0 optionally keeps original currency amounts and explicit rates, previews currency revaluations, closes accounting periods for every writer, and records self-declared posting authors. Date filters and a full trial-balance report with CSV export support review. See Ledger and the ledger example.

Matrix / Tensor

Matrix / Tensor is one built-in surface, found by either name. Bind a native array or authored Tensor, inspect dimensions and axes, select fixed indices, and page through rows and columns. Compare with another source only when shape and axes align. The native owner computes each difference; zero, missing, error, nonfinite and nonnumeric values remain distinct.

The view uses 24-by-24 pages, with values, heatmap and zero/nonzero structure modes. Select an element for its exact value and comparison. Shape comes from the native array or Tensor contract; labels describe axes without changing numeric meaning. See the Matrix/Tensor example.

An explicit sparse source option selects an owned immutable OmicsMatrix artifact. Axis labels and order must match for comparison. Each selected read verifies and decodes the complete bounded CSR artifact, up to 32 MiB and one million stored entries; only the requested window becomes dense. This cost is shown in the view. Reading a page does not imply paginated source decoding.

Each inspection is a snapshot. Refresh after changing model inputs; if a new shape no longer contains the selected axes or coordinates, Reset slice returns to its first page. Symbol inspection is unavailable when the model uses an isolated calculation worker; normal model calculation still works. Owned sparse artifact inspection remains available.

Media / Signal

Choose Media / Signal for an audio/video file in the model's Files, or a finite native numeric vector with an explicit sample rate. Numeric matrices use frames as rows and channels as columns. Configure source also names two declared numeric model inputs that can receive selection start/end times.

WAV and numeric sources provide a native min/max waveform and a Hann-window spectrum. Inspect exact frequency/time bins, choose a channel, and navigate bounded signal windows. Large windows disclose sampled spectral times; gaps are not measurements. The cursor and playback remain synchronized without starting a new native inspection on every playback tick. Numeric amplitudes retain their model units; the spectrum is relative to amplitude 1, not sound pressure or a physical power estimate.

Audio and video play only after the retained bytes match the native source hash and the user starts playback. Other supported browser codecs provide playback and annotations without an invented waveform. The current asset limit is 64 MiB; complete asset bytes are verified before playback. Native numeric inspection admits two million frames and eight channels.

Numeric signal inspection currently requires the in-process calculation owner. When a model calculates in a separate per-model worker, this inspector reports that capability as unavailable. It does not substitute another runtime's shape or values. File playback and native WAV inspection use the model's Files owner.

Select an interval and save a timed annotation. Edit or explicitly confirm its deletion; saves wait for an advancing receipt from this surface's data slot. Failed or uncertain saves preserve the draft. Annotations from another source version remain readable with their original identity and cannot seek/edit the replacement media. Use selection in model writes both declared inputs in one acknowledged batch. Print preserves the bounded projection and annotations, omitting playback and write controls. See the signal review example.

Map

In the workbench, select a layer and use Data to connect a named source, choose latitude/longitude fields or a geometry column, and optionally choose a label field. Adding a layer focuses its source input. Unbound layers stay empty rather than displaying sample locations. Narrow panes keep the map above a scrolling inspector; run and print views omit authoring controls.

The Map surface renders spatial data as layers. A layer can bind to rows with latitude/longitude fields or geometry fields, choose visual style, and display labels or identifiers.

Open Annotations and comments to add a note pin or a freehand line. Give it text, then Save annotation. Enter coordinates instead of drawing when using a keyboard. Select a saved item to edit it or add comments; choose Whole map for general discussion. Deleting an annotation removes its attached comments, and Undo annotation change restores them together.

Comments are shared through the model's saved data. Names are display labels, not verified identities, and comments do not send notifications. Failed saves retain the submitted draft. A conflicting or uncertain save offers a local copy and an explicit choice to load the saved version. Read views omit editing; print includes the notes, line titles and comments below the map.

A review can hold 500 notes/lines and 500 comments, up to 2 MiB in total. Lines allow 2,000 points each and 20,000 points combined. Invalid or unsupported saved review data remains intact for repair in Code. Existing version 1 notes open normally; new review documents use version 2 and must not be edited in older Grid apps. Try the field review example.

Use it for territory plans, store locations, delivery zones, facilities, incidents, assets, or any model where geography is part of the answer. The Map surface gives spatial model state a visual inspection layer rather than forcing users to read coordinate columns.

Calendar

Find events searches titles and categories across the loaded records. The match count identifies that scope; a Table Calendar searches its current page. Use Agenda to see matching events across dates, or keep browsing the current month, week or day. Clear search or Escape in the search field restores all loaded events. Search makes no model changes, and print includes all loaded events regardless of the session search.

Agenda and Timeline event titles open the same details as Month, Week and Day. Use Enter or Space on an event title to inspect it; writable bound events offer the existing editor. Dismissing details returns focus to the event. Print titles remain noninteractive.

The Calendar surface turns date/time rows into month, week, day, or agenda views. It maps event fields such as start, end, title, and color.

Use it for schedules, launches, staffing, bookings, deadlines, content plans, and project timelines. Calendar is best when the model output is naturally understood as time blocks rather than rows.

Bind Calendar to a named array of date rows (including JSON array literals) or a native Table/table view. Use New event, the first-event action, or a month quick-add to create a record; open an event to edit its mapped fields or confirm deletion. Drag events to reschedule them, or drag their bottom edge in Week and Day to resize them with half-hour snapping. Untouched fields remain intact.

The quick creation form includes Start date and End date. Choose a later end date for overnight shifts or multi-day bookings; an earlier end clock time alone never implies another day. Changing the start date keeps the default end date aligned until a different end date is chosen. A failed save retains both dates and times for review.

Week and Day show timed overnight or multi-day events in their actual hours on each date. Whole midnight-to-midnight intervals use the all-day band. An event ending at midnight does not occupy the following day. Resize its final portion to change the end; drag any portion to move the complete event with its duration preserved. Month and Agenda keep their existing spanning/grouped views.

Saves wait for the host's acknowledgement. Pending controls are disabled; a failed or uncertain save keeps the draft. Escape offers Keep editing or Discard changes when the draft has edits. Table editors offer Refresh current events after a failure so you can compare the last loaded record with your draft before retrying. Refresh never resubmits a mutation. A save conflict requires reviewing the current record and reopening it to make a new edit.

Native Table calendars load 100 records at a time and label the page, total and optional view. Each calendar layout shows that loaded page; use the record paging controls to browse more. Prints disclose partial pages. A record changed outside Calendar can fail its guarded save or deletion, and an edited record may leave a view's filter. Named-array editing requires a host that returns input commit receipts. Recurrence rules, attendee invitations and external calendar synchronization are outside this surface's current scope.

See the native Table schedule example.

Planning schedules

A Calendar with [planning] enabled = true shows the native Planning region as resource lanes in relative time. Edit plan opens the current activities and constraints. Add or delete activities, rename them while preserving dependency links, choose predecessors, and edit preferred/alternative resources, demand, availability windows and sequence changeovers. Release times, hard deadlines, optional-work costs, soft due dates and separate solve/repair budgets are editable.

Save and solve submits the whole draft to the native scheduling owner and waits for durable acknowledgement. Inspect the resulting assignments and solver status: an accepted plan can be infeasible or exhaust its search budget. Invalid constraints are rejected. A changed model or restarted host refuses an older draft. Failed or uncertain saves preserve your edits; Reload current plan requires explicit discard when the draft has changes and never repeats the save.

Edits are saved model state, including archive restoration; they do not rewrite the source seed or immutable compiled PlanHandle. Replacing source resets edits when its source identity changes. This editor does not directly pin or drag a solved assignment: change its activity constraints, then solve again. Definitions over 2,048 activities/resources or 32,768 dependency/availability/changeover entries, names over 256 UTF-8 bytes, unsupported fields and integers beyond the exact JavaScript range refuse visual editing. Native resolving remains available. Results whose times or aggregate costs exceed the viewer’s exact integer range show an explicit display refusal; they are not rounded into a different schedule.

The native fabrication reference, examples/planning/job-shop.json, supplies nine activities and every supported constraint family. With that model open, add inspect-a with duration 2 on dock, make it follow assemble-a, then change ship-a to follow inspect-a. Save and confirm that shipment begins after inspection ends. examples/planning/README.md includes the native compilation steps and a resource-capacity walkthrough. These are Core source references, also retained in the local Dev content import.

Charts

Chart and Map setup changes show a local preview while the source save is pending. Configuration saved to the model means the source owner confirmed the change. A failed or uncertain save retains the latest local setup and pauses further sends. Export the local and saved copies to compare them, then choose Save local configuration… to review replacement or Load saved configuration… to review discarding the local copy. Neither action replaces a copy until confirmed. Changing chart or map setup does not replace chart values, map locations, or map annotations.

Where the host provides local recovery storage, Recover local configuration… can find retained setup after reopening or reloading. Opening a retained copy sends nothing; save it explicitly after comparing the current saved setup. Copies are scoped to the account/backend, model, partition and view. Storage failures remain visible, so export important local work when saving cannot be confirmed. Visual configuration editing admits at most 1 Mi characters; larger setup remains available in Code. Map annotation and comment recovery has its separate data owner.

When a chart pane is narrow, its configuration editor moves below the plot. Scroll within the chart to reach the editor, or choose Hide editor to focus on the plotted results. This responds to the pane's available width, including space occupied by the source and inspector panes.

If chart initialization, an option update, or a resize throws an error, the chart shows the failed phase, expandable details, and Retry chart rendering. Retry recreates that chart instance. A renderer failure is separate from loading data, an invalid binding, or an empty result. An error inside deferred third-party drawing code may still require reopening the view; this handling does not detect every possible blank canvas.

Select a loaded worksheet rectangle or one named array, then choose Insert → Plot selection, the cell context menu, or Plot selection in the command palette. Review the detected columns and eight-row preview, choose finite numeric X and Y fields, and label the axes. A worksheet header row can supply labels; the saved binding excludes that row. Units are display labels only: convert values in the model when conversion is needed.

Observations creates points; Curve joins points in source order with straight segments. This does not perform a fit. The result is an ordinary Charts tab linked to the original data, with explicit worksheet qualification. The preview accepts at most 16,384 scalar values and 32 columns; unloaded values, errors, numeric text, and missing X/Y observations require correction. A single vector can instead use the existing Named X and Y vectors editor.

For line and area series, Interpolation selects Straight segments or Smoothed curve. TOML uses smooth = false or smooth = true; omitting it preserves existing smoothed charts. Plot selection writes smooth = false. Smoothing is visual interpolation, not an estimated physical model.

Live Charts subscribe to the cells and named arrays actually bound by their series, including qualified Default and quoted worksheet names. Range bindings are limited to 65,536 aggregate cells across the chart; unsafe or larger ranges show a size explanation before subscription or resolution. Reduce the bound range or compute an explicit summary in the model. This chart binding limit is separate from the smaller Plot selection preview limit. Use the exact name for a binding whose data has not loaded yet. Case-insensitive matching of a differently spelled named array uses already-loaded names when the chart opens; reopen or rebind if that name only becomes available later.

The Charts surface is for dense analytical charting over model outputs. It supports familiar series types such as line, bar, area, pie, and scatter, with field mappings for x, y, label, and color.

Each series has a Number format: number, compact, USD currency, percent, or the layout default. For example, put revenue on the left axis as currency and margin on the right as percent. A raw margin of 0.12 displays as 12%; formatting never changes values or converts currencies. Tooltips and View plotted data retain the individual formats, and the data table also shows the raw numbers. If different formats share one axis, its ticks stay plain numbers. Choose separate left/right axes when the quantities need different scales.

Editable JSX output preserves those formats and independent value scales. Shared category names align across reordered or incomplete series. Numeric bars retain coordinate spacing and fit within the plotted domain; line and area series retain their authored smoothing choice using constrained SVG curves and missing-value breaks. It renders simplified SVG with authored interpolation, missing-value gaps, separate scatter points and actual pie sectors. It does not reproduce the chart editor controls. When authored viewport inputs are present and X coordinates are numeric, exports include start/end controls and reset. These write only the declared minimum, maximum and resolution inputs through the existing Component write guard. Opening the export does not write to the model. See the revenue and margin example.

Use it for exploratory analysis, reports, and dashboards where the important question is "what changed, how much, and compared to what?" Charts is tuned for data-heavy analytical views.

New unbound charts show Choose data to plot. In the editor, Preview example data explicitly opens a labeled demonstration; it does not save sample values into the model. Run and print views do not automatically show examples. Bound charts identify each series' source, distinguish unavailable, empty, calculating, and failed data, and never replace a failed binding with sample data. View plotted data exposes up to the first 100 source rows per series on demand; inspect the bound symbol or range for the complete dataset.

In the chart editor, Data source → Named X and Y vectors pairs existing numeric vectors without creating model formulas. Select an X and a Y for each series; add another series to use the same X with another Y. Row and column vectors are accepted. Both must contain finite numbers, have equal lengths, and contain at most 65,536 points. Matrices, blanks, and numeric text produce an explanation rather than a truncated or coerced plot. Numeric X coordinates retain their spacing. Source captions and the data table identify both names.

The optional TOML keys are x_bind and y_bind, replacing bind for that series. For example:

[[charts]]
type = "line"
x_bind = "Rates"
y_bind = "OutflowPressures"
label = "Outflow"

Do not combine a table/range bind with vector bindings in one series. The editor writes ordinary surface configuration. Ejecting to a Component retains both references, shape checks, and numeric X spacing. Reducing large vectors remains an explicit calculation in the model. Chart axis titles use bounded horizontal space above and below the plot in narrow and print layouts.

Visuals

The Visuals surface is the presentation-oriented sibling of Charts. It focuses on polished SVG visuals, palettes, legends, grid options, grouped bars, curves, donuts, and hover behavior.

An unbound visualization starts with Choose data, which opens the editor and focuses its binding input. Preview example data is an explicit workbench-only action; example charts are labeled and cannot be exported. Run and print views show only connected data.

Use it when the model needs a chart that feels ready to show: executive dashboards, narrative reports, embedded presentations, and cleaner visual summary tabs. Finished visuals can be exported as SVG or PNG for use outside the workbook. Export work runs only after the user chooses a format. SVG serializes the live presentation tree with explicit pixel dimensions; PNG rasterizes that tree at 2× on a white background. After either download, the surface shows the exact output digest and byte count plus format-specific preserved, transformed, approximated, omitted, and boundary claims. Neither format is represented as a model snapshot, accessible-data substitute, archival research package, or verified evidence artifact.

Candlestick

The Candlestick surface renders OHLC financial data with optional volume, overlays, indicators, and a live demo feed when no data source is bound.

Use it for market data, trading models, price simulations, and time-series analysis where open, high, low, close, and volume matter. It keeps chart settings, bound fields, realtime behavior, and overlays in one surface.

Document

The Document surface is for narrative around model state. It can show markdown or rich document content, bind to a live string body, and carry report-style themes.

Use it for memos, model explanations, operating notes, investment writeups, policy summaries, launch docs, and reports that need to sit next to the live calculation. Document makes the workbook readable to people who need context before cells.

In the App layer, Document keeps its editing tools and can receive an editable Chat excerpt through Keep in model. Its Insert menu can add links to other model views. App’s Brief starter creates a normal rich Document with chosen live references and ranges; these additions use the existing document editor, revision checks, recovery and Undo.

Import Word converts a local .docx file into editable document content, appending it without replacing existing writing. Headings, lists, tables, links, named styles, paragraph formatting, and supported embedded images are retained. Empty documents adopt imported page settings; appending keeps destination settings. Word pagination may differ. Imports can be canceled and undone. See the document editing guide for limits and compatibility.

Documents also provide named styles, paragraph formatting, Find/Replace, Heading 1–6 navigation, counts, zoom, and image width controls. Page setup controls exported paper, orientation, margins, headers, footers, and page numbers. Publish creates Word or PDF files and an exact PDF preview, freezing live values as text and tables. Unresolved values and incoming conflicts need attention before export. Unequal table widths, merged cells, repeating headers, numbering, and explicit page breaks survive supported Word round trips. Desktop exports use a native Save dialog; browser versions download files. The editor is a continuous writing view. Located notes identify conversion simplifications. Review adds anchored comments, replies, resolution, and tracked text edits with individual or bulk accept/reject and Undo. Discussion and supported text revisions survive reopening and Word exchange. PDF publishes proposed text without review markup. Formatting and structural changes are not tracked; reviewer names are labels, not authenticated collaboration identities. The rich editor keeps complete content immediately available, including dense documents. Formatting, search, word counts and Undo/Redo follow editor changes without rerendering the entire editor on every transaction. It exposes multiline textbox semantics and reflects changes in editing permission. Dense opening performance remains under development. Use /Image to insert an image URL and description. Cancel preserves the slash text; confirmation inserts one image with normal saved-draft recovery and Undo/Redo. Find and Outline temporarily reveal destinations inside collapsed toggles, including in read-only documents. These navigation reveals leave saved content and Undo history unchanged. Closing Find or Outline returns typing focus to visible content, or to its navigation control when all document text is collapsed. See Document navigation. See the document editing guide, publishing walkthrough, and review walkthrough.

Deck

Create a Deck to present model values alongside slide text, tables, and charts. Browse slides in App, choose Edit slides to author them, and use Present for an audience view. Live references stay connected to the model; exported slides capture the values at export time. See the Deck guide for presentation controls, export options, and their limitations.

Choose Freeform or give individual blocks custom percentage positions and sizes. Numeric controls and keyboard nudges arrange them; later blocks appear in front. Positions survive saves, Undo/Redo and the shared audience, print and editable PowerPoint scene. Invalid positions remain available for correction. Pointer and touch gestures preview movement or resizing, then save one acknowledged change on release. Escape cancels. Embedded MP4 videos play in presenter and audience views; print/PDF capture their poster, and PowerPoint exports retain the original video. Browser and PowerPoint codec support may differ. Import PowerPoint appends unchanged new Grid exports with the same appearance; values stay captured and source bindings remain inactive metadata. Files without a Grid payload can import a strict blank-layout subset of editable Arial text, embedded PNG/JPEG and styled rectangular tables. Source appearance and geometry survive save recovery and Undo/Redo; unsupported content rejects the whole file before writing. Captured and imported tables expose a full cell editor: select a cell, type an exact value and choose Apply cell. Each applied value uses the existing document save, recovery and Undo/Redo while preserving the other cells and source appearance. + Static table creates an editable table without a model binding. Native captured/static tables support row and column insertion and removal; imported table geometry stays fixed while its cell values remain editable. Unapplied values remain visible across read-only or changed-owner transitions in the mounted view. Audience video pauses when the presenter disconnects; playback after reconnection is explicit. General PowerPoint compatibility remains incomplete.

Notebook

The Notebook surface is a computational narrative over the resident Grid model. Its ordered blocks mix markdown, Grid formula assignments, live values and ranges, scenario inputs, WHY provenance traces, and commands from the interactive Grid CLI. Formula blocks do not start a second notebook kernel: submitting one edits the model source through the normal formula-write path, and its output then participates in the same reactive calculation graph as the rest of the workbook.

Use it for exploratory modeling, scenario labs, reproducible investigations, model validation, and handoffs where the reasoning matters alongside the answer. Live value and range blocks always resolve from model state. Command and provenance output can be persisted with the notebook so a printed or shared copy retains the evidence that produced the conclusion. Each execution stores a bounded receipt with its principal, status, duration, model revision, timestamp, and truncation state. Captured output is marked stale after the resident model advances. The backend reparses every request and enforces an effect allowlist: model-changing, administrative, raw-RPC, source-replacement, temporary-model evaluation, and streaming CLI commands are blocked inside notebook command blocks. Writes use typed input and formula blocks instead.

Formula writes are acknowledged and compare-and-swap guarded by the model source hash. A formula block durably owns its output symbol; another block or an existing source definition cannot be overwritten without an explicit Take over symbol action. Formula execution uses a dedicated Notebook route: the server derives the Notebook, block, and authenticated principal identities from the route and session, then injects ownership into the internal model-runtime request. The generic batch editor rejects client-supplied Notebook ownership metadata. Each formula attempt carries a persisted retry identity and returns the same principal-bound execution receipt when an ambiguous network retry reaches the same backend. Reusing that identity with different content is rejected as a conflict. Notebook document saves use the data symbol's request revision, serialize through a single queue, and preserve local edits when a remote revision wins. After a connection or server failure, Retry save resubmits the open draft with the same revision check. It does not override a conflicting revision; Load remote version is available when a newer notebook has arrived. Keep the notebook open until its status returns to saved. Production WHY runs are refused unless the runtime temporal ledger is enabled on durable storage.

Notebook is a dedicated surface rather than a mode inside Document because it owns execution and write semantics. It still follows the same surface lifecycle: native blocks live in Notebook_1!data, and Eject to code creates editable JSX. In the ejected snapshot, model reads and input controls remain live while native CLI and WHY results are labelled snapshots.

App’s Exploration starter creates a normal Notebook from selected inputs and results. Edit notebook exposes its writing and execution tools. Chat excerpts are appended as narrative and optional live-value blocks, never executable code. In a long notebook (80 or more blocks), the first block opens ready to edit and the rest remain readable. Click a block's content or use its Edit action to bring its editor and block controls into focus. The action appears on hover, keyboard focus, and touch. Shorter notebooks show their editors directly. Editing one block leaves unchanged blocks steady. Block ordering, keyboard movement, draft saving, and conflict handling retain their usual behavior. Initial opening of very large notebooks may still take longer than editing an open one.

Board

The Board surface is a freeform canvas for planning. It can hold text blocks, cards, embeds, and positioned items stored in the surface's data slot. It can also project bound card rows as read-only cards.

Use it for brainstorming, planning, model walkthroughs, lightweight dashboards, and mixed visual work where a grid is too rigid. Board is spatial and flexible: place the pieces where they help the story.

Layout

The Layout surface is a dashboard grid for values, notes, charts, tables, and shared filters. Blocks occupy authored rows and columns and read the same model.

Use it for operating dashboards, KPI panels, trading-terminal-style views, scenario summaries, and compact executive screens. Layout is more structured than Board and more dashboard-like than Sheet.

New layouts start empty. In App, View actions → Edit layout reveals Add value, Add note, Add chart, Add table, Add filter, Undo, and Redo. A value can contain literal text or a reference such as =Forecast; the latter follows the model and its display format. Notes remain authored text. Older layouts retain their existing seeds and saved blocks.

Drag a block header to move it or its corner to resize. With a block focused, Alt+Arrow moves it and Alt+Shift+Arrow resizes it; the focused resize handle also accepts Arrow keys. Overlaps are rejected, Escape cancels a drag, and a full canvas asks you to make space. Adding a block focuses its title. Delete removes the focused block, and Undo restores it and its selection.

Select a block and choose Duplicate selected block, click its copy icon, or press Ctrl/Cmd+D with the block focused. The copy keeps its size and settings and appears in the first free slot. Rename or edit it independently; its data bindings and shared-input links still point to the original model. Duplication does not create a second model input or a snapshot of computed data. A full canvas asks you to make space. Undo/redo preserves the copy's identity, and failed saves keep the copy for an explicit retry. Very large blocks (over 1 MiB of saved text and metadata) and layouts at 2,304 blocks explain the duplication limit. Try the duplication dashboard.

Done waits for the existing save path and returns focus to the selected block. Failed writes retain the draft; concurrent changes offer explicit recovery. App reading mode hides arrangement controls, keeps live values inspectable, and stacks blocks in row/column order on narrow windows. Arrangement keeps the authored grid and allows horizontal scrolling. Data retains its dense operational presentation.

Charts bind to existing row results; choose their chart type and axis fields in the selected block editor. Tables bind to row results or native table handles. Visible records page in groups of 25, and partial native results show Load more. Print labels incomplete data. Charts admit at most 10,000 rows.

A shared filter edits a declared scalar model input. A chart or table can also send its selected record field to a declared input. Native formulas use those inputs to update every linked block. Saves require the native revision receipt; failed filter drafts remain available for an explicit retry. Author the inputs and filtering formulas in Code; selecting records does not invent a browser query. See the linked sales example.

Kanban

The Kanban surface is a workflow board. It can own cards directly in !data, or project cards from bound rows grouped by a status field. Columns carry titles, colors, and optional work-in-progress limits.

Use it for tasks, sales stages, recruiting pipelines, editorial workflows, incident response, model review queues, and any process that moves through states.

The board waits for valid saved configuration before choosing its card source. For a board that owns its cards, edits save to !data in order. The save notice confirms a matching saved response before declaring success. A refused or uncertain save keeps the latest local board and pauses further changes. Export board copy keeps its JSON; Retry local board save explicitly tries the same guarded revision; Load saved board… asks before replacing the local copy. Reopening the board in the same session retains unresolved changes; this is not recovery after closing or crashing the application.

Local editing supports up to 5,000 cards and 8 MiB of board JSON, preserving unknown metadata. Missing, unreadable or newer-format data cannot be replaced with starter cards. Only an explicitly ready blank board starts with sample cards. Print lays out every list without scrolling, uses a white page in either theme, and labels unconfirmed local changes. See the local recovery example. Column configuration has its own acknowledged writer: failed or uncertain setup changes retain a copy for export, explicit retry or confirmed saved-copy recovery. Removing a populated list keeps its cards under Unmapped cards with their original IDs.

Local boards and named-array views keep cards visible when their stored list ID is absent from the configuration. Open Unmapped cards to inspect them; each card shows its original list ID. The card editor displays Unmapped: … until you deliberately choose a configured list. Opening makes no data changes. Local reassignment uses the same acknowledged card-save and recovery owner; named-array writes use the guarded receipt contract below. Print includes these cards and their retained details. See the unmapped-card example.

Named-array cards need a unique nonempty text or safe-integer id before they can be edited. Text "1" and integer 1 are separate identities; reordering retains the same card. Legacy or lossy arrays remain readable. Edits preserve unrelated fields and wait for a ready, advancing input receipt matching the exact binding and proposed content. A failed or uncertain save keeps the local cards for export, explicit retry or confirmed saved-copy recovery in the current session. No uncertain write replays automatically. See card identity and configuration recovery and the named-array example.

Named-array boards also create cards with stable text IDs through Add a card and reorder source rows within a list by drag or Control/Command+Up/Down. Existing records and their unrelated fields survive. Failed creates/reorders retain the complete local array; refused creates keep the composer title. Order is shared with other views of the same source array.

Moving a bound card between columns writes its new status through its owning model transaction. Cards can be dragged or moved by keyboard and edited through a modal. The bound records remain the durable source.

A native Table binding uses the same records as Table. Explicit pages contain up to 100 cards, and list counts cover that page. Create, edit, move and delete wait for a native mutation receipt. Each guarded change preserves its exact record ID and compares the retained values it will change; unrelated fields survive concurrent edits. Conflicts retain the draft for review and explicit retry. Deletion requires confirmation. Map title, status, assignee, due date, labels, description and color to their native columns. See the Table-backed board example.

For native cards, add a separate text column for activity and map it with items.activity = "activity" in the board configuration. Activity for … opens that card's files, conversation and history. An enabled board pages 10 cards at a time. Cards without this mapping keep the ordinary board workflow.

Upload attachment stores a file in the workbook's Files. Attach uploaded file then saves its reference to the card. If the second save fails, the file and retained draft remain available; do not upload another copy merely because the card could not be confirmed saved. Downloads verify the saved size and fingerprint. Removing a reference leaves its file in Files. File transfers are limited to 25 MiB; each card can retain 100 references, 500 comments and 1,000 history events within 1 MiB of activity data.

Comments and card changes are saved through guarded native record updates. Refresh saved card reads newer activity without replaying a failed write; Load saved activity… asks before discarding the retained local copy. Export activity first to keep that copy. Names are display labels and times come from the author's device. Comments send no notifications. History covers Kanban changes after activity was enabled, including before/after values for edited fields; it is not an audit of other Table or Code edits. No history is silently trimmed: export it before explicitly resetting full activity in Table or Code.

Closing and reopening keeps acknowledged activity. Unsubmitted text is not a durable draft, and session recovery is not a browser-crash guarantee. Permanent card deletion also deletes its conversation/history but leaves file bytes in Files. Print includes all activity for the loaded page, with partial-page labels when more native records exist. Local-board and named-array cards also support explicit activity mappings: their acknowledged document/array owner saves conversation, attachment references and retained history. Completed detail edits produce one history event, and array history uses the actual mapped source fields. Their print views include all retained activity. Card activity settings in the workbench enables or changes the mapping without changing card data or migrating old history; native setup selects an existing separate text column. See the native card activity example, the local example and the array workflow.

Choose Find cards to search the loaded board's full descriptions, titles, people, labels, lists and checklist text. It opens the existing editor when writes are available, or complete read-only details as a captured snapshot. Search keeps board order, counts and print intact. Native Table Find explicitly covers its current loaded page. Search Table cards searches compatible mapped text fields across the native Table or saved view in bounded pages, and opens exact records through the existing guarded editor or read-only details. See Find and inspect Kanban cards.

Diagram

The Diagram surface is a node-link canvas. It can own editable nodes and edges or project them from bound node and edge row sources.

Use it for dependency maps, system diagrams, org relationships, process flows, network analysis, scenario graphs, and any model where relationships are easier to see as connected nodes than as rows.

For an editable local diagram, Shift-select nodes and choose Group selection to put them in a named container. Drag its header to move the contents together. Select a group and another node or group to create a nested container. Ungroup and deleting a container keep its contents and connections in place. Saved groups survive reopening, printing, auto-layout, and JSX snapshot export. Grouped documents require a reader supporting Diagram data version 2; an older reader will refuse them. Bound node/edge rows keep their read-only ownership. Try the grouped workflow example.

Explore graph opens a read-only workspace for searching nodes, inspecting their original properties, filtering visible relationships, and expanding incoming or outgoing neighbors. Follow directed connections to build a highlighted walk; this is an inspection trace, not a shortest-path calculation. Close exploration to return to the full authored diagram and its editing tools.

The exploration canvas displays up to 500 nodes and 2,000 edges, with paged record lists and explicit omission counts. Load model paths reads retained native path reports with their costs, algorithms, source identities, and revisions. Those reports remain separate from the row projection unless their identity can be established. Matching labels alone do not establish that link. See the service graph example.

Sketch

The Sketch surface is a parametric two-dimensional engineering canvas. It owns stable line, circle, and arc entities plus their geometric and dimensional constraints in !data. Dimensions can be driven by live model symbols, so a sheet edit regenerates the geometry; editing a bound input dimension in the inspector writes through the normal model input path.

Use it for profiles, plates, layouts, mechanisms, tolerance studies, design tables, manufacturing outlines, and spatial engineering models where geometry must stay connected to calculations. The native inspector reports degrees of freedom, constraint residuals, bounds, path length, and areas, and exports SVG or DXF as advisory browser previews, not manufacturing files. Named design configurations overlay unbound dimensions and expose an explicit native comparison of measured outputs; model-bound dimensions keep external ownership and cannot be shadowed by a configuration.

When the active solid result supplies mass properties, enter a target such as MassSnapshot under Publish mass properties to cell, then choose Publish properties. Query the saved result with ordinary formulas:

solid_volume = CAD_VOLUME(MassSnapshot)
solid_area = CAD_SURFACE_AREA(MassSnapshot)
solid_center = CAD_CENTER_OF_MASS(MassSnapshot)

This publishes a persisted, revision-pinned cad_mass_properties_snapshot; it does not keep a process-local solid handle or automatically republish on later Sketch edits. After changing the design, inspect the newly computed properties and publish again deliberately. CAD_MASS_PROPERTIES validates a snapshot, and the query functions accept an optional expected source-revision string when the consuming calculation must require an exact revision. Volume and area carry dimensions; center of mass is a dimensional three-coordinate vector. Unavailable or uncertifiable area/center results return #N/A, not a fabricated zero.

Experimental source-owned CAD editor

The source pane's CAD tab is separate from the Sketch canvas. It provides an explicitly selected, experimental workflow for a reusable millimeter rectangular pad: author an imported part, edit its depth input or width argument, regenerate and save, reopen its saved checkpoint, measure, and download revision-matched STEP. This is not general programmable CAD support or a claim of manufacturing validation.

Load saved source deliberately. Use the library editor for the reusable part, then Regenerate and save source for the root model. Measurements and STEP downloads use the confirmed saved revision and are unavailable while drafts are unsaved. A conflicting or unconfirmed edit requires reloading rather than assuming the save succeeded. After a restart, explicitly reopen the saved checkpoint; an already-live reopen refusal is not a successful reopen.

The checkpoint is not a new portable Grid-document archive. Refreshing a pinned import is not available in this editor. Its drafts are local: switching models or closing the workspace does not preserve them. Copy unfinished work before leaving. Source-view tab changes ask before discarding a draft or active operation. Other geometry operations retain their individual support limits.

Analysis

Use Analysis to inspect finite-element regions already authored in model source. Add the surface, choose Resolve regions, then select a region, field, and component. Inspect convergence/status and units before interpreting the color plot; the field table and mesh are bounded previews, not proof that every entity is visible.

Add a probe by entity index, or select a displayed node for a node field. Region, field/component selection, and bounded probes are saved with the tab. In the development workbench, a populated selected region offers Edit native definition. It opens the complete native mesh/problem with material, load and boundary controls, paged mesh fields, a native rectangle generator and draft-only JSON mesh transfer. Solve and save definition submits the complete guarded definition through the existing native solver. Code remains available for source authoring, changing physics and creating new weak-form expressions. Displaying a result does not make an unconverged solve converged.

The viewer requests geometry belonging to the same native result. A refined mesh takes priority; otherwise the original mesh is admitted only when its region, mesh, problem and result handles match. The original preview is bounded to 4,096 nodes, 8,192 elements/facets and 1 MiB of encoded mesh. A stale identity or bound refusal keeps numerical results visible and explains why geometry is unavailable. Ordinary FEM resolves do not request this optional projection.

Plate conduction is a complete native source-JSON model with an Analysis tab, a 64×32 triangular rectangle, conductivity, and marked boundary values. Its steady temperature field is linear from the left edge to the right edge. This example exercises the existing native solver. The visual editor and native save path are implemented in development; updated-host end-to-end saving remains unverified.

A saved region, field location or component that is no longer available stays explicitly unavailable; the viewer does not substitute another numerical result. Choose an available region/field/component deliberately to change the selection. Retained probes keep their exact identities, including when all regions vanish; an absent, ambiguous or incompatible field/component displays unavailable. Print retains these identities and probes without replacement controls. Opening never repairs the viewer document. See Retained Analysis selection, a viewer-state example with no FEM solve. Viewer edits require a matching, advancing save response. Failed or uncertain saves retain local selections and probes through reopening in the same running session, and stop queued writes. Under Analysis changes need review, export a local viewer copy before choosing Load saved viewer…. Keep local changes cancels replacement; confirming discards the local draft and adopts the current ready saved snapshot. Refresh does not silently retry a failed write. Recovery is scoped to the backend/account, model, partition and surface; it is not disk or restart recovery. The definition editor keeps up to eight unfinished region drafts in the running session, with one active editor per draft. Export local definition copy retains unfinished values outside the session. A failed or uncertain definition save keeps its draft and blocks replay; Load saved definition… requires deliberate replacement. Import recovery copy… accepts an exported definition copy up to 4 MiB, including unfinished numeric and rectangle values. Confirm replacement of the current local draft; the editor checks a fresh saved definition against the copy's model, source, region, handles and complete saved content. Changed saved content refuses replacement and keeps your current draft. When the content matches after an owner restart, later explicit saves use the freshly inspected owner. Import itself does not solve or save. These are separate from the viewer selection/probe document. A matching confirmed native precommit validation or convergence refusal keeps the draft editable for correction and another explicit save. Attempted writes or missing/mismatched acknowledgements still require deliberate inspection.

The repaired native host preserves accepted definitions, ordinary inputs and viewer data across graceful restart and archive restore. Existing saved Analysis definitions with numeric material keys reopen without rewriting their records. Eleven real native HTTP lifecycle groups and two earlier-record reopening checks cover this bounded workflow. Full-App populated browser authoring, broader workbook/process-cache coherence, power-loss and selected latency/resource verification remain outstanding. Automatic draft retention is session-local; exported definition copies support deliberate frontend recovery. Changing physics and creating a new weak-form AST are not implemented.

Requirements

Open a saved model, add Requirements, and Import ReqIF from a bounded ReqIF 1.2/1.2.1 document or a single-document ReqIFZ archive. Use Requirements, Traceability, and Verification views to inspect paged objects, typed attributes, hierarchy, links, and conflicting evidence. Select a requirement to record verification with its method, observation time, and evidence references when write access permits. Export ReqIF exports the normalized artifact, not arbitrary embedded archive content.

In the Requirements view, select an object and choose Edit requirement to change its title, description, and typed attributes. Attribute controls retain stable definition and enumeration IDs; Use default / unset removes an explicit value. Integer values retain their full signed 64-bit precision. Date edits accept calendar-valid timestamps such as 2026-10-01T14:30:00Z. Editing an XHTML field replaces its formatting with safe plain text; untouched rich text remains intact. Imported read-only flags and datatype bounds are enforced by the native owner.

Enable Move or reorder a placement to choose one hierarchy node, its new parent or specification, and a zero-based insertion position after removal. The node and its descendants move together; other placements of the same requirement remain distinct. Cycles and invalid positions are refused. The hierarchy editor is bounded to 2,000 placements and specifications; attribute editing remains available for larger documents within its own projection budget.

Every edit creates an immutable version under the existing Requirements head. Concurrent saves against an older head fail instead of overwriting content. Changed content or placement ancestry clears current verification for affected requirements while historical versions retain their evidence. Change impact includes hierarchy moves and sibling order. A lost response retains the draft: use Check current saved version before opening the saved head. If only the workspace reference failed, Save workspace reference retries that save without repeating the native edit. Drafts remain local to the open session; copy retained drafts before closing it.

Under Baselines & change impact, name and publish a baseline of the current artifact. After importing or creating the changed state, enter the exact before and after artifact IDs and choose Publish change impact. Inspect changed identifiers and suspect links; retain the resulting artifact references for review. Baselines and structural comparisons do not confer approval, signoff, promotion, or release status. Those are separate authorized workflows.

The formal Requirements signoff workflow, when installed and configured, requires the exact baseline and complete matching impact report, reviewer submission, then a different approver's reason and trusted signature. An incomplete/truncated comparison cannot be used as complete signoff evidence. The resulting workflow record remains tied to those artifacts; subsequent changes do not inherit approval.

Engineering

Use Engineering to inspect imported engineering files without executing them. Choose the IFC, FMU, or PCB view, select the corresponding file, and import or inspect it. The tab retains the artifact reference and selected view, so reopening it reads the same normalized artifact rather than reparsing an untracked browser file.

IFC inspection exposes normalized building entities; FMU inspection exposes model metadata and variables without loading its executable code; PCB inspection handles the supported Gerber/Excellon input. Browser import ceilings are 256 MiB for IFC, 64 MiB for FMU, and 32 MiB for PCB, with bounded previews. This surface is not an IFC geometry editor, FMU simulation runner, electrical design-rule checker, router, CAM tool, or fabrication/machine controller.

Browser

Use Browser in Grid Desktop to open an HTTP or HTTPS page in an isolated native session. Enter a URL in the location bar, browse normally, then use the automation panel when model or agent work needs page state. A surface address such as dom:main h1 reads the first matching element, dom:all:a[href] returns a bounded list, and storage:local:theme reads one local-storage value for the current origin. page:url, page:title, page:html, and page:text address main-frame state.

Programmatic callers use the same surface variable to navigate, query, click, fill, focus, and read or update local/session storage. Prefer stable CSS selectors and semantic attributes over layout coordinates. DOM and storage results are snapshots at call time; read again after navigation or page script mutates the document.

Programmatic automation uses the same surface-scoped handle as the toolbar. It supports redirect- and hash-route-aware goto, settled back/forward/reload, bounded load/selector waits, CSS query/count, visibility and computed-style inspection, click/fill/focus/hover/keyboard, checkbox and select controls, scrolling, history, reload, storage mutation, and explicit session close. Element results include control state, visibility, and viewport geometry; no coordinate synthesis or arbitrary page-script evaluation is required. Selector actions wait up to five seconds for the element to become attached and actionable instead of silently returning false while a page is still rendering; callers can override that bound with timeoutMs, up to 30 seconds. DOM, page, computed-style, storage, and formula-snapshot results are byte-budgeted inside the page before crossing the native bridge; large queryAll results return the bounded document-order prefix rather than first allocating an unbounded payload. Direct page:html reads share the formula snapshot's live-control capture and password redaction. Selecting a missing option—or multiple distinct values on a single-select control—is an explicit error, not a silent empty selection.

State-changing calls on one Browser session are deliberately serial: await one navigation, wait, element action, or storage mutation before starting the next. An overlapping stateful call is rejected clearly instead of racing the live page, and the native host does not retain an unbounded queue of pending automation. Immediate queries remain point-in-time reads and can run alongside revision polling and window layout.

Cells read the Browser's captured developer-panel state through its data slot. For example, BROWSER_READ(Browser_1!data, "dom:main h1") returns the first matching DOM node, DOM_TEXT(...) extracts its text, BROWSER_QUERY_ALL(Browser_1!data, "a[href]") returns matching links, and BROWSER_STORAGE(Browser_1!data, "local", "theme") reads an exact storage key. Completed navigation and automation publish a bounded snapshot; use Capture for cells for an immediate manual refresh. While the Browser is visible, page-script DOM changes, form interaction, and same-document history changes are detected and republished after a short debounce. Web Storage is included—and its mutations are observed—in that persistent snapshot only when [browser] formula_storage = true; live storage remains queryable through the surface handle without enabling it.

The default session is incognito and lasts only for the desktop process. It does not share Grid's signed-in WebView profile. On macOS 14 or later, set [browser] incognito = false to retain cookies and persistent site storage on this device in a separate profile for the workbench and model/surface identity. Sign-in popups use that surface's profile. Other surfaces and workbenches stay separate. Close the existing surface before changing its incognito setting; Windows, Linux and older macOS explicitly refuse persistence.

Reopening a persistent surface loads the configured start page with retained site data. It does not restore tab history, DOM state or sessionStorage. Changing the model/surface identity or workbench selects another profile. Closing or deleting a surface retains its local website data. These profiles do not travel with a gridoc; portable browser Save/Resume remains unfinished.

Up to eight Browser sessions retain their in-memory state while hidden. Opening another releases the least-recently-used hidden session unless it is running automation; revisiting a released surface starts a new page at its configured URL, retaining persistent site data when selected, while the last captured cell snapshot remains available until the new session publishes a replacement. If the surface is still open in the workbench, it shows Reopen fresh session for a private session, or Reopen session for a persistent session, as soon as the native host releases its hidden WebView, rather than leaving its controls bound to a stale session. Deleting a Browser surface closes its session immediately, cancelling any call still using that deleted page. The workbook receives only the bounded formula snapshot (URL, title, ready state, and bounded HTML/text, plus explicitly admitted Web Storage). Password-control values are redacted from snapshots and DOM-query results. Cookies—including HttpOnly cookies—and history are intentionally excluded. Direct, redirected, clicked, and popup navigation all share the same credential-free HTTP(S) and normalized-URL size policy. Browser surfaces cannot run in the web client or print output; those contexts show a capability or static-content notice instead of silently substituting an iframe.

The explicit live QA harness in tools/qa/browser-surface/ can drive an already-built Desktop executable against a deterministic loopback page and preserve a no-overwrite result bound to that executable's SHA-256. Its checks cover page and CSS addresses, password redaction, DOM mutation, forms, local and session storage, captured HTML, history, frame boundaries, popup containment, the eight-session resident limit, least-recently-used eviction, and isolated recovery. No completed packaged-product run is recorded in this working tree; new product bytes require their own driven qualification.

Industrial

Bind the surface's assets, telemetry, alarms, work orders, and maintenance collections to normalized model rows or tables. Start with Overview, select an asset or alarm for detail, and use Refresh endpoint status to inspect declared connector health. Missing or unavailable status is not evidence that equipment is healthy.

Supervisory actions require a configured action and an explicitly authorized host bridge. The default workbook host does not grant those action bridges. When one is available, select its target, click the action, review its confirmation, then choose Confirm manual action. Refresh, telemetry changes, and timers never trigger it. Adding this surface does not install a control loop or grant industrial write authority.

Sequence

Use Sequence for resident references, reads, alignments, and related artifacts. Import browser text formats FASTA, FASTQ, SAM, or Matrix Market, or select a supported file already in the model's Files area. Browser imports are bounded to 60 MiB. Binary BAM and H5AD use the linked-asset path, not the text upload path; backend support is still required.

Select the imported artifact, inspect its identity/summary, then choose an operation available for that artifact kind. Examples include a sequence sketch, mapping index, reading-frame translation, open-reading-frame search, and alignment. Mapping reads requires the reference and its index as explicit dependencies. Follow the job status and select the resulting artifact; importing a file alone does not run every analysis.

Explore reads, annotations and samples links a reference window with explicitly selected read, annotation, and variant artifacts. Reads that begin before the window but overlap it remain visible. Inspect recorded CIGAR blocks, strand, mapping quality, annotations, and exact coordinates; select a record to focus its locus across tracks. Each track has independent bounded pages. Matching contig names alone do not prove a shared reference assembly.

Variant

Use Variant for a bounded genomic region and variant artifacts. Import VCF text (up to 60 MiB through the browser), or use supported linked VCF/BCF data. Select the exact artifact and set the contig and start/end coordinates for the region view. A bounded result page does not represent the entire cohort.

Call variants from alignments is an explicit operation: supply the reference-sequence and read-alignment artifacts, run it, and inspect the resulting artifact and job outcome. A VCF import does not infer missing reference provenance, run a caller automatically, or establish clinical interpretation.

The linked inspector shows named sample genotype columns, preserving phased, unphased, multiallelic, and missing values. Sample and record pages are explicit; the browser shows eight sample columns at once and a region of at most 100,000 bases. It does not infer coverage or variant effects. Inspection and region selection do not mutate the scientific artifacts. See the synthetic genomic example.

Molecule

Use Molecule to inspect chemical graphs, structures, and trajectories. Import SMILES, SDF, MOL2, PDB, or mmCIF text, or select a supported model asset; browser text imports are bounded to 60 MiB. Select the artifact and, where applicable, the structure model or trajectory frame.

The 3-D viewer displays native element identities, recorded bond orders, and ball-and-stick, sticks, or atoms representations. Rotate, pan, and zoom; inspect an atom's recorded charge, isotope, chain, residue, and coordinates. Atom sizes are illustrative. Position windows admit 10,000 atoms and 20,000 bonds at once and disclose omitted or invalid geometry; larger windows use a canvas renderer.

Trajectory playback starts only on request and reads one frame at a time. Pause, manual navigation, errors, the final frame, hiding the document, and print stop playback. Native harmonic dynamics lineage can provide verified topology; other trajectories remain explicitly coordinate-only when their topology cannot be established. Automatic playback is limited to artifacts with recorded counts of at most 10,000 atoms and 16 MiB; larger trajectories retain manual frame navigation. See the molecular inspection example.

Operations depend on artifact kind: molecule sets offer fingerprints, conformers, and ligand docking; structures offer dynamics preparation or receptor docking; fingerprint sets offer comparison/screening; prepared dynamics systems can run dynamics; trajectories can be analyzed. Choose the required receptor, ligand, or comparison artifact explicitly and follow the job result. Availability depends on the installed scientific capability; a viewer or artifact row alone does not establish backend availability or scientific validity. Research Workspace is a separate context-aware workspace, not an automatic side effect of these operations.

Molecule sets and structures also offer Calculate calibrated properties. Choose the RDKit descriptor set, Crippen log P, or fragment polar surface area explicitly. The interface checks property-adapter registration on selection; the submitted job confirms method support and runtime permission. Saved results show units, missing descriptors, warnings, backend/version, and execution provenance, with 50 molecules per page and full JSON download. Reopening results does not rerun the adapter. See the computational chemistry guide.

Canvas

Use Canvas to display a computed drawing or image, rather than manually edit a Sketch. Set source.bind to a cell holding a DRAW_* drawing, a supported DRAW_TO_SVG result, or numerical pixels produced by DRAW_RENDER/IMAGE_*. The view refreshes when the bound value changes.

For numerical pixels, pixels.mode = "gray" reads grayscale intensities and "rgb" reads packed RGB colors. layout.fit chooses "contain" or "actual"; show_checkerboard controls the background. Nothing to render means the binding is missing or its value is not a supported drawing/pixel shape. Correct the producing formula or binding instead of pasting arbitrary HTML into the canvas.

Score

Use Score to engrave, play and edit music notation. Set source.bind to a cell holding a score from MUSIC_SCORE, a music"…" literal, MUSIC_FROM_NOTES or MUSIC_FROM_MUSICXML. The surface engraves it as publication-style notation with beams, accidentals, ties, slurs, tuplets, dynamics, lyrics and chord symbols. Page view breaks systems onto pages; Panorama shows one long line. Play previews the score from the selected measure with a moving playhead, and Parts shows the full score or one part.

Set source.edit to the writable input that holds the score's notation text to edit by keyboard: select a note, then type A–G to insert, ↑/↓ to move by a step, 1–8 for note values, . for a dot and T for a tie. Each change rewrites that note in the input and the model recalculates. A transposed or imported score is read-only, with the reason shown. Warnings such as an overfull measure are listed below the score. Transposing instruments read at written pitch, with a Concert pitch toggle, and notes outside an instrument's range are drawn in red.

Mixer sets each part's volume, mute and solo for the preview and for rendered audio. layout.page, layout.orientation, layout.staff_size and layout.margin set the paper, staff height and margins of the page view, and layout.hide_empty_staves leaves resting staves out of each system after the first.

Render audio writes the performance to a WAV file in the model's Files (playback.audio, or renders/<cell>.wav), and Sound then plays either the browser preview or that file. Name a SoundFont (.sf2) from the model's Files in playback.soundfont to render with its recorded instruments instead of the built-in sounds. Export MIDI writes a Standard MIDI File beside it for sequencers and other notation programs. Import MusicXML converts a .musicxml, .xml or .mxl file into the notation input, after confirmation, so scores from other notation software become editable. Bind a Media surface to the same file to inspect its waveform and spectrum and annotate it; while either surface plays the file the other follows, and choosing a note seeks Media to that measure. See Music Notation for the notation and the MUSIC_* functions.

Experiments

Use Experiments to compare simulation candidates without editing the live model's inputs for every trial. In Design, name the experiment, select Time simulation, Discrete event, or Spatial agents, choose outputs, and supply the relevant step/integrator or region settings. Time-simulation sweeps use a full-factorial product of explicit values or linear ranges and scenarios; other design-of-experiments algorithms are not implied. Review the expanded matrix size before running it.

In Runs & comparison, follow the queue, inspect failures and compare summaries without rerunning. Inspect original output reads the retained time simulation, discrete-event or spatial-agent result without executing the model again. Older records without an original payload explain that limitation. Verified replay remains a separate explicit action for supported time-simulation rows. Publish evidence retains the original evidence; Graduate creates the explicitly named model branch. Neither action approves or releases a model.

In Calibration, choose the loss, bounded parameters, tolerance, iteration limit and optional residual output symbols. Start a retained calibration to follow bounded iteration/evaluation progress or cancel while keeping its checkpoint. Reopen completed runs to inspect the original optimum, trace and authored residuals, separately from objective loss, then publish that same result without rerunning. Workbook archives retain terminal journals and original evidence; active jobs must settle before export. Imported published records must agree with their immutable payloads. Archive and selected-cost verification are tracked in the built-in surface completion ledger. This simulation-fitting workflow is distinct from Predict's calibrated upper-P90 model bounds. See simulation authoring for model and replay semantics.

Discussion

The Discussion surface renders chat or forum-style conversation from bound rows or its own messages. It maps author, body, timestamp, thread, and reply fields when present. An authored local thread saves to the surface's !data document; a named-array binding writes through the model's input owner.

A native Table binding posts messages through the same record mutation path as Table. The composer waits for an insertion receipt, then refreshes the messages. Incoming table revisions keep an unsent draft intact. A failed or uncertain send retains the draft: refresh and check the thread before sending again. A failed refresh after an acknowledged post can be retried without repeating that post.

Table reads load the newest 100 messages by the mapped timestamp and display the loaded conversation from oldest to newest. Search checks loaded messages only; use Load more messages for older entries. Posting through a saved view appends to its source table, so the view's filter may hide the new record. The table schema and host permissions still govern accepted writes. Print is read-only.

In explicit shared mode, native attribution identifies the signed account for the exact message version separately from its editable author label. Only that account may edit the attributed version. The original version and edit intent are retained before dispatch. An unresolved acknowledgement keeps the active editor and its text visible; reload recovers the retained intent after shared inspection. Inspect original edit receipt observes the original native transaction without repeating it. A missing receipt permits an explicit retry of that same intent. A changed account, original version or unsupported recovery record refuses the edit. Historical author labels grant no edit authority.

Edit a message through its existing owner and keep the draft if a save fails or the original text changes. Native table edits guard the exact record and body, preserving unrelated columns. Mentions use @name or @[Full Name]; the participant picker draws from loaded messages. Choose Viewing as to filter mentions and unread messages, then Mark loaded messages read explicitly. Read status belongs to that viewer and discussion in this browser, retaining up to 3,000 read message versions within a 2 MiB loaded-text budget. Edited messages become unread again. A viewer name does not sign in, and a mention does not send a notification. Storage failures are shown without losing edits.

For a native table, Open shared collaboration explicitly selects account-based reactions and read status. The host must provide signed identity transport, and your account must have model editor access. Inspecting the thread does not join it: choose Join shared discussion before reacting or marking messages read. The signed account is displayed separately from writable message author names. Shared read versions survive native restart and workbook archive restoration. Use Refresh shared state to reconcile another session; there is no background polling. Collaboration supports the recent page of at most 100 text-backed messages within 2 MiB. If more pages are loaded, refresh messages to return to the recent page before using shared actions.

To notify someone, choose a loaded Message and a joined Recipient, then Send inbox notification. This creates an in-app shared inbox delivery; mention text alone still sends nothing. Open Shared inbox explicitly and acknowledge individual notifications. An inbox acknowledgement does not mark the message read. Older notifications have a separate bounded page control.

If a delivery is not acknowledged, its original intent remains in browser storage. Closing and reopening shared collaboration never resends it. Choose Inspect notification receipt; only an explicit missing-receipt result enables Retry original notification, which uses the same identity. Recovery also offers Cancel unresolved notification. The host either returns the already committed delivery or durably fences that original intent before the browser clears it. A failed cancellation keeps the intent for reconciliation; this action also works when the original message is no longer loaded or exists only as an older version. Cancellation does not retract an accepted notification. Notification preparation refuses unavailable storage. Signing in as another account refuses pending actions until you close and reopen shared collaboration. Message drafts remain intact while opening and closing these controls.

Message posting and editing continue through the source table owner. Shared collaboration does not authenticate existing author labels or add authenticated posting receipts. Dense-opening, broader resource and packaged/full-workbook verification remain open in the workflow ledger.

The table-backed review example opens Discussion and Table over the same Comments records.

Use it for model review, operational notes, comment streams, decision logs, and collaborative context. Discussion keeps conversation close to the model state it is about.

Custom UI Surfaces

Custom surfaces are for model-specific applications. They let a workbook carry its own UI layer: forms, dashboards, workflow tools, calculators, decision screens, or embedded mini-apps that read from and write to the model.

There are two custom UI paths:

App surfaces are the lower-code path. They are useful when you want to assemble a screen from standard UI blocks, bind those blocks to model values, and keep the interface editable by model authors.

Component surfaces are the code-first path. They are useful when the surface needs custom layout, custom interaction, or React ecosystem components. A Component can read live model values, render them through React, and write back to allowed model symbols.

Custom UI availability is a deployment trust decision expressed as one setting: VITE_GRID_CUSTOM_UI_TRUST = off | trusted | sandboxed-only. off disables every custom-UI runtime (including packaged app takeover); trusted enables them all — the single-author / trusted-team posture; sandboxed-only disables in-process JSX evaluation (Component surfaces and ejected built-ins) while keeping the App builder's no-eval interpreter and sandboxed packaged apps — the multi-tenant posture. When the policy is unset, the legacy VITE_GRID_COMPONENT_SURFACE / VITE_GRID_APP_SURFACE flags keep their existing behavior. Public embeds never evaluate in-process JSX regardless of the policy. Disabled runtimes keep their surface data; the tabs render an explanatory notice instead.

Packaged desktop builds default this policy to sandboxed-only. That makes the no-eval App builder and Publish Grid App available in the desktop product without trusting authored Component JSX. A desktop product build may still set an explicit supported policy when its deployment boundary calls for off or trusted; invalid values fail the build instead of silently disabling the builder through the legacy fallback.

One model-binding ABI

Every custom-UI runtime speaks the same verb set — the grid:model-ui:v1 model-binding ABI: read verbs (model.symbols, model.range, model.subscribe), write verbs (model.setInput, model.setBatchInput, model.setFormula), route/context verbs (app.location, app.setPath, app.setContext), and command verbs (job.run, connector.call). There are two transports: packaged apps speak it over postMessage through the host shell, and Component surfaces bind it in-process over the live symbol store. The generated package client derives its method table from the shared ABI module at publish time, and a conformance suite drives the packaged client and the reference client through identical wire sequences, so the runtimes cannot drift apart.

Grid Views also uses app.formatValues for bounded presentation of supplied scalar values with the native TEXT formatter. It accepts no model id, source or formula, reads no model state and grants no write capability. The same operation serves the workbench and private copies. Older hosts return a concrete unavailable-format notice; the renderer retains the original values for actions and numeric sorting.

In the App layer, model.setContext?.({ symbol, title?, description? }) in Component JSX, or await grid.setContext(...) in a packaged app, selects a model value in Grid's Context panel. null clears it. The host resolves the live value; the contribution cannot provide values or callbacks. Symbol, title, and description limits are 256, 160, and 1,200 characters respectively. Packaged contributions require model.read; an unavailable host returns an explicit connector error. Selection is scoped to the current model, view, and app route.

Capabilities are one schema everywhere: verb scopes (model.read, model.write, app.route, job.run, connector.call) plus per-symbol bindings.reads / bindings.writes. A Component surface declares them in its !config; a published package carries them in ui/manifest.json; the App builder's capability review renders them before publish. Writes are enforced at every execution point with the same guard: the Component runtime blocks undeclared writes in-process, and the packaged-app host shell rejects writes outside the manifest allowlist (write_denied) even when the coarse model.write capability was granted. The command verbs are capability-gated end to end; hosts that expose no job runner or connector bridge answer method_unavailable rather than pretending.

App

An App surface is a structured builder for custom model UI. It stores a tree of UI blocks in !data, mirrors declared reads and writes into !config, and can run in a preview mode against live model bindings. The App document is now an app-level structure, not only one component tree: it can contain pages, each with a title, package-relative path, and root component tree. The active page is mirrored into the legacy root field so older single-page App surfaces still render and publish.

Large App outlines use a scrolling viewport, with keyboard and range selection across the full expanded tree. The canvas and Preview continue to include every component. Initial loading avoids replaying an already loaded document; recovered drafts, later model updates and Undo/Redo retain their normal behavior.

Svelte, Vue and Solid downloads preserve supported layouts and live GridClient bindings. Subscriptions move to replacement clients and discard old callbacks. Job and connector buttons preserve their authored JSON payloads, wait for completion before success feedback or navigation, and suppress late success after connection or component-lifetime changes. The downloaded source retains no model rows, files or native runtime; its embedding host supplies those capabilities. Successful external operations retain a mounted continuation so an uncertain feedback save or failed route can be resumed without launching the operation again. Feedback writes require matching receipts before navigation. Exported Toggle, Select, Segmented control, Slider and Date input controls also wait for matching receipts and retain failed or newer pending choices. Explicit Save, Use current value and Reapply draft preserve intent across changed connections or revisions. Date/datetime metadata remains attached to date writes, including after a reset. Clearing an optional date restores its declared default, which can be nonblank. Exported Table selection retains original source indices through filtering, sorting and local paging. Table/Detail identities distinguish numeric and text keys, and mouse or keyboard selection waits for the same acknowledged-save lane. Exported Tabs and Accordion panels follow acknowledged text selections. A pending choice retains its own Save and recovery controls; failed or unknown values do not silently select another panel. Tabs support arrow-key navigation, and closing an Accordion writes an empty text selection. Exported Modal, Drawer and Menu visibility follows acknowledged Boolean state. Close failures retain reachable recovery controls inside the open panel; closed-panel recovery stays visible. Keyboard and focus behavior preserves text editing and outside focus destinations, and discards late focus work after connection changes or unmount. Exported Nav honors home inclusion and distinct tabs, pills or list appearance. See App export fidelity.

Use App when the user wants a custom screen but still benefits from a visual composition model: metrics, inputs, cards, rows, lists, buttons, and repeated sections. The builder is direct-manipulation: drag blocks into place, multi-select and move or resize them, drop across pages, and grab and position blocks from the keyboard. App is also a stepping stone to code; when the user needs full custom behavior, an App can be ejected into a Component. The layout system is now part of that app model rather than incidental CSS. Alongside Stack, Row, Card, and Form, builders can use Section, Responsive grid, and Sidebar layout primitives. Sections provide page-level regions with title, subtitle, spacing, padding, and surface treatment; grids provide responsive dashboard/form/card regions with explicit or auto-fit columns; sidebar layouts provide a two-region workspace that collapses for narrower app frames. Layout presets in the palette seed dashboard grids, form sections, and record workspaces, and the same nodes render in builder preview, ejected JSX, and packaged ui/ apps. When published as a model-owned UI package, App buttons can also act as route buttons: action = "route" treats the button value as a package-relative appPath and updates the takeover URL without declaring a model write. The builder exposes the App document's pages as route targets so authors can wire navigation by choosing a page path instead of memorizing package URLs. Route buttons can optionally write a selected-state value before navigating. Inside a Repeater, that write can come from row scope (@order.id, @order.#index), which gives App Builder the standard master-detail app pattern: choose a record, commit that choice to the model, then open a detail page that reacts to the same state cell. Submit buttons are the batch-command sibling of route buttons. A submit action can write several model symbols at once, can take values from the current Repeater row (Target = @order.amount), and can optionally route after the writes. That gives visual App Builder screens a reusable command layer for review, approve, apply, save, and wizard-style workflows without moving state out of the spreadsheet model. Alerts are the feedback primitive for that same workflow layer. An Alert can bind its title or message to a model cell and use normal visibleWhen conditions, so validation errors, save results, approval status, or warnings can be calculated in the spreadsheet layer and shown in the app shell. The same condition system gates actions: disabledWhen can disable inputs, buttons, submits, or whole containers from model state or row scope, and that behavior is preserved in preview, ejected code, and packaged model UI. Published App packages declare a homePath from the selected home page, so opening the model in App Mode starts at a stable app route rather than the generated dist/index.html document. The generated package listens to Grid's app.location connector events and renders the page whose path matches the outer app route, while all reads/writes still flow through the model binding contract. The builder preview uses the same page-path rules, so route buttons can be tested before publishing. Ejecting an App to a Component also preserves the page table with a small generated router; the ejected code can navigate locally and still call the host model.setPath API when available.

This makes App Builder the visual framework layer for Grid Apps: pages define navigation, layout primitives define responsive regions, bindings define reactive state edges, actions define writes or route changes, and publishing turns the result into the model-owned ui/ package. Component surfaces remain the escape hatch for custom code, but they sit on the same connector and app-mode runtime. The Builder left rail includes an App framework panel generated from that same contract, so authors can see the app home, pages, model reads and writes, commands, row scope, conditions, feedback, and record/chart/filter features while they build instead of discovering those relationships only after publish. That panel now treats App Builder as a small application framework map: App shell, Reactive state, Actions, Data views, and Custom UI each carry a status, signal, and recommended action from the same metadata written to the package. Empty or partial layers can launch the existing shell/form/records starters directly, keeping the authoring conversation centered on the app being assembled rather than only on the URL that will launch it. The same metadata now rolls those layers into an App readiness strip (draft, forming, usable, or publishable) with a ready-layer count and a single next action. That gives builders a product-level path through app composition instead of asking them to infer intent from component counts alone. It also records a layout summary: section count, responsive grid count, sidebar layout count, card/form count, responsive-region count, and max explicit grid columns. Generated GRID_APP.md includes the same summary so a custom React, Vue, or plain JavaScript handoff can see whether it is replacing a dashboard grid, a form flow, a record workspace, or a basic stack. The framework panel also includes a capability review before publish. It summarizes the app's current risk level and lists every scope the generated app does or does not use: model reads, model writes, app route changes, job runs, and connector calls. Read-only apps show as low risk, model writes show as medium risk, and write-then-route workflows are highlighted as higher risk. Inactive job and connector scopes are shown explicitly so builders can see that a packaged app is not silently running jobs or calling external connectors. The palette now starts with inferred App patterns from the live model: Model app, Dashboard, Records workflow, and Input workflow. These apply the same model-aware starter logic as the framework map, using row arrays, selection/search state, scalar inputs, and feedback cells to assemble higher-level app flows instead of isolated widgets. The starter palette also exposes named app templates: CRM, Approval workflow, Forecast dashboard, Intake form, Operational queue, and Scenario planner. Each template binds live row sources, selected/search state, scalar assumptions, status/approval cells, and feedback cells when the model exposes them; when a symbol is missing, the template keeps the region as an unbound App component so the builder can wire it later instead of failing generation. The palette also exposes layout presets that do not require a model symbol: Dashboard grid, Form sections, and Record workspace. They are reusable container patterns rather than generated launch plumbing, so authors can first shape the app screen and then bind model state into it. Actions are now described as first-class action plans in the Builder contract, not just as incidental button props. Button plans can set, increment, decrement, write formulas, append a row by replacing array/table state, validate against a model condition, branch to a success route, write feedback, or declare planned job/connector calls for publish review. Submit buttons are batch transactions: their write lines run together, can resolve row-scope values, can route after success, and can write feedback. Generated dist/app-meta.json records an actions summary plus per-action plans with kind, reads, writes, validation, route-after-success, feedback target, capability scopes, support status, risk, and evidence. The framework panel and GRID_APP.md render the same Action Builder section so custom UI handoff can preserve action intent instead of rediscovering behavior from generated code. The adjacent Appearance panel persists app-level mode, accent, density, and radius on the App document. Builder preview, read-only run mode, generated ui/ packages, and ejected Component JSX all consume that same theme contract, so app styling is a first-class framework layer instead of loose CSS drift. Selected version-2 App Tables also provide signed native create/edit/delete forms for a newly admitted empty authored table. All four declared framework carriers use the shared renderer and a capable host; foreign record owners, populated migration and undeclared sandbox transports refuse editing. See native record forms and recovery.

The App state panel is now a semantic binding browser over the current reactive model contract. For every declared read/write symbol it shows access (Read, Write, or Read/write), binding role (table schema, writable app state, action target, or derived value), live kind/preview, source lineage (Named state or sheet/table source), row schema, a small sample row when the model exposes one, validation hints, and suggested UI uses such as Table, Cards, Chart, Number input, Toggle, Alert, or Metric. Rows can jump back to the source model symbol through the existing selection bridge, making the spreadsheet state visible while the app is being assembled. Generated dist/app-meta.json also writes a static stateBindings map with access, role, component lineage, and suggested uses. GRID_APP.md includes the same Semantic Bindings section so a custom UI handoff can preserve the model-state intent even when it no longer has the live workbench samples. The same handoff guide includes Capability Review from dist/app-meta.json, including scope evidence, so custom UI authors can see what the Builder app was allowed to read, write, route, run, or call before replacing the generated entry point. The same panel surfaces the custom UI handoff files: GRID_APP.md, the custom-ui/ project folder, custom-ui/manifest.json, custom-ui/README.md, custom-ui/index.html, custom-ui/main.jsx, custom-ui/vue-main.js, custom-ui/grid-app.d.ts, grid-app.js, grid-app.d.ts, grid-react.js, grid-react.d.ts, grid-vue.js, grid-vue.d.ts, custom-app-starter.js, custom-react-starter.jsx, custom-vue-composable.js, grid-connector.js, grid-connector.d.ts, and the createGridState helper. The Navigation block is the first page-aware component in that framework: it renders the App document's pages as tabs, pills, or a list, marks the active page, and routes through the same app-path connector used by route buttons. The builder also offers an App Shell starter from the palette and Pages panel: it creates a routed Dashboard, Records, and Inputs page set from the model's live symbols, with Navigation already placed on each page and responsive sections/grids seeded for dashboards, forms, and records. When the model also has obvious selected-row state for the row source, the shell adds a Record detail page and seeds row cards with Open buttons that write the selected row before routing. Records workflows use the Sidebar layout when selection/detail state is available, keeping filters/detail beside the main table on wide frames and stacking naturally on smaller frames. When the model exposes obvious error, warning, status, result, or validation message cells, generated starters add Alerts and keep those cells out of editable input forms. It is meant to turn a blank App surface into a working multi-page application skeleton in one move. The Bar chart block gives dashboards a first visual primitive over row data: it binds to a row source, infers label/value columns by default, and can be inserted directly from the From model palette for a selected range. Tables can participate in the same app-state loop: a Table may bind a selected value to a model cell and optionally name the row column to write when the user clicks a row. The selected value is read back to highlight the active row, and published/ejected apps preserve that read/write contract. Tables may also bind filter to a text-like model cell; the table filters rows from that value while preserving source-row identity for selection. Authors can pair a Text input and Table on the same search cell, so search is still model state rather than private component state. The Detail block completes the basic master-detail pattern: it reads the same row source and selected value, finds the active row, and renders selected-row fields without requiring an author to build helper formulas first. The Records starter uses this convention when the model already exposes an obvious selection symbol such as SelectedOrder: it creates a selectable table and selected-record detail instead of leaving the author to wire the record workflow by hand. When it also sees an obvious search symbol such as SearchOrders, it adds the search input and binds the table filter automatically. The same workflow is available from the From model palette: choosing Records view on a row source inserts the searchable, selectable, master-detail block for that specific data source. Row sources can also become end-user card lists. Choosing Cards on a row source inserts a Repeater bound to that source; when the builder can see a sample row it seeds a card template with row-scope bindings such as @order.id and @order.amount, and otherwise falls back to automatic labelled cards at runtime. When the model exposes a matching search state such as SearchOrders, the generated Cards workflow includes a search input and binds the Repeater's filter slot to the same model cell. Scalar model state has a matching workflow primitive. Choosing Input form from a number, text, or boolean symbol inserts a Form whose children are model-bound inputs for the detected editable scalar state. Obvious record workflow state, such as SearchOrders and SelectedOrder, stays with the Records view instead of being pulled into the generic Inputs screen. On a host with combined Form support, standard and custom fields submit with the compiler-owned action as one transaction. Undo and Redo restore those fields and the action result together. Authenticated hosted models use the same controls and retain Earlier history across service restart. Only the submitting principal can replay an operation, and changed source or intervening edits can refuse replay. If an acknowledgement is lost, retry reconciles the same submission without executing its action twice. Read-only or unsupported owners refuse combined submission. Hosted support currently requires an ordinary model with durable native storage; organization/protected ownership, selected distributed durability and unsupported advanced actions retain their existing admission requirements. Atomic Form Undo restores fields and model state; it does not roll back an external action. Combined Forms with unsupported external effects refuse before saving any fields and retain the draft. Run those actions separately. Accepted actions can remain pending while effects settle; success and failure use the same feedback for standard and custom controls. An authored compensation is a separate action, shown as Compensate, rather than a promise of rollback. Run again can repeat an external effect; Cancel effects applies only while a held effect has not run. See actions, outcomes and pacing in the Views guide.

Boolean state can also become reactive structure: choosing Conditional section on a boolean symbol inserts a Card whose visibility is driven by that model cell. This makes show/hide behavior another declarative edge in the App document rather than private component state. Text state can become a view state machine. Choosing Mode switcher on a string-like symbol such as Scenario, Status, or Mode inserts a bound segmented control plus conditional Cards for the inferred options, so an author can build scenario, status, or tab-style app flows from one model cell.

Component

A Component surface is authored JSX inside the workbook. It renders through React and receives a curated model API for reading and writing bound model state.

Use Component when the interface needs code-level control: conditional layouts, custom interactions, richer components, specialized visualizations, or a UI pattern from the React ecosystem. Component surfaces should declare the symbols they read and the symbols they are allowed to write.

One Surface Framework

Built-in and custom surfaces use the same model-facing shape. A surface is a namespace with named slots:

Map_1!type = "map"
 
Map_1!config = <toml>
  version = 1
  kind = "map"
  title = "Stores"
</toml>
 
Map_1!data = ""

The !type slot chooses the surface family. The !config slot stores the surface settings. The !data slot stores surface-owned state such as board cards, layout tiles, app-builder trees, or diagram positions. Some surfaces also use !source for JSX source.

This shared shape is what lets Grid unify built-in product surfaces with custom UI work:

• A built-in Table, Chart, Map, or Document can start with a native Grid UI.
• Ejectable built-ins can generate JSX source for customization.
• A Component can use the same model bindings as an ejected built-in surface.
• An App can be assembled visually, previewed, and ejected into a Component when the interface needs code-level control.

The result is a gradual path: start with a built-in surface, customize it when the model outgrows the default UI, and keep everything inside the workbook.

Model Bindings

Surfaces bind to model values by name. A Table might bind to Orders; a Chart might bind to MonthlyRevenue; a Map layer might bind to StoreLocations. Bound surfaces update when the model updates, so formulas, connector data, and surface views stay together.

Some surfaces are also editable: moving a Kanban card or dragging a Calendar event writes the change back to the bound cells through the model's normal input path. The model stays the source of truth — the surface is just a faster way to edit it.

Custom surfaces use the same idea. A Component can read a value:

function App() {
  const revenue = model.useValue("Revenue");
  return <ui.Metric label="Revenue" value={revenue} format="currency" />;
}
 
render(<App />);

It can also read rows:

function App() {
  const orders = model.useRows("Orders");
  return <ui.Table columns={orders.columns} rows={orders.rows} empty="No orders yet." />;
}
 
render(<App />);

Writes are explicit. Custom surfaces declare which symbols they can write, and Grid blocks writes outside that allowed set. This keeps a custom UI from accidentally editing unrelated parts of the model.

The custom UI model exposes these common reads and writes:

The injected ui primitives provide standard controls and display pieces so a custom surface can look and behave like the rest of Grid without rebuilding basic widgets every time. Current primitives include ui.Stack, ui.Row, ui.Card, ui.Panel, ui.Toolbar, ui.Text, ui.Badge, ui.StatusBadge, ui.Alert, ui.Button, ui.CommandButton, ui.Metric, ui.Field, ui.FilterBar, ui.TextInput, ui.NumberInput, ui.InlineEditor, ui.Select, ui.Toggle, ui.Slider, ui.Table, ui.DataTable, ui.Cards, ui.EmptyState, ui.Progress, ui.KpiGrid, ui.Tabs, ui.Sparkline, and ui.Chart. The framework views — ui.DataTable and ui.Cards — window large row sets to O(visible) DOM and carry the model-state view conventions (bind filter to a search cell; selected/selectKey/onSelect write the selected row back to a model cell), the same conventions the App builder's Table uses. ui.Chart renders an inline SVG chart with no chart library in the bundle. ui.Alert is the feedback banner: compute validation, results, or status in the spreadsheet layer and show it with <ui.Alert when={errors} tone="danger" message={errors} /> — feedback stays model state, gated like the App builder's visibleWhen. Selectable ui.DataTable views support keyboard use by default: Tab enters the table, arrows move between rows, Home/End reach the first/last row, and Enter or Space selects the focused row. Moving focus alone does not write to the model. Filtering preserves the original row and source index passed to onSelect; a changed filter starts at the first result without changing the selected value. Shorter datasets keep the viewport within the remaining rows. Tab leaves the table normally.

ui.Cards provides a focusable scroll region. Give it a descriptive label when a page has several collections. Page Up/Down, Home/End and arrows retain native scrolling behavior; controls inside each card keep their own keys. Changing the filter starts at the first result, and a shorter collection keeps the scroll position within its available results.

A Component can also use standard JSX elements such as div, section, input, select, table, and svg. Package components from the wider React ecosystem must be made available by the host surface scope before a Component can reference them by name.

Authoring Custom UI

When creating a custom UI, start from the user's workflow rather than from the component tree. Decide:

1. Which model symbols does the UI read?
2. Which model symbols may it write?
3. Which state belongs in formulas, and which state belongs in the surface's !data slot?
4. Is a built-in surface close enough, or should the UI be an App or Component?

A small Component surface has three parts:

Component_1!type = "component"
 
Component_1!config = <toml>
  version = 1
  kind = "component"
  title = "Revenue Console"
 
  [bindings]
  reads = ["Revenue", "Orders"]
  writes = ["Scenario"]
</toml>
jsx Component_1!source = <jsx>
function App() {
  const revenue = model.useValue("Revenue");
  const orders = model.useRows("Orders");
 
  function applyScenario(next) {
    model.set("Scenario", next);
  }
 
  return (
    <ui.Stack gap={12}>
      <ui.Metric label="Revenue" value={revenue} format="currency" />
      <ui.Row>
        {["bear", "base", "bull"].map((scenario) => (
          <ui.Button key={scenario} onClick={() => applyScenario(scenario)}>
            {scenario}
          </ui.Button>
        ))}
      </ui.Row>
      <ui.Table columns={orders.columns} rows={orders.rows} empty="No orders yet." />
    </ui.Stack>
  );
}
 
render(<App />);
</jsx>

The create menu and Component editor also provide scaffold actions for common custom UI starting points: Dashboard, Records, Controls, Scenario, Review, and Kanban. Creating from a scaffold seeds the new Component surface with both JSX source and config; applying a scaffold inside an existing Component replaces the JSX source and rewrites the config in one step. In both cases, the generated UI and its declared read/write bindings stay together. This is the same packaging an AI agent should produce when it creates a custom UI directly: !type = "component", !config with narrow bindings.reads / bindings.writes, and runnable JSX in !source.

AI Agent Contract For Component Surfaces

When an AI agent creates a custom UI, it should produce a complete Component surface package in one edit:

1. Keep durable business logic in model formulas, rules, or named data values.
2. Choose a Component namespace, such as ScenarioConsole.
3. Write ScenarioConsole!type = "component".
4. Write ScenarioConsole!config with version = 1, kind = "component", a human title, and [bindings].
5. Put every symbol read by JSX in bindings.reads.
6. Put only the symbols the UI may mutate in bindings.writes.
7. Write runnable JSX in jsx ScenarioConsole!source = <jsx>...</jsx>.
8. End the source with render(<App />); or an equivalent single render call.

Do not make the Component calculate values that should be shared with sheets, built-in surfaces, or other custom UIs. Put those calculations in the model and read them from the Component. Do not write broad allowlists such as every model symbol; writes are a capability boundary.

The authoring surface statically scans JSX and shows repair actions when a symbol is read but missing from bindings.reads, or written but missing from bindings.writes. Those diagnostics are advisory; runtime write enforcement still happens through the Component model API, so undeclared writes are blocked. The editor also exposes authoring metadata for available model symbols, the supported model.* methods, and the blessed ui.* primitives; agents should treat that metadata as the autocomplete contract for generated Component code.

Deterministic Generation Recipe

Agents should use the same planning rules as the Component editor's recommended starter:

1. Classify the request from intent words first:
   • scenario / planner / forecast / assumption -> Scenario
   • review / approval / queue / triage -> Review
   • kanban / board / pipeline / stage / status -> Kanban
   • record / search / browser / detail / list -> Records
   • control / form / input / edit / settings -> Controls
   • dashboard / KPI / metric / summary / overview -> Dashboard
2. If intent is vague, infer from model shape:
   • row data plus scalar metrics -> Dashboard
   • row data only -> Records
   • scalar values only -> Controls
   • status/stage-like row data -> Kanban
   • scenario/target/assumption-like scalar values -> Scenario
3. Generate the Component scaffold package: !type, !config, and !source.
4. Run the static binding scan over JSX and compare it to [bindings].
5. Repair missing reads/writes before presenting the result.
6. Verify the custom UI in Mock, Empty, Loading, and Error preview modes. A generated Component is not done until those states render cleanly.

The planner is exposed in code as buildComponentGenerationPlan. It returns the chosen scaffold, generated package, reads, writes, validation checks, safety notes, and rationale. Agents should prefer that helper when they are operating inside the Grid UI codebase; otherwise they should follow the recipe above exactly.

The injected model API has this shape:

interface ComponentModelApi {
  get(symbol: string): unknown;
  useValue(symbol: string): unknown;
  useValues(symbols: readonly string[]): Record<string, unknown>;
  useRows(symbol: string): {
    status: "unbound" | "loading" | "error" | "empty" | "bound";
    columns: Array<{ key: string; label: string; type?: string }>;
    rows: Array<Record<string, unknown>>;
    label: string;
    error?: string;
  };
  useRange(symbol: string): Array<Record<string, unknown>>;
  set(symbol: string, value: unknown, typeTag?: string): void;
  setFormula(symbol: string, formula: string): void;
}

The injected ui primitives are React components. They are intentionally small and composable:

ui.Stack;       // vertical layout
ui.Row;         // horizontal layout
ui.Card;        // framed content
ui.Panel;       // titled framed section
ui.Toolbar;     // header/actions row
ui.Text;        // muted/supporting text
ui.Badge;       // status token
ui.StatusBadge; // tonal status token
ui.Button;      // action button
ui.CommandButton; // primary/quiet/danger command
ui.Metric;      // labeled scalar
ui.Field;       // label/value display
ui.FilterBar;   // search/filter row
ui.TextInput;   // string write control
ui.NumberInput; // numeric write control
ui.InlineEditor; // compact editable value
ui.Select;      // option write control
ui.Toggle;      // boolean write control
ui.Slider;      // numeric range control
ui.Table;       // row display
ui.DataTable;   // windowed data view: any row count, filter + selection write-back
ui.Cards;       // windowed card list over rows (renderCard) with filter
ui.StatusBadge; // tonal status token
ui.Alert;       // feedback banner, gated by model state (when)
ui.EmptyState;  // empty/error panel
ui.Progress;    // progress meter
ui.KpiGrid;     // repeated metrics
ui.Tabs;        // segmented sections
ui.Sparkline;   // compact trend chart
ui.Chart;       // dependency-free SVG chart (line/bar/area) over rows

For a model like this:

Revenue is currency = 720000
Scenario = "base"
Orders = [
  { id: "ORD-1", customer: "Acme", amount: 42000 },
  { id: "ORD-2", customer: "Northstar", amount: 88000 }
]

an agent-generated Component should look like this:

ScenarioConsole!type = "component"
 
ScenarioConsole!config = <toml>
  version = 1
  kind = "component"
  title = "Scenario Console"
 
  [bindings]
  reads = ["Revenue", "Scenario", "Orders"]
  writes = ["Scenario"]
</toml>
jsx ScenarioConsole!source = <jsx>
function App() {
  const revenue = model.useValue("Revenue");
  const scenario = String(model.useValue("Scenario") ?? "base");
  const orders = model.useRows("Orders");
 
  return (
    <ui.Stack gap={12}>
      <ui.KpiGrid
        items={[
          { label: "Revenue", value: revenue, format: "currency" },
          { label: "Scenario", value: scenario }
        ]}
      />
      <ui.Select
        label="Scenario"
        value={scenario}
        options={["bear", "base", "bull"]}
        onChange={(next) => model.set("Scenario", next)}
      />
      <ui.Table columns={orders.columns} rows={orders.rows} empty="No orders yet." />
    </ui.Stack>
  );
}
 
render(<App />);
</jsx>

Keep calculations in formulas whenever possible. Use the custom UI for interaction, presentation, and workflow. This keeps the model inspectable and lets the same values continue to work in sheets, built-in surfaces, and custom surfaces.

Complete Surface Examples

These examples show the model-source shape a user or AI agent should produce. They are intentionally small, but each one includes both model data and surface slots.

CRM With Table And Kanban

MODEL "Pipeline CRM"
DESCRIPTION "Track accounts as rows, then show them as a table and workflow board."
VERSION "1.0.0"
AUTHOR "AI Agent"
TAGS "surface-template", "crm", "table", "kanban", "surfaces"
 
Accounts = [
  { name: "Acme", owner: "Mina", stage: "lead", value: 42000 },
  { name: "Northstar", owner: "Owen", stage: "qualified", value: 88000 },
  { name: "River Co", owner: "June", stage: "proposal", value: 56000 }
]
 
TotalPipeline IS currency = SUM(MAP(Accounts, row => row.value))
 
# Inspect account fields in a table.
Accounts_Table!type = "table"
 
Accounts_Table!config = <toml>
  version = 1
  kind = "table"
  title = "Accounts"
 
  [columns]
  bind = "Accounts"
  title = "Accounts"
 
  [[columns.fields]]
  key = "name"
  label = "Account"
 
  [[columns.fields]]
  key = "owner"
  label = "Owner"
 
  [[columns.fields]]
  key = "stage"
  label = "Stage"
 
  [[columns.fields]]
  key = "value"
  label = "Value"
</toml>
 
Accounts_Table!data = ""
 
# Group the same accounts by pipeline stage.
Pipeline_Board!type = "kanban"
 
Pipeline_Board!config = <toml>
  version = 1
  kind = "kanban"
  title = "Pipeline"
 
  [layout]
  wip_limit = 8
 
  [[columns]]
  id = "lead"
  title = "Lead"
 
  [[columns]]
  id = "qualified"
  title = "Qualified"
 
  [[columns]]
  id = "proposal"
  title = "Proposal"
 
  [items]
  bind = "Accounts"
  column = "stage"
  title = "name"
  assignee = "owner"
</toml>
 
Pipeline_Board!data = ""
 
END MODEL

Store Map

MODEL "Store Map"
DESCRIPTION "Show store locations on a map."
VERSION "1.0.0"
AUTHOR "AI Agent"
TAGS "surface-template", "map", "locations", "surfaces"
 
Stores = [
  { id: "SFO", name: "San Francisco", latitude: 37.7749, longitude: -122.4194, revenue: 125000 },
  { id: "OAK", name: "Oakland", latitude: 37.8044, longitude: -122.2712, revenue: 92000 },
  { id: "SJC", name: "San Jose", latitude: 37.3382, longitude: -121.8863, revenue: 111000 }
]
 
TotalRevenue IS currency = SUM(MAP(Stores, store => store.revenue))
 
# Plot store locations from the shared model data.
Store_Map!type = "map"
 
Store_Map!config = <toml>
  version = 1
  kind = "map"
  title = "Store Map"
 
  [layout]
  basemap = "streets"
  center = [37.7749, -122.4194]
  zoom = 9
 
  [[layers]]
  name = "Stores"
  bind = "Stores"
  lat = "latitude"
  lng = "longitude"
  label = "name"
  color = "#2563eb"
</toml>
 
Store_Map!data = ""
 
END MODEL

KPI Layout Dashboard

MODEL "Revenue Dashboard"
DESCRIPTION "Summarize a forecast in dashboard tiles."
VERSION "1.0.0"
AUTHOR "AI Agent"
TAGS "surface-template", "dashboard", "layout", "surfaces"
 
MonthlyRevenue = [120000, 135000, 142000, 150000, 168000]
Pipeline = 186000
Forecast IS currency = SUM(MonthlyRevenue#) + Pipeline
AverageMonth IS currency = AVERAGE(MonthlyRevenue#)
 
# Present the model’s revenue summaries as dashboard tiles.
Dashboard!type = "layout"
 
Dashboard!config = <toml>
  version = 1
  kind = "layout"
  title = "Dashboard"
 
  [layout]
  cols = 12
  rows = 6
  show_controls = true
 
  [[tiles.static]]
  title = "Forecast"
  x = 0
  y = 0
  w = 4
  h = 2
  formula = "=Forecast"
 
  [[tiles.static]]
  title = "Average Month"
  x = 4
  y = 0
  w = 4
  h = 2
  formula = "=AverageMonth"
 
  [[tiles.static]]
  title = "Notes"
  x = 0
  y = 2
  w = 12
  h = 4
  body = "Forecast includes five months of actuals plus open pipeline."
</toml>
 
Dashboard!data = ""
 
END MODEL

Custom Scenario Console

MODEL "Scenario Console"
DESCRIPTION "A custom Component surface reads model values and writes the selected scenario."
VERSION "1.0.0"
AUTHOR "AI Agent"
TAGS "surface-template", "custom-ui", "component", "surfaces"
 
Revenue IS currency = 720000
Scenario = "base"
Orders = [
  { id: "ORD-1", customer: "Acme", amount: 42000 },
  { id: "ORD-2", customer: "Northstar", amount: 88000 },
  { id: "ORD-3", customer: "River Co", amount: 56000 }
]
 
# Let readers explore the model through a custom component.
ScenarioConsole!type = "component"
 
ScenarioConsole!config = <toml>
  version = 1
  kind = "component"
  title = "Scenario Console"
 
  [bindings]
  reads = ["Revenue", "Scenario", "Orders"]
  writes = ["Scenario"]
</toml>
jsx ScenarioConsole!source = <jsx>
function App() {
  const revenue = model.useValue("Revenue");
  const scenario = model.useValue("Scenario");
  const orders = model.useRows("Orders");
 
  return (
    <ui.Stack gap={12}>
      <ui.Metric label="Revenue" value={revenue} format="currency" />
      <ui.Select
        label="Scenario"
        value={String(scenario ?? "")}
        options={["bear", "base", "bull"]}
        onChange={(next) => model.set("Scenario", next)}
      />
      <ui.Table columns={orders.columns} rows={orders.rows} empty="No orders yet." />
    </ui.Stack>
  );
}
 
render(<App />);
</jsx>
 
END MODEL

Choosing A Surface

Use a built-in surface when the model fits a known workflow: tables for records, maps for locations, boards for planning, documents for narrative, charts for analysis, and layouts for dashboards.

Use an App surface when you want to compose a model-bound screen without writing React first.

Use a Component surface when you want a custom front end with React-level control over layout, state, components, and interaction.

Use eject when a built-in surface gets you most of the way there but the final experience needs custom behavior. Ejecting keeps the model bindings and produces editable JSX source that can continue inside the workbook.

Current Boundary

Surfaces are a UI layer over model state. They do not replace formulas, rules, or the source editor. The model remains the durable computation layer; surfaces are how people operate, inspect, and present that computation.

That boundary is intentional. It lets Grid be a spreadsheet, a model, and an application shell at once: built-in surfaces provide familiar app-like interfaces, and custom surfaces let teams build the exact UI their model needs.

Deck

Deck provides structured live presentations in App, the shared visual editor and source in Code, model bindings in Data, and narrative work in Chat. Present live or capture values, use a separate audience window, print slides, or export editable PowerPoint. See Deck presentations.

Drag or resize a selected block directly with pointer or touch, then release to save one acknowledged placement change. Escape, capture loss or a changed owner cancels the gesture. Numeric controls, keyboard arrangement and Undo/Redo remain available; audience, print and editable export use the same placement geometry.

App presentation and authoring

Charts and Visuals use the shared App heading and View actions menu. Edit chart and Edit visualization open their native arrangement tools; Done returns to the view. Visual export review remains available from the menu. Pending chart edits flush when leaving the surface. Data keeps its existing chart toolbars and editor layout.

Shared numeric controls display percentages in percentage points: 6 beside % writes the ratio 0.06. Currency grouping is removed for editing and validated when pasted. Enter and blur save, Escape restores the last accepted value, and failed text remains available for correction. Numeric edits preserve existing currency/unit tags. Controls honor the host’s declared input catalog when available; read-only bindings remain visibly distinct from editable assumptions. Documents and notebooks carry the host’s existing display metadata with their selected live references.

App hosts the same editors and persistence as Data. Its compact frame separates content actions from Customize App, which arranges navigation and optional per-view Next steps. Numeric/text controls commit on Enter or blur, retain failed drafts, and report acknowledged writes. Native Inspect exposes selected-object commands without opening a panel for every selection. Notebook blocks add drag ordering, keyboard movement, and structural Undo/Redo. App Builder, Layout, and Notebook flush pending content on navigation through the existing ordered draft writer and preserve conflicts for explicit recovery. See Interface layers for the authoring boundaries and the complete forecasting example.

Document insertion accepts full command titles such as /heading 2 and /cell value. Keeping a Chat excerpt uses the same Markdown conversion as the document editor, accepts the saved revision before its first write, and retains the excerpt as one undoable content operation. It does not replace an unresolved draft or interpret prose as executable code.

Inspect a compiled Process (0.68.0 development)

In a Workbench Process surface, open Design and start and choose Create process. Creation remains available when the workbook already has saved plans. Give it a name and one example input as a Grid expression. The saved plan name is under Advanced. Apply draft in Code prepares a minimal Process that returns its input, keeping existing source and comments. Review and Save in Code before Start. Creation neither saves nor runs anything, and an existing unsaved Code draft must be resolved first. After saving, Add step and participant setup extend the process. While creation is open, Start is disabled. Close creation to run an existing plan, or review and Save the new draft in Code. Existing workflows remain available. Creation is unavailable in Run and Print modes.

Visual Process drafts enter the browser Code editor as an Undo step, including its first opening. Undo and Redo change only the draft; Save applies it. On a host with Process execution selected, Code validates the draft with the same compiler as Save. Selecting a retained run does not prevent a later source edit; changed source or an existing unsaved draft still requires review.

In a development Process surface, choose a saved compiled plan to read its Sequence. The surface remembers a chosen or started plan when reopened, independently of the selected historical run. If the plan is renamed or removed, choose another plan or review Code; Start stays unavailable until a valid plan is selected. Selection never starts work. Switch to Diagram for the same structure. Open a branch, independent group, iteration or child process to inspect that scope; long scopes are paged. Participants, sharing audiences and repeat bounds stay beside their steps. Diagram opens on the first step at a readable size. Diagram step and Previous step/Next step move within the loaded page without running work or changing order. The current step remains selected when switching views or resizing. Long cards scroll internally; the canvas zoom controls still provide an overview of the loaded scope. Use the separate step-page controls for more than 25 steps. Use Code to change the definition. Inspection makes no model calls or writes; Start remains explicit. The outline describes the selected plan for a new run, not the definition of a historical result. Use the retained-run inspection described below to read an earlier definition.

In Run setup, choose model references for the plan's AI profiles and open Run limits when you need to change the call or time budget. Save setup remembers those choices for this plan in the surface configuration. Each saved plan has its own setup; reopening restores it without starting a run. Changes can be used for the next explicit Start without saving them. A selected provider requires a model name; Use AI setup instead resolves the configured account at admission. Review connection reads the current provider and model without making a model call. For Use AI setup, Use this model copies that resolved choice into this plan's setup; it does not change the account's preferences. AI setup… opens the existing connection settings when you need to connect an account or server. Review again after changing account settings. Availability is checked when Start admits the run, so a reviewed connection can still become unavailable. Saving stores no credentials and does not fix a remote model alias to an immutable version. Historical runs keep their admitted identities and budgets. Run and Print do not offer setup changes. Invalid authored setup must be corrected in Code before saving or starting.

The canonical Process runtime releases only a closing service's own execution capacity after its physical work drains. Other services can continue on the shared executor, and saved recovery evidence is kept. Native document service selection and document Process runs remain in development.

Native document Process and Tasks delivery remains in development. The new inspection adapter selects plans and current compiled outlines from the exact admitted document image, using the existing sequence and diagram views. It does not admit a run. Start stays unavailable while native execution is unconnected; history, connection/tool review and saved cases still require native owners. The development source adapter also connects the existing source inspector, localized field/insertion/participant/structure edits and creation form to the selected document. Apply prepares a retained Code draft; only explicit Save commits it through the native source owner. It checks source/revision and candidate digests, and refuses source inspection if imported source changed since the plan was compiled. Current native compilation, execution and restart verification remain open; scripted wire checks do not establish those contracts. Development also shares the existing table manager across admitted members of one native document. Model locators and separate-document storage stay distinct. This storage alignment does not enable Process execution or close native recovery.

Native document Process and Tasks delivery remains in development. If its native execution capability is unavailable, the development client reports that it cannot continue rather than opening or changing a hosted workbook with the same name. This also applies to source inspection, connection/tool review and saved Process cases in Evaluate. Switching to another document retires the previous workspace's requests while the new saved state loads.

Development Start process waits until the saved Process selection has loaded with its current revision. Setup fields and focus remain in place while it loads.

If a Process selection save cannot be confirmed, Start and further selection writes remain blocked. The reply must confirm the exact selected plan or run at its new saved revision; showing the choice in the workbook first is not confirmation. The open setup fields stay in place. Reopen the workbook to inspect the saved selection before continuing. A host without selection-save support keeps Start unavailable.

Development Save setup waits for the host's matching configuration receipt before refreshing the compiled plan. If the reply is missing or uncertain, the current fields remain in the open view and Start is blocked. Reopen the workbook to inspect the saved setup before continuing. This completion check does not establish native configuration durability.

For writable native documents, the development setup-save adapter preserves the existing input contract and supports Undo and Redo. A conflicting Code draft stays in place and prevents the save. Unconfirmed replies keep the setup available and require reopening to inspect the saved version. Live native restart and failure verification of this adapter is still in progress.

Development Apply in a native surface's Code configuration file now waits for the saved source and refresh to be confirmed. TOML comments and formatting survive the save; newer edits and focus stay in place while it completes. Undo and Redo restore the authored source. Code can repair invalid setup without making it ready to run. If completion is uncertain, retain the draft and reopen the workbook to inspect the saved source before another save. Live native failure/restart verification remains in progress.

In the development workbench, unsubmitted setup fields survive leaving and returning within the same app session. Retention is scoped to the current owner, workbook, partition, surface and plan; Run and Print do not restore draft fields. If the compiled process or saved setup changed while you were away, review the current process and retained fields, then explicitly Save setup before Start. Reopening does not save or start work. This shares the bounded Process authoring working-state cache (32 entries and 8 Mi characters); it does not provide recovery after a cold restart. Keep a separate copy before closing or restarting the app.

If a Process declares Workbook destination, choose Review workbook destination and explicitly accept Use reviewed destination before Start. Acceptance writes the reviewed source and destination revision to its declared inputs. The surface refreshes the compiled plan after those acknowledged writes; Start waits for that read to succeed and uses the new captured input identity. Your setup, selection and focus remain in place. An unconfirmed earlier Start keeps its original request and retry key. Reviewing does not call a model or publish a result; the native owner still checks publication authority and revision.

For a retained Process run, choose Inspect run definition to explore the Sequence or Diagram captured when that run started. The view keeps its original plan and artifact identity after you edit the workbook. Opening a child, branch, or loop reveals its steps; long scopes are paged. Inspection makes no model calls and does not resume work. Older records without a retained outline report that it is unavailable. Run mode permits this read-only inspection; Print keeps the selected result snapshot without interactive diagram controls.

In Workbench, Edit step opens fields supplied by the compiler. For example, you can change a contribution's instructions or a child's argument without rewriting the surrounding Process. Source shows the whole selected Process definition. Choose Apply draft in Code, review the result, and Save explicitly. Other source and comments are preserved. A changed workbook or unsaved Code draft must be resolved before applying an edit. Start is disabled during editing. Imported processes are edited in their owning module; historical runs remain read-only.

A human-only workflow needs no model connection. Each contribution presents its declared response shape as a form to the assigned signed-in account. In a bounded review loop, answering one question advances to the next admitted contribution; the final approval does not publish unless the Process explicitly includes an authorized publication operation. Reopening the surface observes the retained result. Editing a later prompt through Code does not relabel that earlier run.

In the selected sequence or diagram scope, Add step offers Value and, when the Process declares participants, Contribution. Coordination steps reveals conditions, bounded repeats, child calls, sharing, withdrawal and independent contributions. Only the selected kind's fields appear. An insertion goes before the final result expression and keeps that result unchanged; edit the result explicitly when it should use the new output. Suggested names avoid existing bindings. Review the generated draft in Code and Save before running.

Open a branch, loop or local child definition to add steps there. A branch with one expression becomes an explicit PRIVATELY block containing the new steps and original result. Independent groups offer only addressed contributions. Inside Edit step, expand Arrange step for Insert before, Move earlier, Move later, and Remove step when the compiler can identify that action. These apply to the whole authored statement shown in the inspector. Moves stay within the current scope and preserve inline comments; leading comment lines stay in place. Required results and loop YIELD clauses cannot be moved or removed. A move or removal can break references: the resulting Code draft retains the compiler diagnostics for review and correction before Save.

For a Process without participants, choose Configure participants from Add step. Name a role and choose an AI profile or Human, supplying the profile name or exact authenticated account ID as plain text. Apply creates a Code draft that adds the role, Team and plan binding. Review and Save it, then add the contribution. Processes with existing roles expose Participants for further configuration. If a Team is shared, a copy is created for this plan so other plans keep their responders. AI connections are selected at Start; participant setup stores no credentials and sends no questions.

Imported or Room-bound setup, and adding roles to a Process with multiple plans, require editing the owning source. The ordinary compiler may also require updated child-call mappings when a new role is introduced. Nested step placement, structural movement and multiline expressions still use Source/Code.

History refreshes when you open the panel, choose Refresh, or perform an action. Only the selected running or waiting process is observed continuously. Completed, stopped and suspended runs are read once; closing the panel stops observation without stopping the process.

If the saved run selection arrives after the panel opens, the panel restores that run without starting or resuming it. A run you choose in the meantime takes precedence; a later saved-state update preserves your Resume model draft and keyboard focus. Hosts that buffer recent presentation edits may lose the latest selection after a sudden shutdown. Choose the existing run from history again; this does not start or resume it. The durable Process journal owns the run independently of its presentation selection.

After a native host restart, a suspended run retains the conversation recorded by its durable Process journal, including questions, accepted replies, captured member failures and physical call receipts. Opening that history starts no work. Choose Prepare to resume and then Resume process to continue a safe run; its original deadline and identities still apply. Older saved records may need explicit Resume to reconstruct their conversation. If the whole conversation exceeds its admitted display budget, the panel reports its retained byte count instead of presenting a partial history as complete.

Optimization

Choose Optimization to author requirements, adjust quantity bounds and whole-unit decisions, inspect a solution, and save the displayed capture. See the Optimization guide.

Statistics

Choose Statistics for one-sample summaries or independent and paired comparisons. Review the sample scope and saved evidence before interpreting results. See Statistics and uncertainty.

Symbolic

Choose Symbolic to inspect symbolic mathematics with explicit assumptions and the supported operation scope. See Symbolic mathematics.

ScientificImage

Choose Scientific Image to browse image slices, inspect labels and select regions for native measurements. See Scientific Image and Volume.

Scene

Choose Scene to inspect scientific objects and their coordinates in three dimensions. See Scientific 3D Scene.

Gallery

Choose Gallery to browse files, preview an item and retain its reviewed selection. See Asset and Gallery Review.

Email

Choose Email to inspect the selected model's mail surface. Use explicit mail connector actions for receiving or sending; opening a surface does not send mail.

New development workbenches

Six standalone workbenches extend the development surface inventory: Optimization, Statistics / Uncertainty, Symbolic Mathematics, Scientific Image / Volume, Scientific 3D Scene, and Asset / Gallery Review. Their main views lead with results, images or selected objects. Analysis settings, solver budgets, exact coordinates, source identity and saved history appear on demand. Optimization authors resource and minimum-cost plans, including exact requirements, quantity bounds and whole-unit decisions. It updates the solution after an acknowledged assumption edit and saves the displayed capture. Native decision, usage, slack and binding values have readable result tables. Statistics creates one-sample summaries and independent or paired comparisons from selected model samples, with distribution graphics and native intervals. Image inspection starts with a sampled whole-plane overview and opens exact pixels for closer inspection; display contrast stays fixed while browsing. Rectangles, polygons and freehand outlines retain native pixel measurements and authored calibration. Scene supports focus, isolation and image export, with transient camera exploration and an explicit save for reopening a view. Gallery can explicitly capture a bounded frozen catalog into the existing immutable artifact owner. Its individual reviews and previews retain exact bytes after live Files change or disappear; frozen thumbnails and bulk review remain unsupported. See Gallery capture and limits. Gallery loads a bounded thumbnail contact sheet with a live collection. Its keyboard review loop prepares Keep/Reject drafts before an explicit save; selecting multiple files applies one guarded review document to exact byte versions. Explicitly verified local video and audio expose browser playback controls. They use existing native computation and Files owners, with bounded admission and explicit inspection. Their guides state write acknowledgements, retention and source-identity limits. Guided resource planning authors ordinary native solver formulas; advanced formulations remain available in Code. Statistics captures remain session-local until downloaded, image inspection uses numeric planes, and Scene presentation uses approximate painter ordering.

These are initial development workflows. Native and full-application verification, paired whole-process cost evidence and compiler-native Grid View embedding remain open. Registration does not establish complete workflow acceptance.

The Symbolic workbench creates fresh named native calculations with local assumptions, including ordered algebra/differentiation worksheets that retain conditions across steps. It explicitly inspects exact expressions, solution bindings, multiplicities, conditions and certificate-bound provenance. Its saved formulas and bookmarks use existing model source ownership. Local literal-step worksheets reopen in a visual editor with their original inputs and assumptions; updating preserves the surrounding source. Shared recipes remain editable in Code. See its guide for bounded display, draft recovery and standalone-only limits. Selected historical captures can be exported as a printable offline HTML report; typeset results, conditions and available source formulas remain together.

Shared surface history retains the visible editing session during a suspended React transition. A replacement becomes the command owner when it commits; an abandoned render cannot redirect Undo or change the target policy.

Published View confirmation also respects private local refusal, including a clean component that is waiting for recovery. Cooperating owners share the host question. If the owner or its draft checkpoint changes while the host is answering, confirmation returns false and keeps the draft intact. This does not yet let a child veto a departure initiated outside its packaged frame.

React View/App components and other framework mounts use the same host session. A standalone destination, Back request or source replacement keeps its approval bound to the current component checkpoints through the actual handoff. A changed owner or retired session cancels the handoff and retains the current View. A containing host with registered guards continues to own its route decision, without a second local question.

For packaged surfaces, a dirty/checkpoint report is not a private component's permission to leave. An internal opt-in host profile now asks those private owners before leaving and checks them again after the host answer. Core App keeps that profile off until its outer route, layer and Back callers can await the decision. Do not rely on that boundary to preserve a private recovery refusal in Core App yet.

The published navigation adapter now exposes its existing private guard decisions to an optional local connector service. The service lives only while guard owners are registered and waits for current protection acknowledgement. Built-in and exported connectors now share optional child decision transport. The selected host profile has bounded request lifetimes and refuses on timeout, reload, retirement or changed checkpoints. Core App outer callers and browser/native placement acceptance still need integration.

Opening a model or loading an example now awaits registered component decisions and keeps that approval tied to current owner checkpoints through the read. A changed draft or newer admitted model open cancels stale adoption and retains the current workspace. Clean recovery owners can refuse without a discard question; cooperating owners share one surface question. The packaged profile still remains off in Core App until the other outer callers are migrated.

Folder switching and explicit signout now await the same registered component decisions as model/example opens. A changed workspace or private checkpoint cancels approval before the transition. Cross-folder search waits for the folder decision, then opens from its current callback; an older pending search cannot revive after a newer search intent. Other outer paths still need migration before Core App enables the packaged private profile.

Deleting the open model from the library now awaits registered component agreement. A refused decision preserves the model and drafts. After successful deletion, work changed while the request was pending remains visible, with a notice to open or create a model to continue. This retains the editing workspace; it does not undo the server deletion. Deleting another model does not ask to discard the current model's drafts.

Scenario departure approval also stays tied to the session and draft revision that existed when the question opened. Changing those facts invalidates approval and retains the private copy, even when its controller object stays the same.

Creating a folder or merging the current folder now awaits registered component agreement. A changed draft, missing merge target or removed parent cancels the handoff. Creation rechecks current names and free slots after agreement. An unrelated folder merge keeps the current editing workspace in place.

New-model creation now awaits registered component agreement before replacing any workspace or showing its existing unsaved-model discard dialog. The dialog's approval belongs to the source, workspace and component checkpoints that opened it. A changed draft, newly registered owner, retired owner, or newer creation intent cancels stale approval. Confirm/cancel handlers from an older dialog cannot act on a newer creation request. Cancellation and workspace reset retire the pending decision. Template starters carry that same component agreement through loading; they do not repeat the surface question. Scenario confirmation remains a separate decision. Other outer callers and browser/native acceptance still need migration before Core App enables the packaged private profile.

Closing Pages/App beside Code now waits for the companion's registered owners. It consults that pane's decisions without asking to discard the primary Code pane's drafts. Refusal or a changed companion/workspace leaves the pane in place. Replacing App with Browser waits for that closure and rechecks the workspace and companion requests before opening Browser. A newer pending close supersedes an older agreement. The primary editor's existing buffers stay mounted through these decisions. This does not complete global route/layer/Back migration or browser/native recovery acceptance.

Programmatic surface/page moves and surface/package run exits now retain the host route and URL while registered component decisions are pending. Refusal, changed owner checkpoints, a newer move, changed model/catalog/package checks, or an unmounted router cancel stale approval. Final layer checks precede one more owner validation. Routing options and focus callbacks belong to committed React UI; a speculative suspended render cannot take them over. This covers these host moves, not every child-local render. Browser Back/Forward, layer selection, boolean entry/custom-page setters and automatic home admission still need migration before the Core App packaged private profile is enabled.

Back/Forward while a surface decision is pending

Within the currently mounted model, Back/Forward waits for the same component agreement used by host surface/page navigation. The current surface remains mounted and its browser entry is restored while the decision is pending. An accepted request resumes once; changed work, a replaced component, newer navigation or a refused layer transition prevents stale agreement taking over. For an entry without router-owned history bookkeeping, the host restores its owned URL and can adopt the accepted destination at that physical entry without guessing an offset. This does not reopen another model. Cross-model history and installed browser/native recovery remain separate unfinished work.

Opening another model through browser history

Core App now routes cross-model Back/Forward through the existing model loader. It retains the source surface during component agreement, checks browser travel before reading, and publishes the destination model and folder only while the request remains current. Refusal or a failed read restores the owned source entry. This supersedes the earlier cross-model limitation above; installed browser/native recovery and full history performance remain unverified.

Entering a surface with component agreement

Host surface entry now shares the leave decision used by surface/page changes. When a component needs to decide, entry returns an eventual accepted/refused result and keeps the source surface and page together until agreement. With no such decision, entry still completes immediately. Navigation drawers, Find and bound-element reveals wait for acceptance. Changed registrations, a newer entry request or a target removed from the current catalog refuse old requests. Layer selection, custom-app page setters and automatic home admission retain separate contracts and are still being unified.

Custom-app page agreement

Custom-app page changes now share component agreement with built-in surface entry and host page navigation. The host keeps the current route until accepted; changed package identity, component protection or a newer request refuses old approval. Find, next steps, context selection and return links honor the eventual result. A packaged app.setPath call receives success only after parent acceptance, and a reloaded frame cannot receive an older route reply. Calls with no component decision still complete immediately. Automatic home admission remains unfinished; the private packaged profile is not enabled. Layer selection is described below.

Layer selection now shares the owner decision used by surface and custom-page routes. Calls without a selected decision still return immediately. A guarded move waits for acceptance before committing the current editor, closing a companion or creation view, revealing a Data or source target, or attaching a symbol to Chat. The editor commit occurs before the source layer unmounts. Focusing an existing pane keeps its contents and retires an older pending move. Layer pickers and More wait for the result; an older result cannot close a reopened picker. Search navigation waits before its final close and destination focus. Workspace Back records the accepted visit even if rendering arrives before the decision; location history remains separate from editing history. Automatic home admission, global screen transitions, Code resource changes and installed browser/native acceptance remain open. This does not enable the private packaged profile or admit private app.back.

Automatic configured and packaged home selection, including an arriving first surface in an empty App layer, now uses the same navigation agreement. The current home remains visible until accepted. A changed model, package, catalog, owner or newer request refuses an older candidate. Editor contents commit before a departing layer unmounts; refusal or a reentrant move prevents publication. Explicit App selection resolves its home in that decision. This does not enable the private packaged profile. Global/resource exits and installed acceptance remain open.

Home, Help, System, Network and Theme Lab now use the shared navigation decision without changing the model route underneath them. Protected components and the current editor remain until acceptance. Document search and global section requests publish after acceptance. Menus stay open while waiting; a late reply cannot close a reopened menu. Return to the model uses accepted layer navigation. Calls with no component decision remain immediate. Specialized Code resource changes and installed browser/native acceptance remain unfinished.

Code working tabs, Back/Forward, workspace area changes, split replacement or closure and surface explorer choices now await shared component agreement. Source locations revalidate before publication. The current editor, tabs and history remain until accepted; retired requests cannot close tabs or move focus. Forward visits survive an accepted destination rendering before its receipt. Opening a new split keeps existing editors mounted and remains immediate. Code location history stays separate from source undo/redo. Internal source scope and some source-reveal paths still use older contracts and remain under audit, alongside installed browser/native acceptance.

Source workspace section changes and explicit search, diagnostic, inspector and outside-scope definition reveals now use the host navigation decision. Scope, history, caret and requested panel or View creation flags publish together after acceptance. A newer move or committed source, model, partition, editor or workspace replacement retires the request, including a source that later returns to its earlier text. Already accepted host and working-history delivery does not ask again. Source undo remains owned by its editor. Within-editor Monaco commands, direct Root source handoffs, remaining global returns and console/deletion paths, installed acceptance and full physical performance accounting remain under audit.

Direct authored-definition and Connections/Extensions source handoffs now require one shared departure decision even when Code is already open. Editor replacement, location history, queued reveal and App return context publish after acceptance. A retained Code or Data companion pane waits for preparation before taking focus when its resource will change; ordinary focus-only navigation stays immediate. Pending handoffs validate the exact source and its committed revision, so changed source that later returns cannot revive an older decision. Accepted controller reveal delivery does not ask twice. Source edit history remains in its editor. Parse-error and other legacy source switches, global returns, native within-editor Monaco commands, installed acceptance and full physical accounting remain open.

Accepted source reveals now wait for an editor registered with the matching full source and actual section. An older scoped controller cannot consume the queued caret; a stale model session retires it. Primary section navigation retires older primary handoffs, while secondary section navigation preserves the primary queue. Code parse-error jumps share declaration handoff admission and preserve the current section when it contains the target. Whole-model New View entry requires departure preparation before publishing its section and creation flags. Valid long lines remain navigable independently of bounded location-history anchors. Conversion/AI handoffs, other legacy resource switches, global returns, native within-editor Monaco commands, installed acceptance and full physical performance accounting remain open. Source undo stays owned by its editor.

App/Component conversions and reviewed Process/formula drafts now wait for shared resource navigation before publishing source or editor state. Conversion staging uses the same primary/split admission callbacks as ordinary Code resources and preserves its review on refusal. Accepted handoff lifetime transfers to the Code draft, so departing review cleanup cannot cancel its insertion. Root layer publication callbacks require departure preparation. The router runs them after accepted route commitment and before focus, letting AI drafts publish source, dirty state and Whole model together. Process and formula controls await the receipt and pass their review lifetime into the decision; refusal keeps the review open and cancellation prevents a late handoff. Source undo remains in its editor and Save remains explicit. Other legacy resource switches, global returns, native within-editor Monaco commands, installed acceptance and full physical performance accounting remain open.

Explicit Code area entry now publishes resource and caller metadata inside the shared accepted layer callback. Open surface builder, Edit this view in Code, Inspect in Code, project-model source entry and package-review returns retain existing editor and return state until acceptance. Source, model object, owner, partition or review-lifetime replacement retires the request.

Legacy Model, I/O, Energy, Atlas, Replay and Research view commands now use the same shared outer-screen navigation decision as Help and Home. Public returns to the model also use that decision; accepted internal return delivery stays separate to avoid another prompt. Research intent, editor visibility, Replay state, retained-input review and purpose examples/inputs publish only after acceptance. Empty-owner navigation stays synchronous and the remembered model route and URL remain intact. Remaining private-frame returns, console/deletion, within-editor Monaco commands, installed acceptance and full physical cost accounting remain under audit.

Console model deletion now awaits shared owner/editor admission before command dispatch. Refusal and stale requests cannot dispatch. Bound acknowledgement of an already committed deletion preserves changed work and another account/folder. Ordinary reads do not invoke admission. Focused deletion callback costs pass; two broader unchanged callback cases exceeded retained budgets and remain under investigation. Installed acceptance and full physical accounting remain unproven.

Browser and console deletion now share admission and bound acknowledgement. Private frame creation, hidden-copy resume and hidden Live return await navigation agreement; visible-pane focus cancels older requests. Private-frame performance, installed acceptance and full physical accounting remain unproven.

Document block gestures now retire on the containing surface’s inactive transition, using the existing gesture cleanup during layout commit. Reopening retains native history and permits a fresh drag. Mounted native-editor tests cover released capture, cancelled frame delivery and no stale mutation; a paired production React probe passes the existing ordinary/admission/selected-cost budgets. This closes the in-process drag retirement gap. Installed placements, device behavior and full physical resource accounting remain open. See the drag investigation.

Document Review comment/change navigation now uses the existing Document focus owner shared with panel returns. It accepts read-only reveals, refuses inactive selection changes, and retires queued delivery after surface/session/posture changes or unmount. Mounted native-editor tests and a source-bound paired probe cover this adapter. The selected cost ratio passes close to its existing limit; installed placement, device and full physical-resource claims remain open. See Review navigation ownership.

Grid View archive export, page HTML snapshot and publication preparation now share a task owner selected at control ingress. Surface/source/host retirement cancels preparation and rejects late delivery; completion cannot clear a successor’s busy state. Whole-View archives survive page changes, while page snapshots retire on departure. Issued publication remains observed and is not rolled back. Control availability and framework generation use the same whole-document compatibility check. Mounted caller tests and a production React hook cost probe cover these boundaries; App-builder/trust-fallback adoption, full render/resource costs and installed/native acceptance remain open. See shared task ownership.

App-builder exports and publication preparation, and the reduced-trust Grid View publisher, now use that same task owner. Source/host/session departure retires preparation; old completion cannot publish/download into or unlock a successor. Issued publication remains observed across callback refresh and retirement. The existing saved-View receipts and packaging capability still enforce their own contracts. Mounted App/View/reduced-trust checks and thirteen-dependency hook cost evidence cover these adapters; installed placements, full render and physical costs, native restart and external publication remain open. See App and reduced-trust adoption.

Shared App/View task preparation now admits work only while its host is visible. Hiding retires pending preparation; reopening creates a fresh lifetime, so retained callbacks and results cannot regain authority or disturb a successor. Standard and custom native action history also passes the selected current-source HTTP restart scenario, including retained journal replay and idempotent retry after restart. These checks cover their declared mounted/native boundaries; installed placements, exhaustive crash boundaries, combined Form-save/action transactions and full resource accounting remain open. See visibility ownership and native history restart.

Saved Views inside Apps and portable Component hosts now receive the enclosing visibility/focus signals without replacing the child session. Hidden native writes are refused while private Form drafts and input identity survive; reopening can commit the retained proposal. Mounted composition checks cover the App surface, shared renderer and standalone Component host. Pending viewer effects now retire across hide/reopen and custom owner withdrawal, with issued native writes observed and uncertain history retained. Focused tests and paired mounted/boundary cost probes pass. Installed placement coverage and complete physical-resource accounting remain open. See host visibility propagation.

Ordinary View action buttons and Touch controls now consume the shared async task owner used by exports and publication. Ordinary buttons retain overlapping actions through opt-in task membership; source replacement, hiding and unmount retire their feedback without forgetting issued native work. Mounted action/Form and existing task lanes pass their focused checks, and single/group hook costs remain within the existing paired budgets. Installed placement coverage, full resource accounting and combined Form/action durability remain open. See ordinary action task owners.

Standard and custom Form submissions now preserve the admitted runtime and control owner through input-save acknowledgement, follow-on action and draft reset. Lost permission retires late validation and viewer feedback; disabling and re-enabling keeps the draft while admitting a fresh Form owner. Issued native work remains observed. Mounted checks and paired ordinary-render/Form-action cost evidence cover these boundaries; combined durable Undo, installed placements and full resource accounting remain open. See Form submission owners.

Form Check and converted staging now retain the shared surface/Form permission owner across awaited preparation. Cancellation, hiding and owning-Form disable abort preparation while preserving staged proposals; re-enable admits fresh work and old results cannot replace its feedback. Focused checks and paired render cost evidence cover these boundaries. The initially incomplete native-control fixtures and refused-focus defect are now repaired with real runtime owners; installed placement/resource acceptance remains open. See Form preparation owners.

Native-control fixtures now exercise real shared runtime owners, and refused validation focus uses a control-lifetime capture that survives task settlement while retiring with its surface. All 23 native-control cases and the broader 223-test owner/Form suite pass. Hook and mounted render/action costs remain within existing paired budgets. Installed placement and full resource/durable crash coverage remain open. See native-control fixtures and refused focus.

Imported component lenses/events and JSX setters/named actions now share the control-lifetime owner used by surface tasks. Retained callbacks refuse new work after replacement, disable/re-enable, hiding or unmount; issued native writes remain observed and departed notices are suppressed. The existing visibility version admits fresh callbacks after reopening. Focused tests and paired callback admission/general-render costs pass; other callback hosts, installed placements and full resource acceptance remain open. See imported and JSX callback owners.

Declared action scopes for free React now use the same callback owner as imported components and JSX. Site, declarations and row replacement retire old ports while preserving the surrounding View; print/hide/reopen and unmount also retire authority. Issued actions remain observed without departed viewer effects. The focused module/action/Form suite and paired renderer costs pass. Installed placement, full resource and broader native recovery acceptance remain open. See declared free React action owners.

Outcome subscriptions in declared React, imported component and JSX action ports now retire with their shared callback owner. Caller cleanup is idempotent, and a retired scope cannot release its successor's listener. Cleanup storage exists only after selected subscription registration. Focused ownership tests and paired callback-owner costs cover this boundary; installed placement and comprehensive resource acceptance remain open. See outcome subscription owners.

Form input-save/action submission and View history now share a selected admission boundary. Pending Forms expose history busy; local and earlier-journal replay refuse new ingress, and a new Form save waits for an existing history replay. Cancellation keeps issued work fenced until settlement, and overlapping Forms release their own admissions. Input batches and reversible actions remain separate transactions; combined durable Undo still needs a native transaction/receipt contract. See Form/history admission.

A composed standard-action/custom-Form/history interface now has mounted evidence through saved App Views and the standalone React host. Root Forms observe existing runtime settlement, so reopening clears stale busy presentation. Form callbacks capture their surface/document/host lifetime; departed callbacks stay retired while fresh controls retain the draft. Continued visibility, hide/reopen and unmount checks preserve issued work and independent enclosing services. Installed product placements and comprehensive resource/native recovery acceptance remain open. See composed View interactions.

Source-bound browser checks now cover composed App/React keyboard history, text-field priority, pending Form saves, read-only refusal and print/return. They found and repaired stale custom-command availability after print: the shared callback owner now publishes committed admission once per control lifetime. Mounted regressions, frontend types and paired costs pass; installed placement, full resources and native durable transaction/recovery acceptance remain open. See browser composition and callback availability.

A fresh Process Start checks that its workspace, inspected plan and setup are still current after loading selected tool catalogs. Closing the panel or changing its owner, plan preparation, setup or permission prevents that pending Start. No attempt is created by a catalog read. Once Start has been sent, an uncertain response still retries the original payload and attempt key; a new source inspection does not silently create another run. Durable pre-admission intent, device-restart recovery and complete native document Process execution remain in development.

When Process Start returns a run, the panel keeps its original attempt until the workbook confirms that run's saved selection. The returned run can be inspected while the save is pending. If confirmation fails, the known run stays selected and “Confirm run selection” repeats only the selection confirmation; it does not start another run or rebind the next run's setup. An uncertain selection-save receipt still requires reopening the workbook for inspection. A lost Start response uses the separate “Retry same start” action with its original request and key. The device-retention development path below extends these controls; actual device-restart execution recovery remains unverified.

Native document AI reference saving is now connected in development source to the admitted document and its existing durable transaction. Canonical authored AI string data slots are admitted for reference saving separately from ordinary inputs. Ordinary input writes and input-state reset retain their declared-input scope. A save confirms the exact selection bytes and a newer resolved revision; an uncertain or stale receipt still stops further admission until inspection. This increment does not enable native inference or Process Start. Native execution, storage-failure/restart QA and complete recovery remain unfinished.

Development source now also preserves a native AI reference through a compatible Code edit. Changing that slot's identity or AI kind requires explicit migration instead of silently carrying its old selection into a different surface. Native compilation and live storage/restart verification are still pending; this does not complete native execution or recovery.

Editable Process surfaces with a host-owned recovery scope now retain the original Start request on this device before sending it. They use the existing document recovery store, including the desktop app profile. A returned run is retained before saving its workbook selection and cleared only after that selection is confirmed. If retention or cleanup fails, the original request or known run stays available through the existing retry/confirmation controls.

Reopening restores only agreeing copies of the same request. A returned-run receipt can complete a matching pending copy; a newer timestamp never wins over a different request or run. Reading recovery starts no work. Conflicting or unreadable copies are kept and prevent a fresh Start. Read-only views do not read or write these copies, and separate native documents keep separate scopes even when they have the same model name. This is connected development source, not proof of live browser/app-profile persistence or hard-restart recovery. Native document Process execution and complete recovery remain unfinished.

Native document Process authoring, Start, history and Human replies are connected in development source. A Start names the exact inspected plan and physical document lease. Saved AI setup choices resolve on the backend; credentials never come from the browser. Grid verifies the existing signed desktop principal and uses the same canonical plan, provider/tool, budget and attempt-key admission as Hosted Process. The private native runtime key selects resident execution; a same-name Hosted model or another document cannot substitute for it.

Snapshot arguments read current native publication receipts, including values already emitted by the native changes owner. Missing or stale publications refuse Start; admission does not resolve a producer or refresh a table-backed cone. Provider/A2A/MCP binding runs after releasing the host and document locks. The run uses the existing shared managed executor and this document's model.db. The panel can review its saved provider connection and discover installed API reads and saved MCP tools through that same physical document context.

History, frozen outlines, Cancel and Remove use the actual retained document owner. Source edits do not replace a run's frozen steps. Cancellation preserves an already committed completion; removal still refuses active runs and keeps governed workflow evidence. The owner and named Human respondent can inspect a question; only its named, signed respondent can answer. Canonical reply size, shape, consent and capacity checks remain in force.

In a frozen run definition, each ASK step has a Retained turns disclosure in Sequence and Diagram. Replies join the exact saved compiler step, so repeated questions and iterations stay distinct. The full Conversation remains below. Older runs without step identities and withheld histories explain why per-step turns are unavailable. Opening a disclosure makes no model call or source write.

In Start setup, Installed methods explicitly reads the host's installed catalogue. Choose an exact matching method, review its setup, then use the normal Start control. Selection alone starts no work. The Start request retains the reviewed catalogue, semantic contract and artifact; a changed plan refuses until you choose a current match. Use saved plan without this method explicitly returns to ordinary plan selection. An unsubmitted method choice is local to the open view. Read-only views show no method picker.

The development replay API also accepts an explicit nodeValues frozen-outline selector. One 25-step page projects computed outputs and completed source-operation receipts with their original compiler coordinates and runtime frames; repeated values retain occurrence numbers. It reuses record-only replay and the canonical executor. Stale selection refuses; byte/occurrence limits or unmatched replay withhold the selected view whole. Original owner inspection admission remains required. Settled native AI operations select their original read-only execution and issued-reference records under the current exact document grant; inspection does not construct an AI owner or submit work. Changed authority/generation, unavailable owners and collection-lane projection remain refused. In a settled run's definition, choose Inspect saved values and receipts to check the selected frozen page. Review the existing participant settings when requested; this check calls no model or operation. Sequence and Diagram then show a Saved values · receipts disclosure beside each step. Values retain their frame and occurrence; completed receipts retain their frame, sequence and operation identity. They are separate records, without an inferred one-to-one relationship. Each disclosure pages twelve entries locally. Navigating to another frozen page requires its own explicit check. Mismatched evidence is not displayed; a wholly withheld view exposes no partial values or receipts.

The actual five-source native document contract passes original-owner settled replay with frozen values and receipts, without another capture or counter change. Ordinary Check saved record does not request this optional projection.

Installed API reads now execute through the existing gateway and the desktop's configured connections. Document admission binds the signed principal, physical document, model member and incarnation once at Start; the existing document invalidation owner refuses subsequent reads after that admission is retired. The model locator never selects a same-name Hosted credential vault. This installation admits bounded reads; commands require their separate authority.

Native document Capture now uses the existing workbench operation, worker and retained Dataset ledger with the opened document's physical stores. It reads native ranges, Tables, retained Frames, assets or authored values; its snapshots stay inside that document. Preparation uses the same native data preparation executor and the document's private resident/job identity. An explicit startup grant names the document ID, model member, principal, generation and capture operation. A Hosted workbook grant with the same model name does not grant native access. Opening the document performs no Capture. See the native Capture example.

These native examples keep editable setup as ordinary JSON data. Root calls project explicit fields into closed frozen contracts instead of inferring a permanent shape from a mutable initializer. Capture has a named plan for each source kind; Train captures the physical worksheet. The native operation owner still validates the full configuration before executing work. Comparison and publication setup pass explicitly through each Process call. Native sequence fields keep the canonical row form during the bounded Start import. Native plain JSON input records freeze through the bounded Process data decoder; richer typed objects remain refused. Numeric setup fields use checked scalar parameters, validated when Start freezes its arguments.

Process empty records retain the general empty-object identity. {} is a closed zero-field record in source, decoded JSON and EXPECT replies, and remains {} in bounded result/prompt/inspection JSON. It is distinct from [], text and rich typed artifacts. This correction selects no new evaluator or storage.

On Unix, configure GRID_PROCESS_AI_GRANTS_JSON with a document grant such as [{"principal":"alice","document":"<opened-document-id>","model":"<member>","generation":1,"operations":["capture"]}]. Use the actual opened document ID and admitted member. The document supplies its existing recoverable Process store; this grant does not need a separate Hosted recovery directory. Omitting document retains the existing Hosted grant contract and its recoverable-storage requirement. Unsupported hosts and missing capabilities refuse the operation.

Native document Predict is connected in source through the same workbench operation and prediction worker. Add predict to the explicit document grant; its input must be an issued retained Dataset. Trained subjects select an exact version from this member's existing registry format under models/<member>/artifacts/trained/registry.json. Absolute artifacts and integrity-bound predictive companions must remain in that trained-artifact home or the member's assets; relative paths resolve inside assets. Traversal, symlink aliases, corrupt registry state and another member's version refuse. There is no global trained-registry fallback. Exact installed coordinates and the saved default use the existing model admission and frozen connection. The original Process control and document admission stop further model calls when the document owner is retired. See the native Predict example. The focused native numeric contract now passes through committed document inputs, the exact physical artifact and retained Dataset: one model call produces the expected numeric result. Supported-profile and UI acceptance remain open.

Native select_version is connected in source to that physical registry. Its explicit document grant includes select_version; the input is a native-issued trained_version artifact, and configuration contains schemaVersion: 1 and positive expectedVersion. The existing registry transaction checks the expected pin, exact version, owner and artifact identity and commits the pin with its original receipt. The document's ingress gate serializes this mutation with its other writers. Binding and observation do not pin; a retired admission cannot execute. A repeated original attempt observes its receipt without replacing a later pin. Select creates no Frame manager or model call. See the selected-version helper. Its native physical factory contract passes on the selected lite,process-runtime host. Train → Select also passes in the complete combined native contract.

Native Train is connected in source to the opened member's retained Dataset, the Desktop registry's existing per-document jobs store and physical trained-artifact home. Add train to the explicit document grant; training and bounded model I/O must be enabled on the host. The same Train owner constructs the original job, enforces its single-fit permit, runs the existing trainer and retains its completion receipt. A job-specific indexed route prevents draining another operation. The existing model I/O executor schedules it without a new polling worker. Publication acquires the original document ingress gate before the job lease fence, then syncs the same registry transaction; it cannot select the global registry or a replacement document. Queue refusal cancels the original unclaimed job. See the first-publication Capture → Train → Select → Predict example, which requires a new model ID. The complete native contract passes physical Train → Select delivery and direct retained-data/legacy training, candidate pin preservation, selection conflicts and uploaded-model registration/rename/archive.

Native Evaluate is connected in source for fresh inference and saved predictions. Add evaluate to the document grant. It uses the physical retained cases, prediction children and report Frames; fresh subjects and rubric judges use the same member custody checks as Predict. Exact version, input contract, mapping, trials, uncertainty, case population and model-call budgets remain owned by the existing evaluation implementation. Scoring saved predictions makes no fresh subject calls and opens no subject model pool. Fresh rubric judges retain their explicit calls. Original document invalidation stops subsequent calls. See the fresh/saved evaluation helper. The six-row example scores training cases and makes no held-out quality claim. The native source contract now joins that helper to the first-publication example and passes both paths, reports, calls and physical Frames. Fresh compiled Process comparisons are now connected in source on Unix. Review the current plan identity and argument/profile mapping before starting; the comparison helper compares the issued trained candidate with a pure Grid Process baseline. Each case uses the captured physical source/imports and retained Dataset values, with the original document Process service and existing shared executor. Later workbook inputs cannot replace its case arguments. Namesake documents share neither the selected continuation slot nor retained case authority. The same case policy refuses unsupported operation/tool, Room and Session effects. Reports retain the existing case receipts and accounting. The combined delivery contract passes six pure Process comparisons and direct fresh/saved scoring. Saved scoring selects exact original public roots with argument ordinals; private derived fresh-case plans are not public saved-run subjects. Manual ratings retain the original result row and respondent separately from computed metrics, without subject or judge calls. Physical historical Resume/replay/fork and pending compiled-child restore are connected in source; native saved compiled-case surface delivery is now connected in source. Hosted continuation refuses these document records rather than selecting a public namesake.

Native Publish is connected in source to the opened member's declared input. Add publish to the document grant. Review the current physical source hash and input revision before starting; a stale destination refuses before writing. The existing publication owner maps retained rows into a physical Frame, then the native input owner commits its override and original receipt in one WAL transaction. Observation reads that receipt, including after a later edit; it never writes again or infers success from the current input. Receipts are bounded to 256 entries and 4 MiB per member; exhaustion requires an explicit owner resolution and never silently erases evidence. See the physical publication helper. It takes an issued artifact from Capture, Predict or Evaluate and an explicitly reviewed destination. Stateful targets use the existing staged native rule/temporal owner and commit its complete semantic image, input responses and receipt in the same WAL frame. Publication retains the input touch with its semantic state and receipt; the existing native scheduler dispatches the change rule through the original owner. The complete seven-operation/direct delivery contract passes one rule firing per publication, repeat-attempt identity, current destination revision checks and original receipt preservation after later edits. The owning codec/WAL checks remain separate evidence; installed/profile/UI acceptance and paired costs remain open. Existing native effect restrictions still apply.

All six factories and historical Resume/replay/fork are connected in source. In the existing Process history, select a suspended owned run and choose Prepare to resume, then review its saved provider choices. Resume uses the original deadline and frozen arguments. For a settled run, Check saved record replays retained evidence without provider calls; Run again from a turn creates a distinct fork and leaves the original completion unchanged. Current source edits cannot replace historical plans or arguments. The backend verifies the physical root before opening saved credentials; request bodies cannot add source, tools, budget overrides or credentials. Missing document context refuses. A pending compiled Evaluate operation restores the original child through that same physical parent, exact request/control, frozen case archive and case service. It does not submit a new Evaluate attempt or select a Hosted namesake. The native contracts remain unrun; current native types and behavior are unverified. The four existing Process UI suites now pass 140 tests with the normal repository dependencies. Those scripted UI checks do not establish native execution. Development turn records also carry the exact numeric compiler definition/node coordinate from their frozen run. This supplies the relationship between an ASK step and its replies, including repeated prompts and loop iterations. Older retained traces omit it. Full runtime-node inspection and its visual presentation remain unfinished; no new display is activated by this metadata change. The existing Check operation outcome control now forwards the original run, operation digest and sequence through signed native document ingress to the canonical service. Pending settlement uses its original obligation; stopped lookup remains refused without an installed reconciliation capability. Read-only or stale document custody refuses. Scripted UI/transport contracts pass; actual physical control acceptance remains unfinished. Pending inspection also exposes the exact frozen compiler node coordinate without changing the run or calling a provider. Two native contracts pass for ASK and operation coordinates across repeated prompts, loops and child frames; full historical value/operation mapping and paired physical costs remain open. Native installed-component inspection and Start admission now select a trusted catalogue scoped to signed principal, physical document ID and member. In GRID_PROCESS_COMPONENTS_JSON, an installation for a physical document includes document alongside the existing principal and model fields. Omitting document retains Hosted installation scope. Neither scope authorizes a namesake in the other scope. Clients inspect the existing catalogue and select exact reviewed semantic/plan/artifact identities; they cannot supply an installation. The original native Process root retains component provenance and reconciles the same attempt without another Start. Current native types/execution remain unverified; the standalone installed-method picker is not mounted in the active panel. Its callback now returns the exact catalogue/contract/artifact tuple and the existing bounded Start request retains it unchanged; the two affected files pass 39 tests. Visible placement still requires named-view review and approval. Plans selecting unavailable operations fail closed; unsupported operation-outcome controls remain visible and disabled. Current-main, supported-profile, installed acceptance and paired physical costs remain open for the full application.

Explicit packaged navigation admission

A packaged app can request private owner decisions before installing its shared draft guards:

await grid.capabilities({ navigationDecisions: true });

Core App admits this request through its guarded asynchronous router. The reference and generated connectors expose the admitted owner service only after a positive handshake. A host that lacks support rejects the explicit request. An ordinary grid.capabilities() call leaves that service dormant. Model write authority and each editor's Undo history keep their existing contracts.

The host then asks current child owners before departure and validates their checkpoint after the enclosing confirmation. Back uses the enclosing router's protected history move. The product's published View/App renderer requests this service automatically before registering its shared Form and nested owners. It requires a host that acknowledges private decisions with a current loaded-frame identity; an unsupported host refuses boot rather than weakening protection.

Native browser checks cover private refusal, changed preparation checkpoints and retired-frame approval rejection. The product-exported renderer also registers private Form ownership and preserves drafts on refused outer departure. Installed desktop close and the remaining lifecycle cases are still being verified.

Direct native Evaluate delivery is now connected in development source for scoring explicitly selected, settled compiled Process cases. Its Dataset picker, preview, case selection, history, results, manual ratings and trace inspection pass the admitted physical document owner through the native transport. Scoring uses the original Process service and existing report engine and makes no fresh Process or subject calls. Direct saved scoring and ratings pass the physical delivery contract; installed/profile and trace/control UI acceptance remain separate. Direct native Publish, destination discovery and formula review/preparation now use physical source, revision and artifact custody in development source. Direct Train/Select authoring now also selects the existing document jobs, single-fit trainer and physical registry in development source; native external registration/rename/archive now select the physical registry; unsupported selectors refuse without selecting a Hosted workbook by the same name. The completed canonical journeys remain credited for their recorded source/profile.

Native uploaded-model registration uses the uploaded bytes in the selected member's Files sandbox. Artifact and sidecar digests are verified before the existing provider validator and registry registration; Grid derives predictive capability from an admitted sidecar. The original publication key is scoped to the document/member/principal, so repeating the same upload does not create a second version. Rename and archive use the existing physical registry transaction and check document writability. Archive marks every version archived and removes the model from discovery/new admission. Native trained workbook formulas now connect to the original inference worker and physical pinned/exact/latest registry selection in development source. Changed inputs use the same formula calculation. Train/registration publication, SelectVersion and archive request a refresh through the existing document projection; its ingress fence serializes active formula settlement and registry mutation. Exact versions keep their identity after a pin change; archive refuses every version. The actual selected native document formula contract passes for those behaviors and namesake isolation. UI observation, supported-profile acceptance and paired physical costs remain open.

Direct Dataset Capture is also connected in development source to the physical member source reader and existing ETL preparation worker. Start, history and results keep the admitted document context. Current native execution remains unverified; the existing source and preparation contracts are unchanged.

Direct native Predict is now connected in development source for example inputs and retained Dataset batches. Subject discovery, calibration inspection, Run, history, Stop and retained results keep the physical document owner. Batch inference and SQL receipts use the existing engine and document table owner; final Frame publication reuses the document custody fence. This batch publication capability is currently Unix-only. Current product types/execution and paired costs remain unverified; this source connection is not installed-product evidence.

Direct native Evaluate fresh cases and active-case controls are now connected in development source. Compiled cases use the physical source/service and existing case deadlines/drain wakes; model comparisons and judges use physical inference custody. Human replies, Stop, original-case inspection and explicit Continue retain the document owner. Continue checks the original principal, configuration and sequence before preparing saved profile choices. Nested Process operation cases continue through their original parent. Current product types and native/UI execution remain unverified; this adds no recovery store, timer or protocol.

Email

Email pairs one IMAP or POP3 account with SMTP in Desktop and Server. Its configuration references the model-owned account:

version = 1
kind = "Email"
title = "Email"
[email]
account_id = "personal"

Use Account to save TLS endpoints, credentials, sender identity, existing folder mappings and separate send/mutation permissions. Test saved connection checks incoming and SMTP authentication without sending a message. Passwords remain in the host secret vault. Cached headers, downloaded content, drafts and frozen outbox actions live with the document's model.db and immutable artifacts.

Mailbox search covers cached headers and downloaded text. Selecting a message fetches its display body; attachments download individually on request. Remote images and other external HTML resources are blocked. Drafts save with revision checks. Send freezes the exact saved message into a durable action; Submitted means the SMTP server accepted responsibility. Delivery unknown requires an explicit resend decision because another attempt may deliver a duplicate.

IMAP read state, stars and supported UID MOVE filing synchronize to the server. POP3 read state, stars and organization stay local; server copies are never deleted. Synchronization continues while the model is loaded, including when the Email tab is hidden. Closing the model preserves queued work.

Authored tables can read the same owner-managed messages:

table Inbox = CONNECTOR("mail.imap", {"accountId":"personal","folder":"INBOX"})
A1 = TABLE_COUNT("Inbox")

These declarations default to subscribe with the table-read delivery profile; explicit query or snapshot-read also use read-only table handles. Generic table editing cannot change mail. MAIL_SEND, MAIL_SET_FLAGS and MAIL_MOVE are rule/action operations with stable operation IDs and separate account permission, unavailable in ordinary formula expressions.

MAIL_SEND(accountId, operationId, draftId, revision) sends the exact saved revision. A message object in the fourth argument constructs and saves a draft at revision 1 in the same transaction as the frozen send intent:

WHEN A1 CHANGES SERIAL LEDGER THEN
  MAIL_SEND("personal", "report-2026-10-08", "report-draft-2026-10-08",
    {to: ["reader@example.org"], subject: "Daily report", text: "Total: " & A1})
END

The object requires to, subject and plain-text text; optional fields are cc, bcc, attachments, inReplyTo and references. Attachments reference existing immutable artifacts. The account supplies sender identity and granted send authority. Choose a new operation and draft ID for each intended message; keep both IDs stable when recovering that same message. Identical replay returns the retained result, and changed content under an existing operation ID is refused. A colliding saved draft is preserved. SMTP acceptance is reported as submitted, without claiming recipient delivery.

Copied, imported and restored documents retain cached mail and drafts, exclude secrets and require account reactivation. Historical queued actions require an explicit individual retry; interrupted submissions remain delivery-unknown. Reactivation does not silently replay them. Full connected QA and Performance acceptance for this implementation remain outstanding.