6.5.12 · D3Research Frontiers & Practice

Worked examples — Building a portfolio and research roadmap

5,487 words25 min readBack to topic

The scenario matrix

Think of a matrix the way you would for signs and quadrants in trigonometry: rows are the dimension of variation, columns are the edge cases along that dimension. Every cell is a situation. Our job is to cover all of them — and below, every cell is filled by a numbered example (its tag A1, C4, … appears in the cell).

Dimension (row) Zero / degenerate case Typical case Limiting / extreme case Sign flips (good → bad)
A. Portfolio inventory 0 projects → A1 3–4 mixed artifacts → A2 40 half-finished repos → A3 quality-vs-quantity trade → A4
B. Reproduction gap exact match, gap = 0 → B1 small gap to judge → B2 gap so large paper is unmatched → B3 your number above paper's → B4
C. Extension result no change () → C1 modest win → C2 huge win (suspicious!) → C3 negative result () → C4
D. Roadmap time budget 0 slack (fully booked) → D1 phase fits exactly → D2 phase overruns / early → D3 phase finishes early → D4
E. Compute constraint no GPU at all → E1 one small GPU → E2 cluster access → E3 compute wasted → E4
F. Real-world / exam twist reviewer with 0 time → F1 admissions scoring → F2 tie-breaker at the top → F3 strong work, weak framing → F4

Row A — Portfolio inventory

Example A1 — the ZERO case (blank slate)

Forecast: Guess now — four things feel like more, but do they count more?

  1. Score the one deep reproduction. Why this step? We must convert "feels impressive" into the reviewer's actual formula, not our gut.
  2. Score the four shallow tutorials. Why? By the single-impression rule of our reviewer model, the headline is the best artifact, not a sum — so we take the best of the four (they are identical at ), not their total.
  3. Compare. . Why this matters: depth is weighted and rigor , so shallow breadth can never catch up.

Verify: Even if you did ten shallow tutorials, the best one still scores 6, far below 22. The zero-project case is solved by going deep once, not wide. This is the concrete reason the parent note says "reproductions first."

Example A2 — the TYPICAL case (3–4 mixed artifacts)

Forecast: Does a balanced 3-artifact set beat a lone deep reproduction (which scored 22 in A1)?

  1. Score each artifact with . Why? We need the headline before the bonus.
  2. Take the best as the headline. Why? The single-impression rule anchors on your strongest work: .
  3. Add the breadth bonus. Why this step? Three distinct pillars are present, so bonus . Why a bonus at all: covering all three pillars signals a rounded researcher, which the lone-reproduction portfolio lacks.

Verify: — the balanced portfolio edges out the single deep reproduction because of breadth, not despite it. This is the "three pillars" claim of the parent note, made numeric. The typical, healthy state of a portfolio is exactly this: one strong headline plus coverage.

Example A3 — the OVER-FULL / extreme case (40 half-finished repos)

Forecast: Does deleting work ever raise your average?

  1. Average score before pruning. Why? With 40 repos the 6-click budget applies, and clicks are uniform-random (justified above: the reviewer cannot pre-sort). Each clicked repo is finished with probability , so the expected per-click score is
  2. Average score after archiving the 35 bad ones. Why this step? Now only 5 repos exist, which is fewer than the budget of 6, so by the stated protocol the reviewer opens all 5 — and every one is good. The average is therefore (The sample size dropped from 6 to 5 because the protocol opens all repos when fewer than 6 exist — that is the stated rule, not a silent change.)
  3. Interpret the extreme. Deleting 35 repos raised the average impression from to . Why? Reviewers judge by density of quality, not count.

Verify: improvement from removing work. This is the arithmetic behind "archive old work" in the parent note — see also 6.5.10-Open-problemsin-AI-research for choosing what to keep working on.

Example A4 — the SIGN-FLIP cell (quality-vs-quantity trade)

Forecast: More repos feels like progress — but watch the sign.

  1. Headline under Option Q. Why? Adding unfinished work never raises the max (single-impression rule); and the bug can only lower it. Your best repo is untouched by the new repos, so headline stays with a real risk of dropping if the introduced bug hits the top repo.
  2. Headline under Option D. Why? Raising from 1 to 3 on the top repo is a swing:
  3. The sign flip. . Why "good → bad": chasing quantity (Q) at best holds you at 20 and at worst drops you, while depth (D) strictly rises. The intuitively "productive" choice is the losing one.

Verify: ; the depth swing is exactly (). Quantity is a trap when quality is your bottleneck — the parent note's "narrative over chronology."


Row B — The reproduction gap

The figure shows the paper's BLEU as a horizontal teal line at 27.3, a shaded teal band (its numeric edges 26.7 and 27.9 marked on the vertical BLEU-score axis), and three of your runs as points: B2's 26.9 sits inside the band (safe), B3's 19.5 sits far below it (bug), and B4's 28.1 sits above it (audit). "Inside the band = explainable by luck" is the whole visual message.

Example B1 — the ZERO case (exact match, g = 0)

