feedback_scorecards_one_at_a_time_optimal_sequence

When presenting multiple related questions/decisions to Rich, present them one at a time in a carefully-sequenced order where questions with the most knock-on effects on downstream questions come FIRST. Do NOT batch-present multiple scorecards/questions at once. Do NOT sequence by difficulty / alphabetical / creation-order / convenience.

Why — triple elevation 2026-04-24 → 2026-04-25 → 2026-04-26

Original directive (2026-04-24 T-022 F+ sub-decision adjudication):

“sorry, I need them one at a time please - be careful to ask them in the a sequence where each answer gives the maximum useful information for the next question”

First elevation (2026-04-25 Probate decision-round sequencing):

“i insist on questions being sequenced in the most logic way possible i.e. prioritise the questions which have the most ‘knock on’ effects - ask them first, so that the answers helps inform and shape subsequent questions”

Second elevation (2026-04-26 — strict-form lock after Claude was observed batching at end-of-response three times in same session even with existing memory in place):

“Can you help me ensure questions are always asked with the single highest-knock-on re-score being asked first? I.e. if there are 4 questions to be asked, first of all ask me the one which has the biggest impact on the second, which has a biggest impact on the third, which has the biggest impact on the fourth - help me with this topic as it is so important to me”

The “i insist” + “so important to me” framings make this a load-bearing discipline, not a preference. Rich elevated three times within four days. Each elevation triggered by Claude failing the discipline despite the prior elevation being in memory.

The 2026-04-26 escalation was triggered by THREE batching failures in the same session on Claude’s part:

1. “Two questions before I start authoring §1: (1) Is the table structure right? (2) Do you want me to save the UK-drift correction as a memory now?” — orthogonal questions batched.
2. “Three specific things I need your steer on: (1) Confirm starting point, (2) Confirm document structure, (3) Confirm output cadence” — dependency order was right but all three batched.
3. “OK to do all four [items 3-6]?” — listed multiple options for go-ahead in single turn.

The pattern that keeps recurring: at end of responses, Claude batches 2-3 final confirmation questions because it feels efficient. That instinct is WRONG. Batching costs Rich cognitive load and suppresses the information-compounding effect of sequential adjudication that Rich has explicitly asked for THREE times.

Batch-presenting creates cognitive load (multiple scorecards to hold in working memory). Sequencing by wrong criteria (difficulty / alphabetical / convenience) loses the information-compounding effect that sequential adjudication provides. Each decision should resolve uncertainty or scope-lock context for the next.

STRICT-FORM 2026-04-26 — pre-send single-question rule

Before sending any message that ends with a question to Rich, Claude MUST run this check:

1. Count the questions to Rich at the end of the message. If exactly ONE → send.
2. If >1 questions → STOP. Do NOT send. Build a dependency map first.
3. Identify the highest-knock-on question: which one’s answer unlocks / constrains / informs the most others?
4. Ask ONLY the highest-knock-on question in this message. Park the rest visibly.
5. Use the parked-questions pattern so Rich sees the queue + dependency reasoning + can override:

**Asking now (highest knock-on first):**
[Question 1, with full context]

**Queued behind this:**
- Q2 — depends on Q1 because [reason]
- Q3 — depends on Q1+Q2 because [reason]
- Q4 — depends on Q1+Q2+Q3 because [reason]

This pattern preserves the information-compounding Rich has insisted on AND the visibility-of-the-queue + override-ability.

Boundary test (run before every send): count question marks at end of message addressed to Rich. Greater than one → STOP, re-write to single question + parked queue.

Common failure modes Claude has fallen into:

• Asking confirmation-style follow-ups in pairs (“OK to do X? Also is Y still right?”)
• Listing alternatives as multiple questions (“Should we do A or B? And what about C?”)
• Sequence-shaping questions before the work begins (“Confirm starting point + structure + cadence”)
• “Two/three things before I start…” preamble — almost always a batching tell

ALL of the above must be re-written to a single question + parked queue.

How to apply (general — applies in addition to STRICT-FORM)

