Glossary

Watching a page is how you tell Amendary it matters. A page you connect is only discovered; it does nothing until you watch it, which classifies its audience (Help center or Engineering docs) and maps it to a repo. A discovered page you do not watch is never read or edited.

Mapping ties a watched page to the repo it describes, so a change in that repo can trigger a check of that page. A Notion page can be mapped to several repos, and a mapping can be narrowed to a path inside the repo. A GitHub page maps only to the repo it lives in.

A watched page with at least one repo mapping. Only mapped pages are read for a check and only mapped pages receive corrections. Corrections go to every mapped page’s own home, a Notion edit or a GitHub edit.

Where your docs live: a Notion connection, or a GitHub repo’s docs folder or wiki. Destinations are added on the Pages tab, a team can have several, and Notion and GitHub work independently. Generated docs go to the one destination you choose; corrections go to every mapped page wherever it lives.

What counts as a shipped change for a repo, set on the Repos tab: commits on the default branch (the default), commits on a branch you name, published GitHub Releases, or new tags. Help-center pages and the product-updates page follow the trigger. Engineering docs always follow commits on the default branch.

A few model-written sentences about one unit of change (a merged pull request, a direct commit, a release or a tag), kept with the changed paths and a link to the source. It orients the check and appears on the correction card as evidence. Raw diffs are processed and discarded; the summary is what is stored.

A correction is grounded when the change backs up what it says. Grounding is checked on the blocks the edit changes, against the shown change and the code after it. Only hard values gate publishing; soft values (bare numbers, Title Case phrases) are shown as “check these” and never hold.

A version, a path or a URL. A hard value in an edit that the change does not back up is “ungrounded” and holds the correction for a person, even in auto mode. Bare numbers and product names are soft values, not hard ones.

A label on a correction card saying the page or the change was too large to show the model in full, so it saw the sections around the change instead. It is a warning to inspect, never a hold on its own. A card whose matched sections were all shown whole does not carry it.

The list of corrections and product-update entries waiting for a person. In review mode and during the free trial everything waits there. In auto mode it holds only the corrections a hold applies to, with the reason on the card. Auto-applied and Resolved tabs list what went through, with Undo where available.

A reason a correction waits for a person in auto mode. Exactly five: 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 (except the narrow grounded case in a region rewrite). A proposed new page always waits, and two operational holds, “no edit drafted” and “the edit could not be planned”, wait too.

A workspace setting, available to owners on a paid plan, where a correction nothing holds is applied to the page on its own and logged. Auto mode publishes; it does not queue. The free trial stays review-only whatever the saved mode.

The default for every new workspace. Nothing is written to a page until a person applies it from the Queue. Review mode holds everything, including corrections that would pass every check in auto mode.

Amendary’s way of saying a mapped page no longer matches what shipped. It names the region of the page that is now wrong, shows it rewritten as it should read with the blocks that change, and attaches the evidence. Each region can be applied or dismissed on its own. See Queue & reviews.

A short, customer-facing entry (one to three sentences) describing something that shipped, added under a dated heading on a Notion page set to the product-updates type. One entry per repo per landing day for commits; releases and tags keep their own entries. Product updates are Notion-only and are never one entry per commit.

The shape of a page, set on its row on the Pages tab: docs and guides (prose, the default), on-call runbook, incident playbook, or product updates. It says how the page is checked and what generate produces for it. A page has one type for all the repos it is mapped to. See Document types.

The per-repo opt-in that lets Amendary write docs to that repo, as a commit or a pull request to a docs folder, or directly to the wiki. It is off by default, one target per repo, and only owners can turn it on. A repo with it off is strictly read-only, and code is never changed either way.

Restores the text a correction replaced, from the original stored in Amendary, after checking the block has not been edited since; if it has, the undo is refused. Available in the queue for 30 days after a correction is applied, on every Notion plan.