How Amendary works

You install the Amendary GitHub App on the account or organisation that owns your repos and pick the repos to share. The App reads repository contents and metadata so it can see what landed. Code is never changed.

Then you add a destination: where your docs live. A destination is a Notion connection or a GitHub repo (its docs folder or wiki). A team can have several, and Notion and GitHub work independently.

Connecting a destination only makes pages discoverable. Nothing happens to a discovered page until you watch it. A watched page is one you chose. A mapped page is a watched page tied to the repo it describes, with an audience (Help center or Engineering docs) and a shape (docs and guides, runbook, incident playbook, or product updates).

Unmapped pages are never read for a check and never edited. A Notion page can be mapped to several repos. A GitHub page maps only to the repo it lives in. See Pages & mapping.

Engineering docs are checked per landed commit on the default branch, one unit of change at a time (a merged pull request or a direct commit). Customer-facing pages follow the change trigger you set per repo: commits by default, or a branch, published GitHub Releases, or tags.

Checks never run per open pull request; a change counts once it has landed. Prose files in the repo (Markdown, docs, help, legal, marketing) are not evidence of product behaviour and are left out of change summaries, matching and grounding.

For each unit of change the model sees a short summary, the changed paths, and the diff itself (whole when it fits, otherwise the parts most relevant to the page). For each mapped page it sees the page text: the whole page when it fits, or the sections that match the change. Nothing from an unmapped page is sent.

Every input that comes from your data is marked as untrusted content. The model names a region of the page and writes it as it should read; code then works out which blocks change, are added, or are removed.

A correction must be backed by the change. Hard values are versions, paths and URLs. A hard value in the edit that the change does not back up holds the correction for a person. A correction that removes a value the change does not mention is held. An edit that removes or shrinks content is held.

Additions are held too, with one narrow exception: an addition inside a region rewrite on the page that describes the changed repo, where no block is deleted, the evidence is complete, every inserted hard value appears in the shown change or the code after it, and no inserted sentence is already on the page. Soft values (bare numbers, Title Case phrases) never hold; they are shown as “check these”.

New workspaces start in review mode: every correction waits in the Queue until a person applies or dismisses it. On a paid plan an owner can switch to auto mode in Settings. The free trial is always review-only.

Auto mode applies corrections on its own. Exactly five things still wait for a person: a hard ungrounded value, a removed value the change does not mention, an edit that removes or shrinks content, a possible decision-record supersession, and an addition outside the grounded case above. A proposed new page always waits. Two operational holds also wait: “no edit drafted” and “the edit could not be planned”. The card names the reason. See Queue & reviews.

A correction goes to the page’s own home. On a Notion page it is a direct edit of the affected blocks, with unchanged formatting preserved; when the edit cannot be placed exactly, Amendary posts a page comment instead of guessing.

On a GitHub page it is a commit or a pull request, as you chose for that destination, and only where GitHub docs writing is turned on for that repo. A repo with it off is strictly read-only.

Every correction records the change summary and source link, the model draft, the applied text, and the exact text it replaced, in an append-only log. Raw diffs are not kept.

Undo lives in Amendary, not in your Notion plan. For 30 days after a correction is applied, the queue offers an Undo that first checks the block has not been edited since, then restores the stored original. If someone edited it in between, the undo is refused rather than overwriting their work. More on storage and access in Security; terms are defined in the glossary.