Documentation

Human Review Gate

Review a draft the way readers see it. Edit the rendered post in place, every change saves to the draft, and comments anchor to the exact words.

Reviewing a draft in chat costs more the better the draft gets. You describe an edit in prose, wait for the agent to apply it, then re-read the whole piece to check it understood you. Three small changes become three round-trips and a full re-read. And there is no way to say "this claim needs a source" or "does this land?" without derailing the edit loop, because everything you type is treated as an instruction.

The Human Review Gate moves that work onto a page. The agent opens a review session, hands you a link, and blocks. You read the draft in the real post template and change what you want changed, in place. Every edit saves straight to the draft as you make it. When you have also said whatever needed saying, you press Done once.

What you get on the page

The draft renders in the live post template, with the real typography, spacing, and media. You are judging the thing itself, not a markdown approximation of it.

  • Edit in place, saved as you go. Click any paragraph and it becomes its markdown source, right where it sits. Change it, click away, and it renders again. The change is written to the draft at that moment, not held back until you finish. Empty it out and the block is gone.
  • Edit the headline. The title and subtitle are editable the same way. They are separate fields on the post rather than part of the body, so they travel as their own before and after values.
  • Comment on the exact words. Select any span of text and leave a note attached to that span. It shows in the rail on the right, highlighted where it belongs. A comment does not have to be an instruction: "needs a source" and "does this land?" are useful things to say and they no longer cost you an edit cycle.
  • Comment on things that are not text. The hero image and other non-text elements are individually selectable, so you can say what is wrong with the picture without describing which picture you mean.
  • Delete without explaining. Mark an element for deletion and move on. The deletion travels as an explicit operation, so nothing depends on the agent inferring intent from a sentence.
  • Resolve as you go. Comments can be resolved and unresolved, and they survive a reload. You can leave the tab, come back, and pick up where you were.

Your edits are live. What you are reading is the draft itself, so there is no version of it sitting somewhere waiting to be approved.

Comments are different. They are notes for the agent, so they are delivered when you press Done, which is also what tells the agent you have finished. Without that signal a review where you only edited and never commented would leave it waiting until the link expired.

What the agent receives

Your edits come back as a positional diff, and the agent is told they are already applied. Only the blocks you actually touched appear in it. That distinction matters more than it sounds: a full-body replacement invites the agent to re-read everything and quietly restyle paragraphs you never looked at. An operation list says exactly what changed and leaves the rest provably alone.

The diff is a record rather than a task. Because your edits went straight into the draft, an agent that re-applied them would double-apply your change.

Comments are the part the agent acts on. Each comes back anchored to the passage it was written about. The agent reads what you changed, acts on your comments, honours the deletions, and re-runs the proofreader before anything is published.

Comments that survive edits

An anchor is stored as the quoted text plus a window of the words around it, not as a character position. Character positions are the obvious approach and the wrong one: edit a paragraph near the top of a post and every position below it shifts, so every comment underneath now points confidently at the wrong words. That is the worst way for a review tool to fail, because it fails silently.

Instead, each comment is re-located when the page loads. If the text is still there it re-attaches, even if it has moved because you inserted three paragraphs above it. If the wording drifted slightly it re-matches and says so. And if the text it was about is genuinely gone, the comment is marked orphaned and shown as orphaned, rather than being re-homed onto whatever now occupies that spot. You always know which of those happened.

Access and expiry

The review link carries its own access token, so there is no login step. Open it on your phone, on a second machine, wherever you actually read.

Links expire, 24 hours by default. That is deliberate: the agent is waiting on this session, and a link that never expires is a way to wedge it forever. An abandoned review resolves on its own and reports itself as expired rather than blocking indefinitely. Re-opening review for the same post returns the session you already have instead of minting a second link, so two conflicting sets of edits can never be submitted against the same draft.

Comments live with the session and expire with it. They are working notes for the review in front of you, not a permanent editorial record attached to the published post.

Using it from an agent

Two tools drive the gate:

  • create_review_session takes a post UUID and returns the review URL. Give the URL to the reviewer.
  • get_review_feedback reads the session. It returns pending while you are still working, submitted with {diff, comments, deletions, title, subtitle} once you press Done, and expired if the link lapsed. diffAlreadyApplied is true: the edits are in the draft already.

An agent that has opened a review session should not publish that post until the reviewer presses Done and the comments have been acted on.

Want this page as machine-readable markdown? GET /docs/features/human-review-gate.md