When Research Becomes a Traceable Object

The science workbench is Feynman’s answer to a problem that appears after a successful search: how do plans, sessions, tools, files, checks, and claims remain intelligible when a research effort lasts longer than one conversation? Its purpose is not simply to display a nicer folder. It turns ordinary workspace artifacts and runtime events into a local control plane that can be grouped, versioned, and inspected. The useful judgment for a reader is whether a run needs that additional lineage surface or whether a lightweight command-line session is enough.

From a folder of outputs to a research run

A research workflow naturally produces multiple files. A plan may sit beside source notes, a draft, a final brief, a score audit, a graph, a notebook result, and a provenance record. In a plain directory, those files can be opened individually, but their relationship is often left to naming conventions and memory. The workbench begins by indexing ordinary research artifacts in the workspace and grouping them into runs. It also associates sessions, plans, execution records, provenance, and verification with those runs.

That grouping changes the basic question a reader can ask. Instead of “What is this file?” the reader can ask “Which research effort produced it, what other artifacts belong with it, and what state is that effort in?” A run can expose a primary artifact, a plan, a provenance record, and verification evidence as related objects. The files remain ordinary workspace files that can be inspected from a terminal, editor, or version-control system; the workbench adds a view of their relationships.

The workbench’s scope is intentionally local. The public design describes a browser-based application backed by Feynman-owned workspace and organizational state, with research artifacts continuing to live in familiar output, paper, and notes locations. This arrangement avoids requiring a separate hosted research service for the core control plane. It also means the workbench’s continuity is tied to the local workspace, its sessions, its configuration, and the external providers or compute resources that a run happens to use.

Projects provide a second layer of grouping. The workbench can expose a general workspace alongside project views for plans, papers, verification, and other research-oriented collections. Those views are not substitutes for scientific interpretation. They are ways to keep a question’s context, run slugs, artifact paths, and session counts together so that the researcher can return to the same decision later.

Imagine that a PaperRank run produces a readable brief and several supporting artifacts. The CLI can already leave those files on disk. The workbench can treat them as a run, place the run in a project context, show which artifacts have provenance or verification records, and make the supporting material discoverable from the primary result. That does not strengthen the score. It reduces the chance that the score will be read without the evidence that qualifies it.