SC Contractor Task Quality - Review Standard

Purpose

Defines how to review and close a contractor's work on a ClickUp task. This is the companion standard to SC Contractor Task Quality - Pre-Work Standard: pre-work covers what we hand the contractor; this standard covers what happens when they hand it back.

Bad review patterns -- vague feedback, scope-creep masquerading as bug fixes, inconsistent approve/clarify decisions -- cause errors to repeat across cycles and erode trust in both directions. This doc names the patterns and the choices a reviewer makes at the close of every task.

Scope

Applies in two contexts:

AM-review subtask — when an AM-review subtask has been opened on a client-facing parent task per Markdown Task File to ClickUp SOP §3c, and the Account Manager is reading the work product before the parent ticket closes.
Post-hoc sampling — during the weekly sampling pass of the previous week's closed tickets (see §Post-hoc sampling).

The conventions below (AC walk-through, feedback tone, decision documentation) apply identically in both contexts. The synchronous review status that previously gated every ticket has been retired (2026-05); contractors close their own tickets at complete with the Evidence bullet as the per-ticket validation artifact.

Acceptance Criteria confirmation

What: Before any other review action, walk every bullet in the task's ## Acceptance Criteria section and mark each as met / not met / partially met.

How:

Open the task description and read AC. Skip the chat history — AC is the contract; chat is context.
For each criterion, verify it on the actual deliverable (the live URL, the merged PR, the deployed config), not on the contractor's screenshot or report.
Mark partials explicitly: a criterion is "partially met" only if the unmet portion is small enough to land as a follow-up (see Follow-up vs. send-back).

Why: A task with ## Acceptance Criteria but no AC walk-through at review time is operationally identical to a task with no AC at all. The walk-through is the only thing that converts AC from theater to reality.

If the task has no AC (i.e., it was assigned before the pre-work standard was enforced): construct AC retroactively from the task description and the chat history, post them as a comment on the task ("Reading AC from the description as: 1...2...3... -- confirming below"), and walk through those. Do not approve a task whose success criteria cannot be stated.

Feedback tone

Two tones, named explicitly so the contractor can act on them differently.

Blocking feedback

A defect that prevents closure. Marked clearly: Blocking: or Must fix: at the start of the bullet.

Format: Blocking: <what's wrong> -- <how to fix> -- <which AC it violates>
Example: Blocking: Carousel uses custom code -- swap for the chosen WP plugin (Smart Slider 3 per spec §2.1) -- violates AC #3 (no custom code).

The contractor cannot close the task until every Blocking item is resolved.

Advisory feedback

A suggestion that improves the work but does not prevent closure. Marked clearly: Advisory: or Nice-to-have: at the start.

Format: Advisory: <observation> -- <suggested change> -- <reason>
Example: Advisory: H1 font weight is 600, design kit suggests 700 -- consider bumping unless deliberate -- minor consistency improvement.

The contractor may address advisory items in this task or open a follow-up; their call.

Why the labels matter: Without them, contractors over-rotate on small advisory comments (wasting hours) or ignore blocking comments (forcing a second review cycle). Naming the severity at the start of every bullet removes that ambiguity in one word.

What not to do:

"It looks off" -- not actionable; either advisory with a specific suggestion, or blocking with the AC violated.
Long unstructured paragraphs mixing 3 blockers and 2 nice-to-haves -- separate into bullets, label each.
Sarcasm or rhetorical questions ("did you even read the spec?") -- not feedback, just damage. Replace with the blocking statement.

Decision documentation

What: When the reviewer makes a judgment call -- accepting a deviation from spec, downgrading a blocker to advisory, deferring an AC item to a follow-up -- the call is documented in the task comments.

Format:

Decision: <what was decided>
Why: <one-line rationale>
Tradeoff: <what was given up, if anything>

Example:

Decision: Accepting H1 weight 600 (spec said 700) for this task.
Why: Design kit was updated to 600 last week; spec is stale.
Tradeoff: Need to update spec in next sprint -- filed follow-up CL-RS-2026-05-001.

Why: Decisions made verbally or in Slack vanish from the audit trail in 90 days. The next contractor reading this task to understand a similar pattern needs to see the call and the reasoning. Comments on the task survive; Slack threads do not.

When to skip: Routine approvals where everything went per spec. The default outcome doesn't need a "Decision: approved" comment; the task status moving to COMPLETE is the artifact.

Follow-up vs. send-back

A binary at the end of every review: send the task back (move to in progress, list blockers) or accept and open a follow-up for any remaining gaps. Don't approve-with-list-of-blockers — that's neither.

Send back (rework)

The task is missing something that was in the original AC.
Or, the work product has a defect on a criterion that was actually met-in-spec.
The contractor stays on the task; status moves back to in progress.
AM-review subtask context: the AM-review subtask moves back to in progress; the contractor fixes on the parent ticket; the AM re-checks once fixed.
Post-hoc sampling context: see §Post-hoc sampling for the reopen-vs-follow-up decision.

