Stanford Test-Time Compute Grounding
Keep lecture evidence, project interpretation, measurement, and change authority
separate while applying test-time compute concepts to GEODE.
Workflow
- Select the lecture reference by decision plane and read it completely:
references/lecture-analysis.md for Part 2 test-time compute, or
references/lecture-05-planning-multistep.md for Part 5 planning,
multi-step reasoning, and deep research. Read both when the request crosses
those boundaries.
- Classify the request using the decision planes below.
- Read only the matching project references from
references/project-application-index.md.
- Inspect current GEODE code and tests for every implementation claim.
Historical presentation snapshots are context, never current code authority.
- If exact timing, wording, or a slide is material, follow
references/source-manifest.md and verify against the original source.
- Report lecture evidence and GEODE application as separate claims.
Decision planes
| Plane |
Question |
Do not confuse with |
| Parallel candidate width |
How many alternatives solve the same task? |
workflow fan-out or repeated benchmark trials |
| Sequential repair depth |
How many feedback-conditioned revisions occur? |
long chain-of-thought without observations |
| Inference-program search |
Which bounded operator composition should run? |
online self-modification or product promotion |
| Measurement replication |
How uncertain is one policy's measured result? |
best-of-N candidate selection |
| Promotion authority |
Which evidence may change named state or release state? |
verifier score or candidate ranking |
| Multi-step planning |
Which steps depend on each other, and which are independent? |
prose checklist or automatic execution |
| Trajectory search |
Can alternative action paths be cloned, rolled back, and scored? |
retries in one shared mutable environment |
Claim discipline
- Preserve the source labels
[직접근거], [외부연구], and [해석].
- State the search object, budget unit, verifier, measurement unit, and write
authority for every proposed compute policy.
- Distinguish oracle coverage from delivered correctness.
- Treat a trajectory as a training-data candidate only after identity, privacy,
duplication, reward quality, and evaluator-leakage checks.
- Call GEODE's current capability a direct implementation only when the input,
output, decision object, and authority match the cited operator contract.
Guardrails
- Do not call concurrent subagents parallel sampling unless they produce
comparable candidates for the same task.
- Do not call K repeated evaluations best-of-K.
- Do not call a gate a ranker merely because it chooses keep or revert.
- Do not claim GEODE implements Archon or compute-optimal scheduling without
current code and executable evidence.
- Do not infer performance scaling from observed trajectory length; run a
controlled budget intervention first.
- Keep completed state-changing trajectories out of answer fusion. Consider
fusion only before side effects, over plan or text candidates.
- Parallelize only independent subplans. Keep critical-path actions and final
synthesis under the parent.
- Do not claim LATS/tree search without cloneable state, branch isolation, and
a path evaluator.
Output contract
For a design, audit, or report, include:
- the decision plane and search object;
- lecture evidence versus project interpretation;
- current GEODE code/test grounding;
- verifier and promotion-authority boundaries;
- measured GAPs, non-goals, and the smallest justified next experiment.
1---2name: stanford-test-time-compute3description: Ground GEODE design and evaluation work in Stanford CS329A Parts 2 and 5. Use for test-time compute, planning, multi-step reasoning, deep research, LATS, independent subplans, best-of-N, repair depth, measurement replication, verifier authority, and GEODE/Eco²/SIL/Crucible comparisons.4---56# Stanford Test-Time Compute Grounding78Keep lecture evidence, project interpretation, measurement, and change authority9separate while applying test-time compute concepts to GEODE.1011## Workflow12131. Select the lecture reference by decision plane and read it completely:14 `references/lecture-analysis.md` for Part 2 test-time compute, or15 `references/lecture-05-planning-multistep.md` for Part 5 planning,16 multi-step reasoning, and deep research. Read both when the request crosses17 those boundaries.182. Classify the request using the decision planes below.193. Read only the matching project references from20 `references/project-application-index.md`.214. Inspect current GEODE code and tests for every implementation claim.22 Historical presentation snapshots are context, never current code authority.235. If exact timing, wording, or a slide is material, follow24 `references/source-manifest.md` and verify against the original source.256. Report lecture evidence and GEODE application as separate claims.2627## Decision planes2829| Plane | Question | Do not confuse with |30|---|---|---|31| Parallel candidate width | How many alternatives solve the same task? | workflow fan-out or repeated benchmark trials |32| Sequential repair depth | How many feedback-conditioned revisions occur? | long chain-of-thought without observations |33| Inference-program search | Which bounded operator composition should run? | online self-modification or product promotion |34| Measurement replication | How uncertain is one policy's measured result? | best-of-N candidate selection |35| Promotion authority | Which evidence may change named state or release state? | verifier score or candidate ranking |36| Multi-step planning | Which steps depend on each other, and which are independent? | prose checklist or automatic execution |37| Trajectory search | Can alternative action paths be cloned, rolled back, and scored? | retries in one shared mutable environment |3839## Claim discipline4041- Preserve the source labels `[직접근거]`, `[외부연구]`, and `[해석]`.42- State the search object, budget unit, verifier, measurement unit, and write43 authority for every proposed compute policy.44- Distinguish oracle coverage from delivered correctness.45- Treat a trajectory as a training-data candidate only after identity, privacy,46 duplication, reward quality, and evaluator-leakage checks.47- Call GEODE's current capability a direct implementation only when the input,48 output, decision object, and authority match the cited operator contract.4950## Guardrails5152- Do not call concurrent subagents parallel sampling unless they produce53 comparable candidates for the same task.54- Do not call K repeated evaluations best-of-K.55- Do not call a gate a ranker merely because it chooses keep or revert.56- Do not claim GEODE implements Archon or compute-optimal scheduling without57 current code and executable evidence.58- Do not infer performance scaling from observed trajectory length; run a59 controlled budget intervention first.60- Keep completed state-changing trajectories out of answer fusion. Consider61 fusion only before side effects, over plan or text candidates.62- Parallelize only independent subplans. Keep critical-path actions and final63 synthesis under the parent.64- Do not claim LATS/tree search without cloneable state, branch isolation, and65 a path evaluator.6667## Output contract6869For a design, audit, or report, include:70711. the decision plane and search object;722. lecture evidence versus project interpretation;733. current GEODE code/test grounding;744. verifier and promotion-authority boundaries;755. measured GAPs, non-goals, and the smallest justified next experiment.
mangowhoiscloud