Research Notebook Reference

documentation/ guide and reference

Each record owns one kind of information and follows a durable contract. The machine-readable schemas below are synchronized with skill release v0.2.0. Publication guidance links to the current skill source. Installed skill files remain the format authority when a local notebook differs.

reference / invariants · source

Ownership rules

01

Raw outputs are immutable inputs. Markdown records point to them with job identity, revision, parameters, provenance, and hashes when practical.

02

Predictions and decision thresholds are written before outcomes are inspected and are never rewritten afterward.

03

Single-experiment analysis stays in its experiment file. A finding exists only when evidence spans experiments.

04

Indexes and status pages point to authoritative records instead of copying their conclusions.

05

A terminal job becomes processed only after its evidence is durable and the notebook passes validation.

06

A plan coordinates bounded work. Each action still requires appropriate authority.

07

Each estimand carries its registration status, and a claim cites the estimand. What informed a design is written at the design moment; it cannot be recovered later.

08

A corrected value is stated beside the superseded one, and the same session searches the notebook for every record that relied on it.

reference / structure · source

Directory structure

project/
├── lab-notebook/
│   ├── STATUS.md
│   ├── QUESTIONS.md
│   ├── PRIORITIES.md
│   ├── CHANGELOG.md
│   ├── experiments/
│   │   ├── README.md
│   │   ├── EXP-001-short-topic.md
│   │   └── EXP-001-short-topic.annex.md
│   ├── findings/
│   │   ├── README.md
│   │   └── 2026-08-10-cross-experiment-result.md
│   ├── plans/                  # optional
│   ├── reports/                # optional
│   ├── papers/                 # optional authored manuscripts
│   ├── references/             # optional cited-paper archive
│   ├── kb/                     # optional stable reference notes
│   ├── causal-models/          # optional mechanism hypotheses
│   ├── jobs/processed/         # optional runner fallback
│   ├── GLOSSARY.md             # optional
│   ├── BIBLIOGRAPHY.md         # optional
│   ├── RUNNER.md               # optional
│   ├── CLAIMS.md               # optional
│   └── PUBLICATION.md          # optional
├── scripts/                    # executable research code
└── data/                       # large or structured outputs

Markdown records remain small enough to review and version. Scripts and large artifacts stay in project storage; experiment records preserve the command, revision, parameters, artifact location, and content hash needed to recover a result.

Top-level files

FileQuestion it ownsAdd it when
STATUS.mdWhere does the project stand now?Baseline
QUESTIONS.mdWhat is known, open, or blocked?Baseline
PRIORITIES.mdWhat should happen next?Baseline
CHANGELOG.mdWhat was learned or decided, and when?Baseline
GLOSSARY.mdWhat do local terms, symbols, and acronyms mean?Terminology needs a stable definition
BIBLIOGRAPHY.mdWhich papers matter and why?Related work is tracked or cited
RUNNER.mdHow does this project submit, inspect, retrieve, and process jobs?The project uses a compute runner
CLAIMS.mdWhich claims belong to each paper, what role do they play, and what supports them?An argument needs evidence tracking
PUBLICATION.mdWhere are the manuscript and packets, and what blocks submission?A paper enters preparation
COMPANION-DOCS.mdWhich reports, guides, talks, or IP documents accompany the work?Several artifacts need an index
QA.mdWhich questions should a talk or defense answer?Preparing a presentation

Schema 5 defines the baseline paths: STATUS.md, QUESTIONS.md, PRIORITIES.md, CHANGELOG.md, experiments/README.md, findings/README.md.

Directories

DirectoryContentsAdd it when
experiments/One mutable record per experimentBaseline
findings/Dated, immutable cross-experiment synthesesBaseline; it may remain empty
plans/Versioned contracts for bounded research objectivesWork spans phases, agents, or sessions
reports/Longer living analyses and figuresA synthesis is too large or changeable for a finding
papers/Canonical Typst manuscripts and their shared bibliographyDrafting inside the notebook
references/Downloaded cited papers, source notes, and indexesArchiving or annotating literature
kb/Stable reusable methodology and comparisonsMaterial is reference, not evidence
causal-models/Working mechanism hypothesesSeveral interventions inform one mechanism

