How do I define a review cycle so it does not repeat indefinitely?

Make the review a sequence of bounded passes, not an open invitation to keep improving everything. Before each pass, write down four things: its purpose, what reviewers may comment on, who resolves disagreements, and the condition for closing it.

For example, a draft might have a structure pass, a content pass, and a final proofread. The structure pass is not also a chance to debate wording; the proofread is not a new strategy discussion. Give each pass a feedback deadline. At that point, the designated decision-maker sorts comments, agrees on the in-scope changes, and records the outcome. A settled point stays settled unless something material has changed.

Ask what changed and what the new comment affects. A correction identifies a specific problem against an agreed requirement or a newly available fact—for instance, a required section is missing. Reopening a settled issue usually repeats a preference or argument that was considered before, without new information or a changed requirement.

You can label incoming comments:

1. In scope: addresses this pass's stated purpose.
2. Correction: points to a missed agreed requirement or clear error.
3. New issue: may matter, but was outside this pass.
4. Reopen request: challenges a recorded decision.

For a reopen request, ask the commenter to state what new fact, constraint, or requirement warrants reconsideration. If there is none, keep the recorded decision and move on. If the new issue could materially change the result, decide explicitly whether to pause, revise the plan, or defer it.

Name one person who can make the final call for that pass; reviewers contribute advice, but the decision-maker resolves conflicts. That person can be the project owner or another agreed lead—the right choice depends on your working arrangement.

Make closure observable. For example: “This pass closes at [date/time]. The decision-maker will accept, reject, or defer each in-scope comment and record any approved changes. New requests go on a separate list. The pass reopens only if [named trigger] occurs.” A useful trigger is specific, such as a changed requirement, a factual correction that affects the output, or a newly identified omission that prevents the stated purpose from being met. Avoid “until everyone is happy”: it gives no workable stopping condition.

Use this as a starting point and replace the bracketed parts:

Review plan — [work item]

1. Pass 1: Structure — Check [sections/order] against [agreed goal]. Comments on detailed wording are deferred.
2. Pass 2: Content — Check [accuracy/completeness against agreed requirements]. Suggest changes only where they address those requirements.
3. Pass 3: Final check — Correct typos, formatting inconsistencies, and approved changes. Do not reopen settled choices unless the trigger below applies.
4. Feedback deadline: [date/time]. Decision-maker: [role or name].
5. Closure: At the deadline, the decision-maker logs each comment as accepted, declined, or deferred. The pass then closes. Late feedback goes on a follow-up list unless it identifies a material error, changed requirement, or agreed reopening trigger; the decision-maker states whether that warrants reopening.

Worked example: If someone asks to change a heading during the final check after its wording was approved in the content pass, record it as a reopen request. If they point out that the heading misstates a newly changed requirement, assess that change against the trigger and record the decision. This keeps the process firm without treating useful new information as forbidden.