Plan Records

plans / frontmatter · source

Frontmatter and status

---
status: draft
summary: Determine whether the effect survives two control families
next_action: Design the first pilot
owner: researcher
reviewer: collaborator
current_phase: Phase 1
created: YYYY-MM-DD
updated: YYYY-MM-DD
---

Required frontmatter is status, summary, next_action, created, updated. Optional fields are owner, reviewer, current_phase, gate, revisit_when, promote_when, superseded_by, abandoned_because. Use YYYY-MM-DD-lowercase-topic.md filenames. Status is draft, active, blocked, gated, backlog, superseded, completed, abandoned. next_action identifies one next step and is empty when the plan is finished. A completed plan adds a Completion report and Evidence; a superseded or abandoned plan adds Disposition and Evidence. Active plans live directly in plans/; other statuses have matching subdirectories. Gated, backlog, superseded, and abandoned plans carry the status-specific reason and reconsideration fields. A plan that answers its question negatively is completed, not abandoned.

Legacy spellings complete (for completed), proposed (for draft) validate with a warning, and a plans/complete/ directory is accepted for them. Run the validator with --write-plan-index to regenerate plans/README.md. Dashboards, editors, and other tools should read diagnostics from --format json.

plans / body syntax

Body structure

Required headings are ## Objective, ## Existing evidence, ## Phases, ## Risks and controls, ## Terminal conditions. Organize phases beneath ## Phases and fill each section of this outline with the plan's content.

# Plan title

## Objective
## Existing evidence
## Phases
### Phase 1: Development
#### WP1: Validate scoring
#### WP2: Run paired pilot
### Phase 2: Confirmation
## Risks and controls
## Terminal conditions

Add ## Confirmation reserve when the plan is intended to produce a confirmatory claim. Terminal records add the closing sections specified below. Phase and work-packet headings organize the body; their numbering is local to the plan.

plans / work-packet syntax

Work-packet records

A work packet assigns part of a phase to one owner. The released schema requires bounded phases but leaves packet format to the project. The suggested body fields below record ownership, dependencies, resources in units, and the gate. Use consistent labels within a project.

#### WP1: Validate scoring

**Owner**: scoring researcher
**State**: awaiting design review
**Inputs**: scoring script and known-answer cases
**Depends on**: approval of the scoring design
**Output**: validation report linked from the pilot experiment
**Resources**: estimated 2 CPU minutes of a 10-CPU-minute
phase estimate; no paid compute
**Review status**: pending; no execution approval recorded

**Gate**: all predeclared known-answer checks must pass.
If they fail or cannot be evaluated, record the defect and
request review. WP2 cannot use the scorer until the gate
passes and its own execution scope is authorized.

Link packet outputs to experiment records and artifacts. The plan guide distinguishes packets, phases, experiments, and gates.

plans / metadata locations

State, resource, and review records

A review log can use a Markdown table with columns Date | Subject and revision | Reviewer | Decision | Conditions | Evidence. Preserve prior decisions when the reviewed design changes. A current summary such as “revision requested” should point to the entry that explains it.

plans / resources and spend · current skill source

Resources and spend

A plan states its resource estimate in units and names its packages and their experiments. It carries no money: no ceiling, allocation, rate, or spend figure. Spend authority, including the plan's ceiling, any package allocations, and their dated history, is recorded in plans/spend/AUTHORITY.json under the plan's filename stem, and money per attempt in plans/spend/LEDGER.md. The spend reference gives both formats.

Explain uncertainty with ranges, bounded scenarios, or unknowns; use outcome probabilities only when there is evidence for them. Conditional scientific branches need explicit resource estimates and entry conditions, not invented expected-value probabilities. A projection across providers or devices keeps the configuration each option needs and leaves the rate to the spend files.

Contingency

Contingency is capacity inside the approved ceiling, recorded as an allocation in the authority file. It is not spent and is not added again to the forecast. Keep it distinct from the statistical confirmation reserve, which holds back evidence rather than money. Budget room cannot replace either scientific or human-review gates, and a larger ceiling does not authorize a different study.

Check headroom before admitting work

Before admitting work, check headroom as the spend reference derives it, using a conservative bound for concurrent attempts and permitted retries. Coordinate reservations so separate agents cannot each spend the same headroom. A documented runner limit is a safeguard only if the runner actually enforces it. If credible exposure exceeds the approved ceiling, or a material unknown prevents bounding it, stop for a decision on scope, resources, or budget.

A scientifically completed plan can have financial settlement pending; say both. Carry lessons about rates, idle time, and retries into successor estimates without authorizing successor jobs.