Accept + follow-up

The original AC is met (possibly with documented decisions).
New work was identified during review that's adjacent but out-of-scope.
The original task closes; new ClickUp task(s) are opened for the follow-up.
New tasks reference the original (Follow-up to <task_url>).

Heuristic: if the contractor's last commit could plausibly be the "final" commit on this task, you're in follow-up land. If they need to make more commits to satisfy the original AC, send it back.

What not to do: "Almost done -- can you also add X, Y, Z" as a single feedback dump. That's three scope items disguised as a review. Either send back with the blockers (and let X/Y/Z be follow-ups), or accept and file the three follow-ups explicitly.

Time-entry validation

What: When approving a task, glance at the contractor's logged time against the estimated-effort.

The validation is light, not forensic:

Within ~20% of estimate: no comment.
20-50% over: flag in approval comment, no action. ("Note: logged 5.5h vs. 4h estimate -- carousel debug took longer than expected.")
50%+ over and no explanation: ask. ("Saw 9h logged on a 4h estimate -- can you note what consumed the extra time? Trying to recalibrate estimates.")
50%+ under: also worth checking. ("Logged 1.5h on a 4h estimate -- did anything ship short of full scope?")

Why a light touch: Time entries are not a basis for payment disputes -- they're calibration data for future estimates. Forensic time auditing destroys the trust that the standard depends on. The right reaction to a chronic over-runner is not policing; it's better estimates next time.

Deferred to M7b cron: Automated time-entry hygiene checks (no missing entries, no entries on closed tasks, no entries from before task assignment date) will run as a scheduled symphony-flow job per FR-050. This standard's role is the human review at task close — not the automated drift check.

Quality tagging

What: When a task surfaces a quality issue — either during this review or after it was previously closed — the reviewer applies the appropriate quality:* tag from the SC ClickUp Tag Taxonomy. The tag is the audit-trail artifact; it persists on the task across reopens.

Three tags, three trigger moments:

quality:rework — apply when sending an AM-review subtask back for a blocking defect found pre-client. The move of the AM-review subtask (or parent) to in progress (per Follow-up vs. send-back §Send back) is the same moment the tag goes on. Remains on the task even after re-close. Distinguished from quality:escaped: rework = caught pre-client; escaped = caught post-release.
quality:escaped — apply when a previously-closed task is found defective in the wild (defect surfaced in production, reported by client, caught by a downstream task, or noticed on later review). Apply either by reopening the original task or by tagging a follow-up task that links to the original. Captures the "oversight" case — what AC or validation-evidence-rule should have caught.
quality:partial-met — apply when closing a task whose AC walk-through marked one or more criteria as "partially met" by mutual agreement, with the unmet portion deferred to a follow-up or accepted as a known limitation. The decision comment names the unmet portion.

How to apply:

Tag in the ClickUp UI (Tags field on the task) or via clickup_add_tag_to_task if doing it programmatically.
Tags persist; do not remove them on re-close.
The reviewer also leaves a one-line comment explaining the trigger: quality:rework — AC #3 not met (custom carousel code), sending back. This pairs the tag with context so the audit trail is readable.

Why: Tags give us reporting. Per-contractor quality:rework rate, per-domain quality:escaped count, partial-met patterns across a quarter — these surface only if the tagging discipline is consistent. The Quality tag family is small on purpose; resist proposing new variants without a documented recurring pattern.

What not to do:

Don't apply quality:rework for advisory feedback. Advisory items are not defects.
Don't omit quality:escaped on a follow-up because "the original is already closed." The whole point of the tag is that closed-then-defective is the case we want to count.
Don't manually create new quality:* variants in ClickUp. Propose them via PR to the taxonomy first.

Approve vs. clarify

The final action on a task: approve (close) or clarify (post a comment and wait).

Approve

All AC met (per walk-through)
All blocking feedback addressed
Time-entry sanity check passed
Any deviations documented as decisions

For an AM-review subtask: close the AM-review subtask at complete; the parent contractor then closes the parent at complete. For a sampling review: leave the original at complete (no action needed for a clean sample). Add a one-line approval comment if anything notable happened (decision documented, follow-up filed). Otherwise the status state is sufficient.

Clarify

Use when you cannot yet make the approve/send-back call. Examples:

AC mentions a behavior that requires production data to verify -- ask the contractor to confirm.
A screenshot looks right but you cannot reproduce locally -- ask for steps.
The deliverable is in a staging environment you don't have access to -- ask for access.

Post the question as a comment on the AM-review subtask (or on the original ticket for sampling). The status stays where it is — no special status change, no special tag. A pending question is a question, not a rework signal.

If clarification reveals work is needed: move to in progress with blocking feedback per Follow-up vs. send-back.

