Review & Approval Workflow

Every module has a review level, which decides whether it needs sign-off and how that sign-off happens. There are three, and a module is always in exactly one of them.

• Not required — no workflow at all. The author marks the module complete when they judge it finished. Nothing blocks on it.
• Module-level — the module is reviewed and approved on its own, by people assigned specifically to it. It has its own reviewers, its own approver, and its own status.
• DRP-level — the module has no sign-off of its own. It is swept into a single review of the whole generated DRP version, alongside every other DRP-level module, and one roster signs off the pack as a whole.

Review policy is set once for the project, on the project's Modules tab, and every DRP in that project inherits it. The tab has three sections, in the order you would normally work through them.

1. 1Review level — set the level for every module at once, or per module in the table below.
2. 2Module-level reviewers & approver — who signs off a module on its own. These are stored on every module whatever its current level, so a module switched to Module-level later already has its people.
3. 3DRP-level reviewers & approver — one roster for the whole project, used by every module set to DRP-level. This is not a per-module setting: DRP-level review signs off a generated version once, so there is one roster rather than one per module.

Only a Lead Analyst can change project-level review settings. A DRP's own Review Assignments tab has the same three sections and the same controls, scoped to that one DRP, and is open to Analysts as well as Lead Analysts.

A DRP's modules follow the project's settings until somebody changes them on that DRP. Once changed, that module keeps what you set and stops picking up later project-level changes — so a deliberate exception is never quietly overwritten.

A module that no longer matches the project shows a "Differs from project settings" badge, with the project's values in its tooltip. "Reset to project" on that row re-attaches it and pulls the project's settings back down.

Customising a module and then moving it between levels does not lose its people. A module with its own reviewers, switched to DRP-level and back, still has them.

• Reviewer slot — a user holding the Reviewer or Approver role on this project.
• Approver slot — a user holding the Approver role on this project.
• Either way, the person must already be a member of the project.

Because of that, review can only be switched on for a project that already has an eligible reviewer and an eligible approver among its members. If the last eligible person is removed from the project, Requio sets every module back to Not required rather than leaving a workflow nobody can complete, and cancels any reviews that were under way.

Because roles stack, the same person can end up in both slots on one module — most often in a small workspace where one user holds both Lead Analyst and Approver. Requio allows this rather than blocking it: on a single-seat workspace, refusing would mean review and approval could not be used at all.

Review and approval are two separate jobs held by two separate roles. Reviewers check the work and mark their review complete; the approver makes the final call to approve or reject it. The approver can only finish a round once every assigned reviewer has signed off, and nobody can sign off simply by being the person who wrote or submitted the section.

• Authors — Lead Analysts and Analysts — write the content, choose who reviews and approves, and submit for review. Holding an author role never makes someone eligible to review or approve.
• Reviewers must hold the Reviewer or Approver role on the project; the approver must hold the Approver role.
• Every sign-off is recorded against the named person, and the generated document's Review & Approval table shows who reviewed and who approved each part.

On plans with more than one seat — Standard, Pro and Enterprise — you can give reviewing and approving to different people, so no single person both checks and signs off the same work.

1. 1An Analyst or Lead Analyst submits the module, confirming first who it goes to. It needs an approver assigned — only the approver can end a review — and must be in In progress or Revision required. Reviewers are optional: with none assigned it goes straight to the approver's decision, and the button reads Submit for approval rather than Submit for review. Everyone it has gone to is emailed, and it also appears in their queue on their dashboard. The module is locked for editing from this point: to change it you reopen it first, which cancels the round.
2. 2Each assigned reviewer marks their own review complete. The module only moves to Awaiting approval once every one of them has — one reviewer finishing does not carry the others.
3. 3The assigned approver approves it, which also marks the module complete, or rejects it with a reason.

A rejected module shows Revision required with the reason underneath, and every reviewer's sign-off is cleared so the round starts again once the content is fixed. If a module has an approver but no reviewers, it goes straight from In Review to the approve or reject decision.

Only the assigned approver can reject a module. A reviewer's single action is to mark their own review complete — they advise, the approver decides.

Choosing who reviews and approves a module does not save as you go. The review level, the reviewers and the approver are set together and kept until you press Save review settings; the other buttons on the page act as soon as you press them. Leaving the page without saving discards those choices.

Once a module has been submitted it must keep an approver. You can swap one person for another, but you cannot clear the slot and leave nobody — only the approver can approve or reject, so an empty slot would leave the module with no way out. Requio refuses the change and suggests naming a different approver, or reopening the module first.

Once a module is Approved or Complete its review settings are locked — the review level, the reviewers, the approver and Reset to project all stop being editable. Who reviewed a module, and under what level, is part of its record. Reopening it is the way back, and that already discards the approval. A project-level policy change skips signed-off modules for the same reason, and the confirmation dialog lists the ones it left alone.

Emptying the reviewer list while an approver is still assigned is a legitimate setup, and moves the module straight to Awaiting approval so that approver can sign off.

If the approver leaves part-way through — taken off the project, their Approver role removed, or their account deactivated — the review is not thrown away. It waits, with every sign-off given so far, and the module shows "Needs an approver — this review is waiting for one". It is counted on the Lead Analyst's "Needs an approver" dashboard tile until somebody names a new approver, who then picks it up where it stopped. The one exception is removing the last eligible reviewer or approver from the project altogether, which switches review off for the whole project — see "Who can review and who can approve".

A submitted module is read-only at every stage — In review, Awaiting approval and Approved alike. To change its content you press "Reopen to edit" first, which cancels the round, clears every sign-off, and returns it to In progress. Reassigning who reviews a module is not a content edit and does not reopen it.