plans / review gates

Phases and review gates

Review the plan before execution and after evidence returns. At each phase gate, a human chooses whether to continue, revise, wait, or close. A gated follow-up needs approval before any new job is submitted. The gated status requires a testable external blocker, such as missing data, compute, a dependency, or a collaborator's decision. Use backlog for viable work waiting to start, and specify when to reconsider it.

plans / confirmation reserve · source

Confirmation reserve

A plan that will end in a confirmatory claim carries ## Confirmation reserve, written at creation and before any exploration, with both **Held back:** and **Decision rule:**. Reserve the intended source before exploration can expose it. If confirmation was not planned at creation, amend the plan to identify a genuinely unexposed source and obtain review of the decision rule before accessing it.

## Confirmation reserve

**Reserved:** the draw-1 scene set (`DRAW_STRIDE = 1000`, as used by
[[EXP-211-second-architecture-replication]]) for every work package in this plan, and the `origin`
value domain from [[EXP-209-cross-domain-entity-transfer]]. A WP may not use either for design or
piloting. Each WP exposes its frozen analysis to draw 1 once for adjudication; an outcome-informed
repair spends that reserve and requires a new untouched pool.

**Decision rule:** a WP's mechanism claim is accepted only if, on the reserved draw-1 scene set, the
package's own pre-registered primary statistic keeps its sign with the 95% scene-clustered interval
excluding its registered null, and the sign is unanimous across at least 12 of 15 blocks. A WP that
clears on draw 0 and fails this on draw 1 is recorded as draw-specific and its claim is withdrawn, not
rescoped.

For access history, outcome-informed revisions, and the difference between another run and independent evidence, follow the confirmation workflow.

plans / decisions · source

Decisions

A plan is edited in place during review and execution, so its body shows the option that was chosen and loses the one that was not. ## Decisions keeps the choice: one dated entry per choice among credible options, newest last. Each entry names the option that lost, what the choice costs or forecloses, and what settled it: a review, an owner instruction, or a tracked decision request.

## Decisions

- **2026-08-16** — Closed the plan as completed rather than adding a
  real-training phase after [[EXP-002-accumulation-comparison]] passed: the
  objective was scoped to the simulator. Forecloses any claim about real models
  from this plan; a replication would be a new plan. Source: closure review.

If no one with the same information could credibly have chosen otherwise, the change is an edit and gets no entry. Entries are never edited: a reversal is a new entry naming the earlier one. A choice that changes one experiment's design belongs in that experiment's record. The validator checks that entries are dated, run newest last, and link to notebook files that exist.

plans / completion · source

Completion report

Before marking a plan completed, write ## Completion report. Record each goal's outcome (met, unmet, or void), supporting evidence, limitations, follow-ups, successor plans, and artifact status. Link to experiment and finding records for the numbers. The validator also accepts Completion report, Completion, Completion note, Completion audit, Outcome, Execution outcome, Execution result, Closed, Disposition as exact, case-insensitive heading matches.

---
status: complete
updated: 2026-08-04
summary: "Reality leak in belief attribution is 0.682 under a bare continuation and 0.000 under an explicit question. EXP-167 shows that discourse placement and the number of examples explain the contrast, not query form. Under both controls, all three forms have zero reality leak. The causal test was therefore unnecessary and was not run."
next_action: null
---

## Outcome

Closed 2026-08-04 by [[EXP-167-belief-form-placement-kshot]] without running the causal test.

- **No residual query-form effect.** Under a document-licensing preamble plus k=8 demonstrations, the
  three query forms span **0.000**: all at 1.000. The apparent form main effect (0.789 vs 1.000) is
  produced entirely by the single uncontrolled cell.
- **Either control alone repairs the continuation.** 0.325 with neither; 0.831 with a preamble only;
  1.000 with demonstrations only.
…
What survives is a methods note for Paper 2, not a mechanism claim …

plans / retraction · source

Retraction notice

When an experiment corrects a finished plan's outcome, keep the original text and add a notice beneath it beginning **Retracted YYYY-MM-DD.. State the corrected values, link to the correcting experiment, and date the notice when applying the correction. The experiment records the superseded values. In the same session, search the notebook for every record that relied on them.

plans / agent plans

Native agent plans and notebook plans

Use Claude Code plan mode or Codex's task and multi-agent tools to plan the immediate work. Give another executor the notebook plan's path and phase name. The plan records scope and review decisions. Paid compute, destructive actions, publication, external writes, and unattended execution still require their own authorization.