reference / formats · source

File-format contracts

A path determines the record type. Headings and field names carry machine-readable state; prose carries evidence and interpretation. Keep the fixed shape below while allowing projects to add domain-specific sections that do not duplicate another record's ownership.

PathRequired or conventional shapeChange policy
STATUS.md# Project status; a ## Snapshot with phase, science status, established result, open work, next action, publication state, and last-updated fields; then ## NavigationLiving front door. Keep it short and point to owners.
QUESTIONS.mdOne ## RQ#. Title block per question, with Question, Status, optional Answer, and Evidence fieldsStable IDs. Update status and links without copying result tables.
PRIORITIES.md# Research priorities, last-updated date, one ## Current focus, a short checkbox ## Queue, and an optional testable-predictions tableLiving queue. Remove completed items; do not mirror runner state.
CHANGELOG.mdNewest-first YYYY-MM-DD: event lines naming the result or decision, evidence owner, and consequenceAppend research events, not routine edits or status flips.
experiments/README.mdExperiment links grouped by current status and research questionUpdate whenever experiment membership or status changes.
experiments/EXP-*.mdTitle and metadata; hypothesis; method; numbered estimands and registration; informed-by links; predictions and decision rule; runs; results and prediction outcomes; conclusion; follow-ups; artifactsMutable through the experiment lifecycle. Never rewrite preregistered content after outcomes are inspected.
experiments/*.annex.mdBreakdown tables or worked cases supporting one experiment's headline. The filename carries the experiment ID; no status field.Supporting analysis, not a separate experiment.
findings/README.mdDated finding links with one-line claims and source experimentsUpdate whenever a finding is added or superseded.
findings/YYYY-MM-DD-*.mdTitle; date, status, questions, and experiments; then claim, evidence, synthesis, scope and threats, consequences, and sourcesImmutable synthesis. Add a successor or correction pointer when evidence changes.
plans/*.mdYAML frontmatter with identity, status, owner, reviewer, phase, and dates; Markdown goals, phases, gates, current state, and terminal dispositionVersioned contract. See the plan schema.
CLAIMS.mdA table with ID, Role, Claim, Status, Evidence, and Paper columnsLiving argument. Every row cites direct experiment or estimand evidence.
PUBLICATION.mdProject publication status followed by one ## Paper block per manuscript, with key, draft, venue, headline result, blockers, and venue tableLiving submission state. External dates require a source.
GLOSSARY.mdCategory ## headings and one alphabetized ### Term entry per project-specific term, symbol, or acronymLiving vocabulary. Link definitions that depend on evidence or a method decision.
BIBLIOGRAPHY.mdThematic ## sections and one ### Paper entry with citation, short summary, project relevance, and source or local linksLiving annotated bibliography.
RUNNER.mdProject-specific commands for submit, status, logs, artifact retrieval, cancellation, processed checks, and final markingLiving adapter to an external job system.
reports/, kb/, causal-models/Markdown with a descriptive title, provenance links, and the sections its subject needs. These directories have purpose contracts rather than one global schema.Reports may change; knowledge-base notes are stable reference; causal models remain distinct from observations.
papers/Canonical Typst manuscripts plus one shared references.bibAuthored source. Venue packets are external derivatives.
references/Cited PDFs, source inventories, manifests, and tracked annotationsPDFs may be ignored caches; source records remain versioned.
jobs/processed/<backend>/<job>.jsonOne JSON object per terminal job with the schema's required backend, job, terminal status, evidence, and notebook-revision fieldsImmutable idempotency record, used only when the runner lacks processed state.

reference / papers · source

Manuscripts and submission packets

A paper's manuscript is its complete, continuing source. A submission packet is a derivative prepared for one venue. The two artifacts have different lifetimes.

Canonical source

Manuscript

lab-notebook/papers/name.typ

Natural length. Continues through arXiv versions, review, and post-publication revision.

Venue derivative

Submission packet

external paper workspace

Venue template, page limit, and anonymization. Frozen while submitted and at camera-ready.

The content invariant is packet ⊆ manuscript. A packet may omit material to meet a venue limit, but it cannot introduce content absent from the manuscript. A frozen packet can therefore remain behind a manuscript that continues to develop.

Edit the manuscript first and port changes into packets in preparation. A reviewer-driven revision or camera-ready phase may make the packet lead temporarily; back-port those changes before manuscript editing resumes. PUBLICATION.md records each packet's venue, state, and synced-as-of date.

Default manuscript source

New notebook manuscripts use Typst with Arkheion 0.1.2. This neutral, natural-length layout is independent of any venue template. All manuscripts in papers/ cite one shared papers/references.bib.

#import "@preview/arkheion:0.1.2": arkheion

#show: arkheion.with(
  title: "Working title",
  authors: (
    (name: "Author Name", affiliation: "Institution", email: "author@example.org"),
  ),
  abstract: [Write the abstract here.],
)

= Introduction

#bibliography("references.bib")

reference / record kinds

Experiments and plans

The two record kinds that grow have their own pages. The experiments page holds the record contract, the status vocabulary and its legacy spellings, estimand registration, annexes and duplicate IDs, and the register-and-process workflow. The plans page holds the frontmatter and status vocabulary, the review-gate diagram, confirmation reserves, completion reports, and retraction notices. Both pages render their vocabularies from the same schema copy this page uses.

reference / claims · source

Claim ledger evidence

CLAIMS.md uses the columns ID, Role, Claim, Status, Evidence, Paper. Roles are major, candidate major, supporting. Statuses are supported, provisional, blocked, refuted, retired, with live (for supported) and withdrawn (for retired) accepted as legacy spellings. Every row cites at least one experiment record. A finding may supply synthesis, correction, or interpretation context, but cannot replace experiment evidence. Papers consume evidence and do not belong in the Evidence cell. When the experiment declares estimands, cite the estimand as EXP-NNN:E#: the validator resolves it and warns when the claim draws on a found estimand or on a gate.

Example claim rows

IDRoleClaimStatusEvidencePaper
C1 major In the deterministic toy simulator, accumulated batches remain inside the preregistered 0.02 equivalence margin. supported EXP-001:E1, EXP-002:E1, EXP-002:E2 gradient-accumulation-note
C015 major Belief and reality use the same value slot. The router, rather than separate value representations, selects between them. live EXP-034, EXP-034b belief-routing
C017 supporting Reliable tracking of information visible to different agents appears between the tested 3B and 7B models. Qwen and Mistral results support the routing explanation. live EXP-026, EXP-028 belief-routing

The first row is from the repository's synthetic example and cites estimands. The other two are from the belief paper's notebook and cite records, since they predate estimand registration there; the major claim rests on two experiments and the supporting claim names the size range it was tested at. That notebook writes live for supported.

If no experiment owns a required analysis, create an analysis experiment that records its inputs, method, artifacts, and result. Mark expectations reconstructed after the result as retrospective.

Write the tested scope in the claim itself. The Paper cell is the stable key for the paper that uses the claim. PUBLICATION.md owns that paper's manuscript and packet pointers, synchronization state, readiness, gates, venues, deadlines, and submission state. Human review is required before promoting a claim to supported or broadening its scope.

Every date in a publication record is a venue's own published deadline, traceable to its source. Work that is urgent but blocked carries an Urgency reason, a Gate that a reader can observe, and a ready since date from which staleness can be read, never an internal target date.

reference / graph · source

Edges and their owners

The notebook is a typed graph. Each edge has one write-moment owner, the file whose author writes it when the fact comes into existence, and the reverse direction is computed by search or index rather than stored. Experiments carry no back-link to plans or claims.

EdgeWritten inChecked by
plan → experimentPlan phases and completion reportValidator link resolution
experiment → estimand### E# heading and registration lineValidator registration values
experiment → prior evidence## Informed byValidator link resolution
claim → estimandCLAIMS.md Evidence cellValidator resolution, with found and gate warnings
claim → publicationCLAIMS.md Paper cellValidator
upstream → downstream experimentUpstream decision rule or follow-upsProse; the forward link is required
terminal plan → correctionRetraction noticeThe retracting session's search

The Informed by edge is the one that cannot be derived. A threshold chosen before looking and one chosen after produce identical code and output; the difference exists only at the write moment.

An Informed by section that names prior exposure to the data. From EXP-182, a registered reanalysis.
## Informed by

- [[EXP-028-visibility-derivation]], including its aggregate results, which were known before this record was created; that prior exposure is why this is a registered reanalysis and not a preregistration
- The four original Weft commands recovered for wj3711, wj3712, wj3726, and wj3733

## Pre-registered predictions (a priori)

None. This record registers an analysis of data already seen (see Registration status). The reproduction targets under Retrospective expectations are checks, not predictions.

The record says which facets of the earlier run it had seen, so a later reader knows the recovered intervals cannot count as a fresh confirmation.

reference / human decisions · source

Human review checkpoints

Agents prepare the record and proposed decision. They do not approve their own work as a substitute for human review. Record each decision in the experiment, plan, or claim update that it governs.

CheckpointWhen
Plan approvalbefore plan execution
Experiment design reviewbefore preregistration
Preregistration reviewbefore outcome inspection
Analysis and interpretation reviewbefore synthesis
Plan gate reviewafter each executed phase
Follow-up approvalbefore a gated follow-up
Claim promotion reviewbefore strengthening a claim

reference / runners · source

Connect a job system

A tracked RUNNER.md records how the project submits work, reads status and logs, retrieves artifacts, cancels work, checks whether evidence has been processed, and marks processing complete. This project-specific mapping is a runner adapter. The tools below occupy different layers and can be composed.

ToolPlacementQueueWorkflowArtifactsProcessed ledger?
DaguLocal, SSH, container, Kubernetes targetsWorkflow scheduleDAGs and retriesProject conventionYes
PueueOne machinePersistent command queueGroups and dependenciesProject conventionYes
SkyPilotClouds, Kubernetes, Slurm, machinesManaged jobsTask dependenciesSync plus configured storageYes
SlurmExisting clusterCluster schedulerDependencies and arraysProject conventionYes
WeftMachines and GPU rentalsResearch jobsSweeps, pipelines, DAGsStaging and retrievalNo, if native state is retained

Dagu and Pueue need an artifact convention or wrapper unless jobs already write to durable storage. SkyPilot and Slurm also need project-specific artifact locations. Setup records these mappings in the project adapter and keeps the core notebook rules portable.

reference / processed state · source

Fallback processed-job ledger

Use one JSON record per backend and job ID to avoid append races:

lab-notebook/jobs/processed/
├── slurm/123456.json
└── skypilot/managed-job-17.json

Required fields are schema_version, backend, job_id, experiment_id, terminal_status, processed_at, evidence, notebook_revision. Terminal status is succeeded, failed, or canceled. Backend names are normalized and unsafe job IDs use URL percent encoding in filenames. Evidence paths stay inside the notebook. Artifact URIs and hashes are recommended.

  1. Check whether the final record exists.
  2. Retrieve and verify outputs.
  3. Update evidence, indexes, and changelog.
  4. Validate and make the notebook update durable.
  5. Write a temporary JSON record in the target directory.
  6. Atomically rename it to the backend and job path, then commit it.

Coordinate writers around the whole protocol. A retry is a new job and receives a new record. Prefer SQLite when many writers, transactional queries, or very large job counts make individual files unsuitable.

reference / literature archive · source

Cited-paper archive

The download-research-references skill follows local LaTeX and Typst includes, reads common LaTeX citation commands and Typst @key citations, resolves authorized open sources, validates bounded PDF downloads, and updates BIBLIOGRAPHY.md. It can also fetch bounded clean arXiv source into references/source/<citation-key>/ and write references/SOURCES.md.

Return to the workflow guide Read the normative skill files