How it fits together

Final Wording holds a small number of objects, and almost everything you will read later is a detail of one of them. Reading this page first means the rest of the handbook has somewhere to attach.

The workspace

A workspace is the boundary around a body of work: its documents, its people, and the record of what they did. People are invited into a workspace, not into an individual document, so the question “who could have changed this?” has an answer that does not depend on who was sent a link.

Inside a workspace, documents can be grouped into projects. A project is optional — a document can live directly in the workspace — but it is more than a folder: a project has a say in who sees what, so a restricted project narrows access to everything inside it.

The document

A document is the thing you are accountable for — a contract, a policy, a report. You write it in an editor built for documents rather than for memos: sections and clauses are real structure, not manual numbering that drifts the first time someone inserts a paragraph.

Structure is worth a moment’s care up front, because it is what later references hold on to. A cross-reference points at a clause, not at the number the clause happened to have on Tuesday.

The version

A document does not exist in one state. It exists as a sequence of versions, and the sequence is the record: what the text said, when it said it, and who made it say that. This is the part that replaces the folder of files ending in final, final2, and final-signed-v3.

Every change is attributed as it is made. Nobody has to reconstruct authorship afterwards from memory or from a mail thread.

The conversation

Comments are threaded and anchored to the wording they are about, so a discussion stays attached to the sentence that provoked it. Colleagues inside the workspace and counsel outside it can be brought into the same thread rather than into a parallel one over email.

A comment is a question about the document. It is not yet a decision.

The approval

An approval is the decision, and it is bound tighter than a version: someone signs off a titled section, and the approval holds to the exact wording they saw. Leave that wording untouched and the approval survives new versions; change it — or anything nested inside it — and the approval falls away automatically, for that section and for every section that contains it. “Approved” then means something specific and checkable later — this exact text, by whom, when — rather than a message somebody remembers receiving.

And then it leaves

Most documents eventually have to exist outside the tool: a PDF to send, a file to file. Final Wording generates that output from the document and your own template, so the thing you hand over is derived from the record rather than assembled by hand beside it. Approval is not a gate: you can generate at any point — but a document that requires approval and still has unapproved sections says so on the output, with a DRAFT · UNAPPROVED watermark that stays until every section is signed off. The same generation step is available over the Document API when the document is produced by a system rather than by a person.

Where to go next

Once these objects are familiar, the rest of the handbook divides by what you are doing: the guides cover a job you are repeating, and the reference covers a surface you are looking up.