The two-person approval queue, and why three gates guard it
A crawl proposes a draft; it never publishes one. Submitting and approving an article are always two different people, and the queue enforces that three separate ways.
Nothing your assistant reads reaches a resident unread by a second person. The Approvals screen is where that rule lives, and it's built as two separate queues because they're fixed by two different acts.
Pending approval: new or changed content, waiting on a first read
Every card here shows a line-level diff — rendered in the content's own text direction, because a Hebrew paragraph diffed inside a left-to-right container is unreadable in exactly the way that makes a reviewer approve without reading it.
The Approve button is gated three separate ways, and each one states itself before you click rather than after:
- Department (maker-checker). You can only approve content owned by a department you belong to.
- Not your own submission. If you submitted it, you can't be the one who approves it — even if you hold the approve permission.
- A submitter must exist at all. An article that somehow reached the queue with no recorded submitter can't be approved by anyone, because there's no one for the approver to be different from. This fails closed rather than quietly letting it through.
Approved and retrievable aren't the same instant. The status flips immediately, but the article isn't answerable by the assistant until its text has been re-embedded — if that's still in progress, the confirmation says so rather than letting you assume it's already live.
Stale: approved content whose source has since changed
A re-crawl doesn't overwrite what residents are being told. It parks the new text separately and marks the article stale, and this queue is where a department decides what to do about it.
If there's a parked revision, you'll see the same kind of diff — this time between what's live and what the source now says — and one control to accept it. Accepting is not approving: it moves the article back into the pending-approval queue, because it's still a change one person is proposing, not one that's been reviewed. A stale entry with nothing parked (the source went unreachable, or someone flagged it manually) has no diff to accept; it needs a human to re-verify it directly instead.
Accepting a parked change is checked against the exact version of that change you were looking at. If a fresh crawl updates the same article while your review is still open, the accept is refused rather than silently applied to text you never actually read.
Why this is three gates and not one
A single "can manage knowledge" permission would let one person author and approve their own work, which turns an approval queue into a formality. Splitting authoring and approving into separate permissions — and then still checking department and self-submission on top of that — is what keeps a department's ownership of its own public-facing answers real rather than nominal.