Rule 1 — One question per turn (STRICT-FORM = enforced via pre-send check)

Whenever there are N ≥ 2 related questions/decisions to surface, present them sequentially. Each turn:

• One scorecard/question in full (per feedback_always_display_full_scorecard)
• Invitation for Rich to confirm / override
• Wait for answer before presenting next

Applies equally to:

• Sub-decisions within a parent decision (e.g., T-022 F+ SD1/SD2/SD3/SD4)
• Top-level Topics within a brief/spec (e.g., Probate Topics 1-6)
• Tensions within a wave (e.g., Wave 3 T-004/T-006/T-007)
• Sections within a spec (e.g., Catala spec §1/§2/§3)
• Planning decisions within a phase (e.g., Phase C spec-ordering)
• Any other sequence of 2+ related questions

Rule 2 — Sequence by knock-on effect: HIGHEST-KNOCK-ON FIRST

Before presenting the first question, build a dependency map. Ask:

1. Which question’s answer unlocks / constrains / informs the options or scoring of the most other questions? → that one goes FIRST
2. Which questions depend on prior answers but have no downstream dependencies of their own? → those go LATER
3. Scope-settling first: decisions that establish what’s in scope come before decisions about how to package what’s in scope
4. Holistic reviews last: plan-review / critical-concerns-review / integration-tests come after all constituent decisions are locked
5. Methodology-last: decisions about methodology/process (e.g., “how do we score future decisions”) typically come last so they don’t contaminate current adjudication

Rule 3 — Explicit sequence rationale + dependency map

At the start of any sequence of 2+ questions, BRIEFLY explain the ordering logic — one sentence per dependency — so Rich can override the order if he disagrees. A small dependency-map table (2-3 columns: topic / affects / depends on) is ideal.

Example:

“Probate Topics sequenced 1→6: Topic 1 Scope first (unlocks all other Topics — determines which primitives exist); Topic 2 GrantTypeScheme second (biggest Tier-2 knock-on → drives Topic 3 A-12 subsumption + Topic 6 C-PR-1 SHACL-dispatch); Topic 3 trivially determined by Topic 2 result; Topic 4 DebtPriorityScheme orthogonal (Tier-2 independent); Topic 5 IntestacyResolution primitive-field-spec (depends on Topic 1); Topic 6 C-PR-1..C-PR-5 review last (depends on all of 1-5).”

Rule 4 — Re-sequence mid-flow if needed

If Rich’s answer to a question makes the originally-planned next question obsolete or changes its premise, say so + propose a revised next step.

Rule 5 — If Rich asks for sequencing, DO NOT just list — justify

When Rich asks “what order should I answer these in?” do a full dependency analysis BEFORE recommending. Don’t suggest the first-plausible order. Present the recommended order with explicit dependency reasoning, plus 1-2 alternative sequences considered and rejected.

Anti-patterns

• ❌ “Here are all four sub-decision scorecards for T-022 F+, make all four calls” — batch presentation
• ❌ “Do you want to do Topic 4 first or Topic 5 first?” — delegates sequencing Rich expects Claude to do
• ❌ Ordering alphabetically or by file-creation-order — ignores knock-on effect
• ❌ Ordering by increasing difficulty — often inverts the right order
• ❌ Presenting methodology-level decisions first — contaminates subsequent adjudication
• ❌ Presenting orthogonal questions in arbitrary order — defensible but wastes information-compounding
• ❌ Running a holistic plan-review before constituent decisions are locked — reviews speculate about downstream-unknown decisions

Scoring implication

If a sub-decision’s scorecard has been designed with weights/scores that assume a particular prior sub-decision outcome, re-visit those assumptions after the prior decision is confirmed. Don’t mechanically use pre-computed scores if the prior decision changed the context.

Related memories

• feedback_always_display_full_scorecard — every scorecard displayed inline in full
• feedback_always_save_scorecards — every scorecard saved to disk
• feedback_reframe_beats_reweight — when scorecards stall at 85-92%, reframe rather than re-weight