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

# 2 · Sign it

> A designated approver signs the document. What the approval attests to, and what Revise does.

# 2 · Sign it

**What you are doing.** Attesting, as a named person, that this document is what it says it is.

Approval is a separate person's job.
When the document was composed by someone else, a designated approver sees an enabled **Approve** button on the same page the author saw blocked.

## The approver's view

<Frame caption="A designated approver sees the document, stored values, and approval action together.">
  <img src="https://mintcdn.com/vinmake/NFYl2zy80-D5Iitf/images/greatbook/walkthrough/07-approver-ready.png?fit=max&auto=format&n=NFYl2zy80-D5Iitf&q=85&s=cbe4ecaee9e60cd1a53f20a70bfea7a3" alt="Supplier VAT invoice ready for a separate designated approver" width="1440" height="1000" data-path="images/greatbook/walkthrough/07-approver-ready.png" />
</Frame>

```http theme={null}
POST /typewriter/documents/{document_id}/approve
X-WorthState-Org-Id: <org>
```

<Note>
  That request takes **no body**.
  There is nothing for the caller to choose: which approval step is next is a fact about the chain and
  the trail, and who is approving is a fact about the session.
  A body would only offer both of those as things to get wrong.
</Note>

## What just happened underneath

The approval does not simply set a flag.
It **re-hashes the stored PDF bytes** and records the approval against that hash.

That is what makes "what I approved is what I saw" structural rather than a promise.
The preview, the stored PDF and the hash all come from one render path, so there is no seam where the bytes an approver looked at and the bytes the system kept could differ.

<Card title="How the byte-identity seam works" icon="hash" href="/greatbook/capabilities/composition-and-rendering" horizontal>
  One render path, hashed at save, re-hashed at approval, attested in the trail.
</Card>

## What you cannot do here, and why

<Frame caption="The author sees the enforced maker-checker rule on the document itself.">
  <img src="https://mintcdn.com/vinmake/NFYl2zy80-D5Iitf/images/greatbook/walkthrough/06-maker-cannot-approve.png?fit=max&auto=format&n=NFYl2zy80-D5Iitf&q=85&s=d606a8b32ec594791c53be718b39565e" alt="Document detail explaining that its author cannot approve it" width="1440" height="1000" data-path="images/greatbook/walkthrough/06-maker-cannot-approve.png" />
</Frame>

**Separation of duties, gate zero.**
The author of a document can never approve it.
The button is disabled with the reason spelled out, and the server refuses the request with a 409 even if the button were forced.

Note that this is a *third* separation, before the two gates on the money path.
By the time a composed document reaches the ledger, four distinct people have touched it: the composer, the document approver, the intake approver and the posting checker.

<Warning>
  **A composed document is not a pre-approved one.**
  Signing it says "this exists and I signed it".
  It does not say "this is correct to book", and the Clerk's queue still treats it as something a human
  has to judge at the intake gate.
</Warning>

<Note>
  **The trail names the signer.**
  Each completed approval step carries its approver identity and approval time.
  When GreatBook can resolve the final approver's user id through the trusted identity store it shows the person's identity; otherwise it shows the recorded stable user id rather than guessing a name.
  The same append-only approval evidence is what approval-sensitive Books registers use.
</Note>

## Versions, edits, and what Revise does

**Revise** creates the next version of the document.
The previous one is marked *superseded* and can no longer be approved or submitted, so **there can never be two approved versions of one document**.

Expand any row's chevron in the documents table to see the whole history.

<Frame caption="The corrected v2 is current while v1 remains visible as superseded.">
  <img src="https://mintcdn.com/vinmake/NFYl2zy80-D5Iitf/images/greatbook/walkthrough/13-revision-history.png?fit=max&auto=format&n=NFYl2zy80-D5Iitf&q=85&s=2f0175efa491d6348be8528a39f87732" alt="Typewriter version history showing current v2 and superseded v1" width="1440" height="400" data-path="images/greatbook/walkthrough/13-revision-history.png" />
</Frame>

<Warning>
  **A new version needs its own approval.**
  Approval does not carry over from v1 to v2, and you still cannot approve your own.

  And if v1 is already sitting in the Clerk's queue, v2 does not quietly replace it.
  The Clerk flags the revision and asks you to choose which version is the document of record.
  That flow is on [Working the review inbox](/greatbook/guides/review-inbox).
</Warning>

| Status                | What you can do next                                                             |
| --------------------- | -------------------------------------------------------------------------------- |
| **Awaiting approval** | Revise it, or wait for a designated approver. Submit is disabled.                |
| **Approved**          | Submit to clerk is enabled. Revising creates v2 and supersedes this one.         |
| **superseded**        | Nothing. A newer version is the head, and approving or submitting it is refused. |

<Note>
  In the version history, **By** is the **author**.
  Open the document's approval trail for the named signer and step evidence.
</Note>

## Next

<Card title="3 · Hand it to the Clerk" icon="send" href="/greatbook/guides/hand-off-to-clerk" horizontal>
  One button, and the handoff becomes part of the document's permanent record.
</Card>

## Related

* [Who does what](/greatbook/roles) - why maker is not checker, and why the old rule was decorative
* [1 · Compose the document](/greatbook/guides/compose-a-document)
