Review changes and use history
Review turns a proposal into a recorded human decision. Editors and Owners can decide where the item and audience permit it. A Viewer does not gain that right from a link, and MCP-authenticated AI actors cannot approve reviews.
Review a proposed change
- Open Review queue → Pending to find proposals waiting for a decision.
- Open an item and read its target, reason, review version and proposed effect.
- Choose Compare changes. Check Comparison baseline so you know which saved content is being compared. Read review version opens the exact proposed content when you need the whole page or its comparison is unavailable.
- Inspect Reference changes, including Added, Removed and Edited entries, as well as body text. Open the actual Library or document evidence before accepting a factual change.
- Choose a decision and inspect its confirmation.
To find correction work, open Review queue → Changes requested, then Filters → Audience. Choose To me, From me, or All to change whose requests you see. Audience controls appear only in Changes requested.
| Decision | Result |
|---|---|
| Approve | Publishes an eligible Context candidate and settles the affected reviews shown in the confirmation. |
| Request changes | Records a required reason (up to 2,000 characters) and routes correction to Chat owner, Me, or All editors. An unavailable chat owner cannot receive it. |
| Reject | Rejects the candidate and may also reject later drafts continued from it; inspect the affected versions first. |
Edit directly, when available, takes responsibility for correction and opens the editable target. It is not a shortcut that approves the existing proposal.
The Context page's Draft pending review banner has View review, View changes, Request changes, and Approve actions where allowed. View changes is that banner's label; the queue's comparison button is Compare changes.
Reviews can be Pending, Changes requested, Approved or Rejected. These are separate from whether a page is an MCP private edit, a saved browser draft, or a published version. Browser Save draft and autosave make a draft readable to authorized workspace Editors and Owners; they do not themselves submit an explicit Review item. Viewers continue to read published content.
Configure Review policy
An Owner opens Settings → Content policies → Review policy. Read and save the workspace's actual values:
| Control | What to check |
|---|---|
| Policy preset | Balanced is the new-workspace default. Conservative, Balanced and Fast-moving change the risk posture; customized values can appear as Custom. |
| Manual review from | The selected risk level and higher enter the review queue. Balanced starts at Medium. |
| Review what agents write | On by default. MCP/OAuth/token-authored writes wait for approval. Turning it off allows those writes to follow the person's publication path, while preserving the policy and audit record and other safeguards. |
| Auto-approve by risk | Off by default in a new Balanced workspace. Allow risk levels explicitly and set whole-day delays from 0 to 30; zero means no waiting period. High-risk automation needs its separate acknowledgement. |
Automatic approval applies to eligible queued work and remains subject to review safeguards; it does not certify factual accuracy. For Low and Medium, the risk level must be at or below Manual review from before you can allow automatic approval. Follow the displayed instruction when an option is disabled. High is independent of that threshold and requires its separate risk acknowledgement before you can enable it. Safe formatting/link-only approvals have their separate Lint settings.
Approve a fixed selection
Use row checkboxes or Select all N shown, then Approve selected. A document group also offers Approve selection. Inspect the preview's eligible, skipped and automatically settled reviews, then confirm the displayed Approve N action.
A fixed selection contains at most 5,000 reviews and expires after 15 minutes. After expiry or a changed candidate, preview again. Selection does not silently include later-loaded queue items. Read per-item results after a partial failure or interruption; confirmed decisions remain saved, so refresh before selecting the remaining work.
Undo a decision when available
Look for Undo approval, Undo rejection, or Withdraw change request in the detail actions, just after a decision, or in bulk results. The person who decided or an Owner may undo; any Editor may undo an automatic approval so it waits for a person.
Undo restores the affected published/draft versions and review state, and leaves a visible undo record in History. A newer edit or changed result can make it unavailable. Decisions from before undo support and approvals reviving an archived page cannot be undone. A restored correction assignment keeps its original expiry. If the recorded result is no longer current, use View page history or Review later changes instead of repeating a stale action. These are browser actions, not MCP approval tools.
Undoing a first publication can leave the page without a published version. Check the actual reader and sharing state after every decision or undo.
Handle overlapping edits
A Context reconciliation item needs Open reconciliation and its dedicated reconcile/discard workflow. Its generic Approve/Reject actions are unavailable because a generic decision would not merge the text. If another reviewer owns the correction or a version has changed, refresh and coordinate.
A review clock in the Context/Agent explorer belongs to a review of the current draft and is visible only to Editors and Owners. Superseded reviews may remain in the queue without that clock. Publication of changed content produces the separate 72-hour recent-change marker.
Read page history
- Open History on the Context page. Versions are newest first beside a history graph.
- Read whether an entry is the current draft or current published snapshot. Changes compares a version with the version it was based on, which need not be the immediately preceding revision number.
- Use Compare two versions, then Earlier version and Later version, to select another pair. The comparison orders them oldest first; the same version cannot occupy both sides.
- Inspect body and Reference changes. Identical body text can still have different references or metadata.
For example, drafts v2 and v3 can both continue from v1: Changes on v3 compares it with v1. Select v2 and v3 explicitly to compare their proposals. A cross-branch comparison does not merge or publish either one.
Wide screens start in Split, phones in Unified. Split columns identify Base version (earlier) and Compared version (later); + and − identify added and removed lines. Current published marks the reader-facing version when it is in the pair. A higher revision number is not automatically published.
Load older versions fetches earlier Context entries where available. Use Scroll history graph, including its arrow-key control, for wide branches. Missing or hidden prior versions produce Changes unavailable and an explanation; absence is not proof that no earlier work existed.
Agent history keeps the latest 50 versions without Load older versions. Library history offers version downloads rather than text restoration. See Agent pages and Library.
Start a draft from older content
Editors and Owners can use Start a new draft from this version where offered. Check the revision in the confirmation, create the draft, then inspect it before publishing Context or activating Agent content. Existing publication/activation remains until that separate action. The first eight characters of the new draft ID can appear in the success message; they are not its history revision number.
A row already current has no such action. In an Agent comparison, the action targets the selected Later version. If you intend the earlier one, use that version's row. The new draft also retains its reference information; compare it before deciding what to publish.
The page revision v3 is unrelated to dtxWiki software version 0.2.1. Chats uses page revision numbers for Input version, Base version, Editing version and Cited version so you can match a call to History.
If a review will not complete
Refresh the exact review and inspect its error. Page publication and review completion are separate: a notice can say publication succeeded but completion failed. Check both the published version and queue state before retrying. If operator repair is required, contact the administrator.
Next: Context pages, Chats, or troubleshooting.
Implementation reference: review UI labels, review policy defaults, selection limits, version comparison, reference comparison, Context history.