Draft Feedback Cycle¶

A revision workflow — instantiates Formative Feedback Loop

Circulates an unfinished work product for feedback, has the author revise it, and re-reviews the revision, so the artifact improves across versions before it is ever finalized.

A Draft Feedback Cycle takes an unfinished work product — a draft, an outline, a design doc, a prototype — through feedback, revision, and re-review before the work is finalized. Its defining unit is the artifact itself: the same document improves across successive versions, and the loop closes only when the revised draft is checked against the feedback that prompted it. Unlike a conversation that discusses progress (Coaching Check-In) or a metric that flags it (Progress Dashboard), the draft cycle acts on the thing being produced, catching structural problems while they are still cheap to fix — before code is written, before the essay is graded, before the deliverable ships.

Example¶

An engineer shares a design doc for a new billing service one sprint before any code exists. A reviewer's comments aren't a verdict; they point at the two spots most worth changing next — the retry logic hand-waves idempotency, and the rollout plan has no way to reverse a bad migration. The author revises: adds an idempotency-key section, rewrites the rollout as reversible stages. The reviewer then re-reads those two sections specifically, confirming the concerns are actually resolved rather than merely reworded, and signs off. The expensive version of these problems — a double-charged customer, an unrecoverable migration in production — never happens, because they were found and fixed in a document.

How it works¶

The signal is a deliberately unfinished artifact, shared early enough that changing it is still cheap.
Feedback is feed-forward: it names the highest-leverage changes for the next version instead of grading the current one.^[1]
The author makes a real revision — the loop requires a changed artifact, not just acknowledgment.
Re-review is targeted: the reviewer checks the revised sections against the original concerns to confirm they closed.

Tuning parameters¶

Draft maturity — how finished the shared version is; too rough and feedback is noise, too polished and the author is anchored and won't change it.
Number of rounds — one pass or several; more rounds converge on quality but risk endless polishing and diminishing returns.
Feedback scope — structural (does the approach work) versus surface (wording, style); early rounds should stay structural, late rounds surface.
Reviewer set — one trusted reviewer versus many; more reviewers catch more but can conflict and overwhelm the author.
Recheck strictness — whether the reviewer re-verifies each concern was addressed or trusts the author; strict rechecks catch cosmetic non-fixes but cost time.

When it helps, and when it misleads¶

Its strength is moving error-finding upstream, where fixes are cheap, and producing a visibly better artifact rather than advice; the feed-forward framing keeps attention on the next version instead of on a verdict for the last.

Its failure mode is timing: feedback given too late — after the author has committed, or right before the deadline — becomes commentary that can't be acted on. A cycle with no real revision step is theater, and over-cycling can polish a fundamentally wrong approach instead of catching it. The classic misuse is a "review" run after the work is effectively final, to bless it rather than improve it. The discipline that guards against this is to share early while change is cheap, require a revised artifact, and re-check the revision against the concern that prompted it.

How it implements the components¶

progress_signal — the interim draft is the evidence the loop reads.
actionable_feedback — comments name the specific changes for the next version, not a grade.
learning_response — the author's revision is the response the loop requires to continue.
recheck_cycle — the targeted re-review of the revised draft closes the loop.

It does not name an underlying misconception in the person's understanding (gap_diagnosis — Misconception Probe, Formative Rubric), author the quality standard (criteria_reference — Formative Rubric), or organize peer-to-peer exchange (learner_response_channel among peers — Peer Review Protocol).

Instantiates: Formative Feedback Loop — it is the loop run on a work product, version by version, before final submission.
Consumes: Formative Rubric when the feedback is anchored to explicit criteria rather than reviewer taste.
Sibling mechanisms: Peer Review Protocol · Formative Rubric · Adaptive Practice Set · Coaching Check-In · Exit Ticket · Low-Stakes Quiz · Misconception Probe · Practice Review · Progress Dashboard · Rapid Feedback Cycle

References¶

[1] Feed-forward — feedback framed to shape the learner's next attempt rather than to judge the last one; it answers "what should change next" instead of "how good was this." A draft cycle is a feed-forward loop by design, because comments target the coming revision. ↩