Weekly review

Needs and produces

You need an active or recently completed motion and a question that can be answered from its records. The review starts with the object a person sees in the app, such as a worksheet, sequence, workflow, or Inbox conversation, and keeps its link. It then follows that object to the owning run, preserving state, attempt, provider, credits charged, structured error, and any receipt returned by the actual run.

The output is a short review per motion: the question, a one or two sentence evidence-backed answer, the object link, run state, and quoted error when one exists. It states the proposed bounded change, whether it spends credits or repeats anything external, and its result if applied. It also reports the leading metrics: qualification rate, reply rate, credits per qualified lead, and one change selected for each motion.

The review is not a permission to re-run a whole campaign. A succeeded step with a receipt is finished. A completed run can be measured, while a queued, paced, capped, unknown, or upstream-waiting item needs its own classification. This distinction keeps the weekly pass from turning normal timing and safety limits into avoidable spend.

Read the visible object and its run

Open the object in its owning screen before looking at aggregate metrics. A worksheet cell question starts with the cell, its column, and the run that settled it. A sequence question starts with sequence state, enrollment, sender, sending hours, and caps. A workflow question starts with the workflow and its run. A cost question starts with finished runs and charged credits. The minimum evidence that settles the question is better than a dump of every log.

Architect uses the diagnostics skill to classify the result as running, queued, paced by a cap or sending hours, waiting on an upstream column, missing a connection, empty provider answer, failed with an error, or a likely product defect. Pending, queued, paced, capped, and unknown are not failures, and none of them is zero. Quote the state or error that supports the explanation.

Metrics summarize finished runs. They do not repair a run or prove that a particular effect happened. Use a trace for the one run in question when the review needs node-level evidence. The trace is the source for each node's state, attempt, output, receipt, and error. Take identifiers from the object and trace you inspected, never from a remembered name or a guessed identifier.

Interpret qualification, replies, and cost

Read qualification from the worksheet's actual evidence and score, not from an assumed row count. A column empty on every row can mean its gate reads a column that has not settled, or that it was added after rows landed and never ran on them. A score that appears stuck can be waiting on an evidence column that failed or is still running. A daily cell limit is workspace pacing, not a worksheet defect.

Read reply rate from the sequence and conversation state, not from a delivery request. A sequence that is enrolled but silent may not have started, may lack a connected sender, may be outside sending hours, or may be at a cap. A reply ends the lead's sequence run, so review the stop state as well as the conversation itself. A conversation status is not proof of delivery when a send result is unclear.

Read credits from finished runs and charged-credit records. Higher-than-expected credits can result from a column rerun from the top that billed a sample twice, contact data running before a selective fit gate, or an expensive column placed before a cheaper filter. These are testable explanations. They are not reasons to claim that a cost is wrong without inspecting the responsible runs and row scope.

Choose one bounded change per motion

A useful weekly review turns one proven issue into one bounded change. It may be a retry of failed rows, a continuation of remaining rows instead of a full column rerun, a named connection to add, a moved gate, or a workflow-node repair. Say whether the change can spend credits or repeat an external effect. Show scope and estimate before a retry that spends credits, then follow it to a final result.

Do not hide a defect by changing providers or writing a manual cell value. Name the defect and retain the object and run identifiers needed to report it. Cancel only a run the user wants stopped, then read its final state. When a play output already exists, skip that step or reorder later work rather than rebuilding it. A play teaches the order of work, but each skill and tool keeps its normal operating rules.

1. 1

   Pick one live motion

   Ask Architect to apply plays and diagnostics to a named motion. In the owning app screen, confirm the visible object and link before treating an aggregate number as the subject of review.
2. 2

   Read evidence in order

   Architect reads the object, its owning run, and the specific trace if needed. Check the state, attempt, provider, charged credits, receipt, and structured error, then classify the state rather than calling every delay a failure.
3. 3

   Calculate the leading signals

   Architect reports qualification from worksheet evidence, reply outcomes from sequence and conversation state, and cost from finished runs. Check that empty, queued, paced, and unknown outcomes have not been converted into zeroes.
4. 4

   Propose one narrow repair

   Architect identifies the least action that addresses the proven issue. Check its affected rows or node, whether it spends credits or repeats an external effect, and the estimate when a priced run is involved.
5. 5

   Read back and schedule the next check

   Architect follows any accepted change to final state and returns the result. Check the object again in its owning screen, then record the leading metric and review date rather than declaring success from the request alone.

Credits and review scope

The review begins with reads, but a repair can have a price. Keep paid work tied to the exact rows, node, or action that failed. Inspect the current capability contract and estimate before a live call, and use the stated maximum-credit ceiling. The completed run, not a preview or a planned change, establishes the charge and final state.

Work through the review one motion at a time. The plays skill says that two plays should not run against the same audience, because the same person could be touched twice. Final external copy is shown before a send, but the weekly review still begins by reading the object and run. The weekly completion report names the chosen play, skill, outputs, missing accounts, credit estimates for paid steps, and the next leading metric.

When it goes wrong

If a run has succeeded with a receipt, do not run it again. If it failed before any effect, retry the failed node rather than the whole run. If the effect definitely did not apply, retry with the same idempotency identity. An accepted retry is not a finished result: follow it to terminal state before putting it in the next weekly metric.

A timeout, lost connection, or missing receipt means the outcome is unknown. Check the outside system or the trace before retrying. A paused or checkpointed run continues from its checkpoint, not from the beginning. When an external effect cannot safely repeat and its outcome remains unknown, stop and report the evidence already collected. Never retry an email, direct message, or post just because the client did not return a delivery confirmation.

If a sequence is enrolled but silent, inspect start state, sender connection, sending hours, and caps before changing copy or enrollment. If a column is blank, inspect the gate, upstream settlement, and whether the column ran for existing rows before entering values by hand. If the review cannot settle one question from the available object and run evidence, continue with Find out why something failed and report the exact state, link, and quoted error instead of guessing.

Leading metric and next play

Track qualification rate, reply rate, and credits per qualified lead with the evidence window and finished runs that produced them. The immediate success condition is one real, read-back change per motion, not a blanket assertion that all systems are healthy. Keep the next review focused on whether that specific change altered the measured condition without creating a duplicate effect.

Continue with Keep the CRM clean when relationship records need a weekly evidence pass, or Clean up a worksheet when the review establishes that source, column, score, or provenance structure is blocking qualification.