A module has exactly one status — there is no separate 'content' status underneath it — shown identically on its tile, on the Review Assignments tab, on the module's own page and in the generated document. It reflects both what is in the module and where its sign-off has got to, so the same module can never read one thing on one screen and something else on another.

• Not started — nobody has put anything in the module yet.
• In progress — work has started on the module and no review round is open on it. Cover & Version Control and Review & Approval sit here by default: both accrue content from the rest of the DRP, so neither is ever Not started.
• In review — it has been submitted, and reviewers have not all finished.
• Awaiting approval — every assigned reviewer has signed off, and it is now with the approver.
• Approved — the approver has signed it off. The module is complete.
• Revision required — the approver rejected it. The reason is shown underneath.
• Complete — a module that needs no sign-off (review level Not required, or DRP-level) and has been marked complete.
• Approved (override) — a module-level module marked complete without going through the approval its review level called for. It counts as an approval, so it does not block generation, but it stays labelled as an override so the record shows what actually happened.

Mark Complete is available at any point before a module is finished — including while a review is under way. Using it then cancels that review, discards every sign-off given so far, and removes the module from its reviewers' and approver's queues. It is the deliberate escape hatch for a review that has stalled, so the review itself never blocks it, but it is always confirmed first and always recorded as an override.

Approved and the two completion states are terminal: the module becomes read-only, and editing it again means reopening it first. Reopening an approved module discards that approval and clears every reviewer's sign-off, so the next round is judged on the new content rather than the old.

A review is only meaningful under the policy it was carried out beneath, so changing a module's review level voids whatever sign-off it holds. Requio always tells you what will be lost first, and the change cannot be undone.

• A review in progress is cancelled and the module returns to In progress, with every reviewer's sign-off cleared.
• A module that is already Approved or Complete cannot have its review level changed at all — who reviewed it, and under what level, is part of its record. Reopen it first; that discards the approval and is confirmed before it happens.

Removing a reviewer mid-review cancels only that person's sign-off; everyone else keeps theirs. If the person removed was the last one outstanding, the module moves straight to Awaiting approval. The approver can be swapped for someone else but not cleared while the round is open, since only the approver can finish it.

Modules set to DRP-level are not reviewed individually at all. They are signed off together, once the DRP has been generated as a version, by the DRP's review roster.

1. 1Generate a version of the DRP.
2. 2Submit that version for review from the Versions tab. Every generated version goes through this step, whether or not any module is set to DRP-level. The DRP needs an approver named under "DRP-level reviewers & approver"; reviewers are optional.
3. 3Each reviewer on the roster marks their review of that version complete.
4. 4The approver named on the DRP approves or rejects the version. Nobody else can — not an Analyst or Lead Analyst, and not another user who happens to hold the Approver role.

If the named approver is unavailable, an Analyst or Lead Analyst can use Approve by override, which asks them to explain why. That is permitted, but the reason is permanently recorded as an override on the version and in the audit log, and the version is labelled as approved by override wherever it is shown.

Review blocks two things, at two different points.

• Generating a DRP — every required Module-level module must be Approved first. DRP-level and Not required modules never block generation: a DRP-level module cannot be approved until after generation, which is the whole point of that level.
• Approving a generated version — the same Module-level check runs again, every reviewer on the version's snapshot must have signed off, and the approver named on the DRP must approve.

When a DRP is not ready, its header says whether the holdup is incomplete modules, modules awaiting approval, or both. The Review & Approval module inside the DRP gives the module-by-module detail.

Someone whose roles on a project are only Reviewer and/or Approver gets a view of that project's DRPs built for signing work off, not writing it. It is decided project by project: a person who is an Analyst on one project and a Reviewer on another writes on the first and reviews on the second.

• DRPs list — a "DRPs you review or approve" table lists only the DRPs where they review or approve something, with "Your part" (for example "Reviewer on 3 sections, reviewer of the whole version") and "Waiting on you" (for example "2 sections · v3"). DRPs on the same project where they have no part are not listed.
• A DRP — two tabs: "Sections to review", listing only the sections they review or approve with what is needed from them, and Versions, where they mark their review of the whole version complete or, as its named approver, approve or reject it. Generate, Upload custom version, Archive, the AI Knowledgebase and Review Assignments are not shown.
• A section — the project and DRP are named above the title, the content is read-only, and the review box shows the reviewers, approver and status with their one action. Check Quality, Get AI Suggestions, the AI assistant and Save Module are not shown, and on Requirements neither are the add, link, edit, unlink and delete controls — the linked requirements are still listed in full, because that set is what is being signed off.

Everyone on a project's team — Analysts, Lead Analysts, Reviewers and Approvers — can comment at the foot of any section. Comments are threads: a first comment with replies under it. Anyone on the team can resolve a thread once it's dealt with, or reopen it; replying to a resolved thread reopens it automatically.

A comment written before the section's content last changed is labelled "Made on an earlier draft", so an old point isn't mistaken for a new one. You can delete your own comments; one that others replied to shows as "Comment deleted" so the replies still make sense.

Two modules are permanently exempt from the review workflow. They have no review level, no reviewers, no approver, and never appear as something outstanding on the Review & Approval module or either gate. This is fixed and cannot be changed for a project or a DRP.

• Cover & Version Control — its revision history is built from the DRP's real version records, so there is no independent content for anyone to sign off. Reviewing it would mean reviewing a read-out of what already happened.
• Review & Approval — it is the live summary of every other module's sign-off. Reviewing the review log would be circular, and assigning a reviewer to it would not mean anything.

Because of this, bulk actions such as "set every module to Module-level" deliberately skip these two, and their rows show no review controls.