Forecast: Zero gap — dream come true, or too clean?

  1. Compute the gap and its z-score. Why? Even the degenerate case must pass through the same tool (valid because the same normal noise model applies).
  2. Decide. sits dead-centre of the band — on the teal line itself in the figure. Under the normal model this is the most likely single outcome, so it is a genuine match. Why still stay alert: an exactly identical number (not just within-noise) can hint you accidentally reused the paper's released checkpoint. If you trained from scratch, is simply a clean pass.

Verify: → match. The zero cell is the calm centre of the band; every other B example is measured as a distance from here.

Example B2 — the TYPICAL case (small gap to judge)

Forecast: Guess — is "close enough"?

  1. Compute the gap. Why? We need a number before we judge it.
  2. Express the gap in units of noise. Why this tool? A raw gap means nothing without a scale. Dividing by (a "z-score" — literally "how many noise-widths away", meaningful because the noise is normal) answers "could randomness alone explain this?"
  3. Decide. is inside the band; the figure's B2 point lands inside the teal shading. Verdict: probable match, no bug hunt needed. Why: chasing a within-noise gap wastes weeks.

Verify: , so the point is inside the band , and is inside. Report it honestly in your RESULTS.md.

Example B3 — the EXTREME case (gap so large the paper is unmatched)

Forecast: Bug or bad luck?

  1. Gap and z-score. Why? Same measurement, new number.
  2. Decide. — see how far below the band the figure's lowest point sits. Under the normal model a deviation has probability essentially zero, so randomness is impossible here. Why this matters: this is a structural bug, exactly the "forgot the causal mask" story in the parent note.

Verify: by a huge margin → hunt the bug. The lesson: the same verification tool () resolves the calm zero cell, the small gap, and this extreme; only the answer changes.

Example B4 — the SIGN-FLIP case (you beat the paper)

Forecast: Is beating the paper good news?

  1. Signed gap. Why keep the sign? A negative means you exceeded the paper — the direction carries information.
  2. Decide. : too far outside the band to be a seed fluctuation, and it sits above the band in the figure. Why care? Beating a paper by usually means an evaluation leak (e.g., you accidentally tested on training data). Audit before you brag.

Verify: → investigate. A too-large positive surprise is as suspicious as a too-large negative one — both live outside the band.


Row C — Extension results (building the ratio )

The figure plots your extension in a plane: horizontal axis = fraction of cost kept, vertical axis = fraction of performance kept. The dashed diagonal is the break-even line ; the shaded region above it is ("worth it"). C2 sits well above the line (strong win), C1 sits exactly on it (no change), and C4 sits just barely above it (marginal negative-result case).

Example C1 — the ZERO case (Δ = 0, no change)

Forecast: Nothing changed — is that a failure?

  1. Compute . Why? Same tool, degenerate inputs.
  2. Interpret the break-even. exactly — the point lands on the dashed line in the figure, and . Why this matters: an unchanged result is a valid negative ("this optimizer swap does nothing here") and is worth one honest paragraph, never a headline.

Verify: and → report as a null result, not a win. Zero change is a real cell of the matrix, not a bug.

Example C2 — the TYPICAL WIN case

Forecast: accuracy lost for compute saved — good deal?

  1. Performance kept. Why? First ratio of .
  2. Cost kept. Why? Second ratio.
  3. Trade ratio. Why the division? To collapse the trade into one verdict number.
  4. Interpret. : you kept more of the performance-share than of the cost-share. Strong, publishable extension. See the figure — the point sits well above the break-even line.

Verify: . Also sanity-check the parent's claim " compute savings": . ✓ Units: are all dimensionless (ratios).

Example C3 — the EXTREME case (huge win, Δ ≫ 0 — be suspicious)

Forecast: Massive accuracy gain and 4× cheaper — dream, or red flag?

  1. Compute . Why? Quantify the "too good."
  2. Interpret the magnitude. with — the point would sit far up in the top-left of the figure, way above break-even. Why be suspicious: a -point accuracy jump while getting cheaper contradicts the usual accuracy–cost frontier. Such a result almost always means a leak or metric bug (train/test overlap, evaluating on the wrong split).
  3. Action. Re-run with a held-out set and a fixed seed before claiming anything. Extraordinary demands extraordinary checking — link the audit trail into 6.5.1-Interpretability-and-explainability to show why it improved, or admit the bug.

Verify: and → treat as suspect, not triumph. The extreme-win cell is where honesty matters most.

Example C4 — the SIGN-FLIP case (negative result, Δ < 0)

Forecast: You lost accuracy and barely saved compute — is this worthless?

  1. Ratios. Why? Same machinery.
  2. Trade ratio. Why? Verdict.
  3. Interpret. (accuracy fell), yet technically — but only barely, because you paid a -point accuracy hit for a mere compute cut. This is the "barely worth it, probably not" cell. A good write-up says why the long-range dependencies mattered here (link to 6.5.1-Interpretability-and-explainability to actually visualise what got lost).

Verify: , , and compute cut . A negative- result with barely above 1 is exactly the kind of honest science the parent note praises.


Row D — Roadmap time budget

