Send a document for review

Between draft and published there is a fourth status: in review. It exists so somebody can read a document before your agents start quoting it.

In review is not searchable#

A document in review is exactly as findable as a draft: nothing finds it, and no agent can answer from it. Moving a document into review changes nothing about a live call.

What changes is the label, and that is the point. In a collection of thirty drafts, the ones in review are the ones somebody has finished writing and wants read. The status filter on the document list has an entry for it, so you can pull up that pile and nothing else.

The three moves#

Open the document.

• Send for review takes a draft to in review.
• Back to draft takes it out again. One action, two meanings: the author pulling their own document back, and the reviewer returning it for more work. Nothing distinguishes them afterwards.
• Approving is just Publish. A document in review publishes exactly like a draft, and publishing is still the only step that makes it answerable.

Repeating a move you have already made is never an error. Sending a document that is already in review, or returning one that is already a draft, succeeds and changes nothing, so a second click costs you nothing.

Published and archived are not part of the loop#

A published document cannot be sent back for review. Its passages are live in search, and a status change on its own would leave them answering calls while the console showed the document as in review. Edit its text instead: that takes it out of search and returns it to draft, and from there you can send it for review.

Read the warning on the edit screen before you do that to a document that came from a file, a website or your own storage. Saving text over one of those replaces it: the stored original goes, and from then on your typed text is the only content of record. If the document is one you typed in the first place, there is nothing to lose.

An archived document cannot be sent for review either. Publish it, then edit it. Archiving is not a way to park a work in progress.

Who can move a document#

Account administrators. A member can write a document and edit a draft, but the lifecycle actions are not shown to them at all: sending for review, returning to draft, publishing and archiving are one permission, not four.

Anything driven by an API key is not role checked. A script holding a valid key moves documents regardless of what its author can do in the console, which matters if you are counting on the role to hold the line.

What this does not enforce#

Read this part before you write the review step into a procedure.

In review is a coordination marker between administrators, not an approval control. The same administrator can send a document for review and publish it a second later, and nothing objects. Who sent it is not recorded anywhere that publishing checks, so it cannot refuse the person who did.

If you need genuine four eyes, where whoever wrote the document cannot be the one who approves it, this status does not give it to you. Treat it as what it is: a note between administrators that a document is ready to be read. If the rule matters to you, it is a working agreement between people, and the status is where you write it down, not what holds it up.

Documents that caused a wrong answer#

Flagged documents, on the Knowledge screen, is the other half of a review: not "is this ready to publish" but "a reader was given a wrong answer out of this".

A document arrives here when somebody reviewing a reported answer confirms it was wrong and names the document that caused it. The queue is ordered by how many reports name each one, because a document reported eleven times is a different problem from one reported once.

There are two ways out, and only one of them is a button:

• Fix it. Edit the document and publish it. Republishing closes the flag by itself, because changing the content is the answer. Asking you to click a second time to say "yes I fixed it" is how a queue fills with documents that were already corrected.
• Dismiss it, when the wrong answer was not this document's fault. A reason is required, and your name goes on it, because that is a claim about somebody else's review.

The same page shows where your knowledge base is wrong overall: which documents cause the most confirmed-wrong answers, each one's share, and how much of your wrong answers can be pinned on a document at all rather than on the agent's instructions or a question your documents simply do not cover.

Each document also carries the count on its own screen, beside how often it was retrieved and cited. Read them together: two confirmed-wrong out of three citations is a document to fix today; two out of nine hundred is a hard question answered badly twice.