> ## Documentation Index
> Fetch the complete documentation index at: https://sdk.revise.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture

> What the component owns, what you own, and how state is scoped.

## The boundary

<Columns cols={2}>
  <div>
    **The SDK owns**

    * Parsing DOCX, Markdown, text, and HTML
    * The document model and its Yjs session
    * Canvas layout, pagination, and rendering
    * Keyboard input, selection, and undo history
    * Tracked changes and comment threads
    * The agent tool runtime
  </div>

  <div>
    **You own**

    * The file: where it comes from, where it goes
    * Document IDs and their meaning
    * Accounts, permissions, and tenancy
    * Persistence and versioning
    * Your agent loop and its model
    * Any chrome you choose to render yourself
  </div>
</Columns>

Nothing in the SDK calls a Revise server. The only network call it can make is
to an agent backend you configure explicitly.

## Canvas, not contenteditable

Revise is not built on ProseMirror, Slate, or a `contenteditable` DOM. It is a
word processor rendered to `<canvas>`, with its own layout engine, text
measurement, and hit testing.

That is why page geometry behaves like Word rather than like a web page:
real pagination, per-section page sizes and margins, running headers and
footers, footnote areas that flow with their references, and text measurement
that matches what exports to `.docx`.

The practical consequence for integrators: **do not expect to reach into the
document via the DOM.** Every read and write goes through the handle or the
tools. Selection geometry is intentionally not public — there are no canvas
rectangles or hit-test APIs — so your UI stays decoupled from Revise's
internals.

## Documents are independent sessions

`ReviseEditor` keeps every open document mounted. Editor-local state survives
tab switches: caret and selection, scroll position, formatting context, search,
review and comment state, zoom, and in-flight agent runs.

```mermaid theme={null}
graph TD
    A[ReviseEditor] --> B[Document: contract-1]
    A --> C[Document: exhibit-a]
    B --> D[Yjs session]
    B --> E[Selection, scroll, zoom]
    B --> F[Review + comments]
    B --> G[Agent state]
```

Every document-local controller supports two forms of routing:

```ts theme={null}
editor.review.next();                        // the active document
editor.review.forDocument("exhibit-a").next(); // a specific one
editor.document("exhibit-a").review.next();    // equivalent
```

Collection state comes from `editor.documents.getState()` and
`editor.documents.subscribe()`. You never need a state round trip before acting
on the active document.

## Document fragments

Inside one document, content lives in separate streams — the same separation
Word makes:

| Fragment  | Holds                                                                |
| --------- | -------------------------------------------------------------------- |
| `content` | The document body. Block operations and agent indices see only this. |
| `chrome`  | Running headers and footers, per side, slot, and section.            |
| `notes`   | Footnote and endnote bodies, referenced inline from the body.        |

This is why inserting a footnote does not shift body block indices, and why an
agent reading "block 12" gets body block 12 regardless of how many notes exist.

## Editing modes

Every document is in one of three modes, set per document and changed at
runtime through `view.setDocumentMode()`:

<CardGroup cols={3}>
  <Card title="editing">
    Changes apply directly. The default.
  </Card>

  <Card title="suggesting">
    Changes land as tracked suggestions to accept or reject.
  </Card>

  <Card title="viewing">
    Read-only.
  </Card>
</CardGroup>

Agent mutations follow the same rule, which is what makes "let the AI draft it,
then review every change" work without special-casing. See [tracked
changes](/guides/tracked-changes).