Example D1 — the ZERO-SLACK case (fully booked)

Forecast: No slack — how bad is one surprise?

  1. Slack available. Why? Slack is planned time minus committed time.
  2. Effect of the shock. Why this step? Any overrun with zero slack pushes the deadline one-for-one:
  3. Lesson. A zero-slack plan has no absorption capacity — the first surprise slips you. Why it matters: always reserve buffer (see D2).

Verify: slack, so a 1-week shock → 13-week finish, exactly 1 week over. The degenerate "fully booked" plan is fragile by construction.

Example D2 — the TYPICAL case (phase fits exactly)

Forecast: Does a plan with a buffer actually finish inside the window?

  1. Sum committed time. Why? Compare against the 12-week window.
  2. Check against the window with buffer. Why this step? The 1-week buffer sits on top: .
  3. Interpret. The phase fits with exactly 1 week of unused buffer — the healthy, typical outcome. Why it matters: a plan that fits and keeps buffer is what "success metric on time" looks like.

Verify: and slack → fits on time. This typical cell is the target every roadmap phase should aim for.

Example D3 — the EXTREME case (overrun via Parkinson's Law)

Forecast: 8 of 12 weeks gone — comfortable or doomed?

  1. Time left. Why? The denominator of the whole question.
  2. Current rate. Why? To project forward we need a velocity. You did the skills (6 weeks) plus of the repro, so effective repro time spent weeks for .
  3. Weeks needed for the last 40%. Why divide? Remaining work ÷ velocity = time.
  4. Compare. on track, slack weeks.

Verify: ✓. The slack ( weeks) is your buffer against Parkinson's Law — time-box the write-up into it so the work does not expand to fill it.

Example D4 — the SIGN-FLIP case (finish early — what to do)

Forecast: Rush ahead, or polish?

  1. Value of Option X over 3 weeks. Why? Baseline plan.
  2. Value of Option Y over 3 weeks. Why? It front-loads value then flatlines.
  3. Compare. . Why: a finished, framed artifact (Y) out-values a rushed head start (X). Slack should first buy polish, then progress.

Verify: → polish the current artifact before racing ahead. Finishing early is a "good" surprise that still needs a decision.


Row E — Compute constraint

Example E1 — the ZERO-GPU degenerate case

Forecast: Is a smaller-scale experiment "real" research?

  1. Feasibility check. Why? Confirm it fits the hard budget.
  2. Expected information value. Why? A proxy that agrees of the time still resolves most comparisons; the null (no experiment) is a coin flip at :
  3. Decide. Positive gain, within budget → run it, and state the proxy caveat. Why: an honest small-scale result beats a grand experiment you cannot run. See 6.5.3-Federated-learning for another "compute-is-elsewhere" mindset.

Verify: ✓ and ✓ → the degenerate no-GPU case still yields publishable evidence.

Example E2 — the TYPICAL case (one small GPU)

Forecast: 8 configs on a modest GPU — one week enough?

  1. Total cost of the sweep. Why? Compare against the weekly budget.
  2. Compare to budget. Why this step? — it does not fit in one week.
  3. Fix. Why? Drop the 2 least-promising configs ( saved): , leaving hours headroom.

Verify: (over by 8); after cutting 2 configs, with 4 hours spare. The typical single-GPU life is prioritise, then sweep.

Example E3 — the EXTREME case (cluster access)

Forecast: 64 GPUs — surely 64× faster?

  1. Split the work. Why? Only the parallel part shrinks with more GPUs (this is Amdahl's Law).
  2. Wall-clock time on 64 GPUs. Why divide only the parallel part? The serial 4 hours stay fixed; the 16 parallel hours split across 64 GPUs:
  3. Real speedup. Why? Compare to the 20-hour single-GPU run:

Verify: hours and speedup . The extreme "infinite compute" cell is bottlenecked by the serial fraction — throwing GPUs at it saturates fast.

Example E4 — the SIGN-FLIP case (compute wasted on the wrong thing)

Forecast: More tuning hours feels better — does it help here?

  1. Value of Plan A. Why? Invalid results are worth nothing no matter the compute.
  2. Value of Plan B. Why? Fix first (0 value for 10 h), then valid tuning:
  3. The sign flip. . Why "good → bad": pouring compute into a broken setup is negative-productivity — busy but worthless. Correctness gates value.

Verify: → fix the pipeline before spending compute. Wasted compute is the "good intentions, bad outcome" cell of Row E.


Row F — Real-world / exam twist

Example F1 — the ZERO-TIME reviewer (degenerate)

Forecast: With no scrolling, which number does the reviewer see?

  1. Identify what is read. Why? With zero scroll time, only the first item counts.
  2. Compare to your best. Why this step? Your strongest work (22) is below the fold and never seen — a -point impression lost purely to ordering.
  3. Fix. Why? Reorder so the best project leads: impression jumps from 13 to 22 at zero cost.

Verify: Impression when best (22) is buried; reordering recovers the full 9-point gap. The zero-time reviewer is why the parent note says "lead with your best work."

Example F2 — the TYPICAL admissions scoring