If clarification reveals work is fine: approve.

What not to do: Sit on the task without commenting. The contractor cannot tell the difference between "you're thinking about it" and "you forgot". State Reviewing — back in <timeframe> if you need time.

Quick reference

Situation	Action
AC all met, no surprises	Approve, move to `complete`
AC met but new scope discovered	Approve + open follow-up task
Original AC unmet (AM-review subtask)	Send back with `Blocking:` bullets, tag `quality:rework`
Cosmetic issue, AC met	Advisory feedback, approve
Defect found in previously-closed task (sampling, in-the-wild)	Reopen or open follow-up per AM's judgment, tag `quality:escaped`
AC partially met, by agreement	Approve + tag `quality:partial-met`, document deferral
Need more info to decide	Clarify comment, no status change
Big estimate overrun, no explanation	Approve + ask in comment
Conflicting spec docs	Apply doc precedence per Markdown Task File to ClickUp SOP §3a

Post-hoc sampling

Cadence: Every Monday, the Account Manager reviews a random sample of the previous week's closed tickets (Monday–Sunday).

Selection: Random ~10–15% of the week's closures. The AM may add targeted spot-checks on top of the random sample (e.g., a new contractor's first ticket, a high-value client deliverable, a domain where defects have been trending) but the random baseline is the floor.

Review: Apply §Acceptance Criteria confirmation, §Feedback tone, and §Decision documentation exactly as you would for an AM-review subtask. The fact that the ticket is already closed does not change the review bar. The Evidence bullet on the AC is the primary check.

Defect handling: Apply the follow-up-vs-send-back heuristic from §Follow-up vs. send-back:

Reopen the original (status complete → in progress — the task stays in active-work; per Workspace Setup SOP §5.2, there is no separate completed-work list as of 2026-06-08) when material rework is needed — the contractor needs to make further commits/changes to satisfy the original AC, and shipping a follow-up would amount to splitting a single fix in two.
Open a linked follow-up ticket when the contractor's last output could plausibly be the final one with a small fix, or when the new finding is adjacent rather than corrective. The follow-up references the original (Follow-up to <task_url>).

In both cases:

Apply the quality:escaped tag (per §Quality tagging).
Leave a one-line context comment on the original ticket: quality:escaped — sampled YYYY-MM-DD, <one-line defect>, action: reopened (or action: follow-up filed <task_url>).

What this replaces: the synchronous review status that previously gated complete. Sampling is the post-hoc accountability mechanism; the AM-review subtask (for client-facing deliverables, per Markdown Task File to ClickUp SOP §3c) is the pre-release safety net for client-visible output. Internal/non-client work flows TODO → IN PROGRESS → COMPLETE on contractor self-attestation backed by the Evidence bullet.

Why sampling rather than 100% review: SC does not have dedicated reviewers. A random ~10–15% sample provides defect telemetry (per-contractor patterns, per-domain trends, AC-quality signals) without creating a synchronous bottleneck. The bar is calibrated against the quality:escaped rate: if it rises persistently, increase the sample size or add targeted bias; if it stays near zero across multiple weeks, the sample can shrink. This is an operational dial, not a fixed rule.

SC Contractor Task Quality - Pre-Work Standard -- companion standard for task creation
SC ClickUp Tag Taxonomy -- canonical list of approved tags, including the quality:* family
Markdown Task File to ClickUp SOP -- task creation and update procedures
SC Task Data Standard -- universal status/priority model
SC SOP Standard -- authoring conventions

Revision History

Date	Version	Change	Author
2026-05-12	1.0	Initial release. Codified the six review concerns: AC confirmation, feedback tone, decision documentation, follow-up vs. send-back, time-entry validation, approve vs. clarify.	Symphony Core Systems Team
2026-05-21	1.1	Added Quality tagging section defining when reviewers apply `quality:rework`, `quality:escaped`, `quality:partial-met` from the new SC ClickUp Tag Taxonomy. Updated Quick reference table with corresponding rows.	Symphony Core Systems Team
2026-05-28	1.2	Removed `review` status from the workflow. Reframed §Scope around two contexts: AM-review subtask (client-facing pre-release) and post-hoc sampling. Added new §Post-hoc sampling section with weekly cadence, random 10–15% selection, AM-judgment defect handling. Simplified Clarify path (no status change, no tag). Updated Quick reference, quality:rework definition. Issue #42.	Symphony Core Systems Team

Purpose​

Scope​

Section index​

Acceptance Criteria confirmation​

Feedback tone​

Blocking feedback​

Advisory feedback​

Decision documentation​

Follow-up vs. send-back​

Send back (rework)​

Accept + follow-up​

Time-entry validation​

Quality tagging​

Approve vs. clarify​

Approve​

Clarify​

Quick reference​

Post-hoc sampling​

Related Documents​

Revision History​