Domain model

Autoresearch adds no database tables. Every concept in the domain model is a page in the research/ directory, typed through metadata.research.type the same way any other page metadata typing works, and the research/ namespace is version-captured so you can see how a goal or hypothesis read at any point in the past. Core and adapter declare disjoint page types, so installing them together never creates an ownership conflict.

The research/ pages

Type	metadata.research.type	Owner	Carries
Goal	goal	Core	Objective and current-plan state plus metric, Elo, and reflexive loop settings
Plan	plan	Core	Confirmed goal ref, constraints, role bindings, budgets, mode, safety profile, and confirmation provenance
Session	session	Core	Exact goal/plan refs, mode, lifecycle, stop/pause reason, trigger, fork, and timestamps
Hypothesis	hypothesis	Core	Exact goal/session/parent/evidence refs, origin, strategy, eligibility, empirical state, and screening
Review	review	Core	Exact hypothesis target, review mode/verdict, rubric/evidence refs, and prompt/model/toolset hashes
Evidence	evidence	Core	Provider/source/locator identity, access and trust class, source hash, and claim directions
Observation	observation	Core	Exact hypothesis/evidence refs, claim, direction, strength, confidence, author, and adapter provenance
Concept	concept	Core	Reusable definition with exact source refs and aliases
Meta-review	meta-review	Core	Session epoch/checkpoint and exact input refs plus execution hashes
Overview	overview	Core	Terminal checkpoint, exact selected hypotheses, stop reason, and execution hashes
Proposal	proposal	Core	Pending heartbeat status or definition edit awaiting confirmation
Experiment	experiment	MLOps adapter	Free-form ML experiment notes/design, linked from hypotheses and runs
Profile	profile	MLOps adapter	The shared model/system card described below
Coding task	coding-task	MLOps adapter	A pending code change carrying research context
Run proposal	run-proposal	MLOps adapter	A pending ML run specification; confirmation promotes it to a backlog
Backlog	backlog	MLOps adapter	One goal’s ordered launch queue

Exact identity and immutable genealogy

An exact artifact reference is always {pageId, contentHash, pageVersionHash}. contentHash is lowercase SHA-256 over canonical JSON containing the type, title, normalized body structure, and only the scientific metadata fields named by that type’s schema. It excludes node IDs/ranks, lifecycle, ratings, timestamps, creator task/run IDs, and admittedContentHash. pageVersionHash is the existing immutable canonical-OKF hash. The first detects a change in scientific meaning; the second proves exactly which recorded page was read.

Evolution genealogy lives in a hypothesis’s parents array of exact refs. Parent refs must be unique and cannot point to the child itself. An evolved idea therefore gets a new page; the parent remains untouched and traversable at the exact content and page hashes used. Evidence refs and review targets use the same shape.

Reviews become stale when either the target semantic hash or target page-version hash no longer matches. research.artifact.inspect {page, review?} returns the current pair, immutable parents, whether admittedContentHash is still current, and reasons such as content-hash-changed or page-version-changed. The tool is read-only and resolves both pages through the run owner’s live ACL.

Hypothesis state has two axes

Autoresearch 1.0 does not overload one status with two different meanings:

• eligibility is draft, screening, reviewing, eligible, held, rejected, stale, or retired.
• empiricalStatus is untested, testing, supported, refuted, inconclusive, or superseded.

A supported result cannot bypass safety and initial-review admission. Editing scientific content makes exact reviews stale; it does not erase the empirical record. The heartbeat loop’s compact {status, goals, evidence} hypothesis shape remains separate from the Supervisor’s exact, versioned artifact contract.

The schemas keep claims, mechanisms, assumptions, predictions, citations, critiques, source fragments, and syntheses in ordinary body nodes. That is why disabling the plugin removes its tools and typed registry but the generic page view still presents a useful scientific record. The package’s plan, session, hypothesis, review, evidence, observation, meta-review, and overview templates demonstrate the intended body sections.

Adapter runs stay mlops-core’s page type

A completed ML run is never a second, research-flavored page type. It is the exact same mlops/run page MLOps already materializes from whichever tracker produced it, decorated with a metadata.research {goal, hypothesis, proposal} lineage stamp once the scheduler launches it (see lineage records below). The run page on the MLOps dashboard and the run page an observation links to are literally the same row, so there is nothing to keep in sync.

The per-goal backlog

This page type and its scheduler belong to the optional MLOps adapter. Confirming a heartbeat-drafted run proposal (a task-queue Confirm, see research loops) promotes it into that goal’s backlog page, auto-created in research/ as <goal> - backlog. The backlog is an ordinary outliner page: each queued run spec lives as one bullet carrying its structured spec in props, and bullet order is priority. Drag a bullet up to move it earlier in the drain order, exactly the outliner gesture you’d use to reorder anything else. The adapter’s scheduler workflow reads this page top to bottom every time it runs; see research loops for how it drains entries against a launcher’s live capacity and a goal’s budget.

Profile pages (the model card)

Profiles belong to the optional MLOps adapter. A goal references a shared research/profile page through metadata.research.profile. Ingest triage and the heartbeat can’t judge whether a paper’s architecture trick or training recipe applies to your project without knowing what you actually run, and a hand-maintained description goes stale the moment a hyperparameter changes. So the profile is run-config-derived: every ingested run normalizes its config (ignoring configured ephemeral keys like timestamps or random seeds) and updates the profile’s machine-derived subtree before the observer even looks at the run.

• Runs off a main or release git ref replace or fold into the profile’s baseline.
• Off-main configs cluster by a stable config signature, branch name is provenance, not identity, retain a bounded set of run/git-ref stamps, and expire once they go runless or end up tied to a refuted or parked hypothesis.
• A config that stabilizes and lands on main disappears as its own cluster once the matching recipe becomes the baseline.
• The profile’s human-authored root nodes (intent, constraints) are never touched by this machinery, only the derived subtree updates automatically.

A baseline signature change emits a research-profile-drift event through trusted triage into the profile’s inbox, so a meaningful shift in the current recipe surfaces to you instead of silently rewriting history. Goals that opt in automatically pin their profile in triage.context, and both the heartbeat’s gather step and literature triage read the same live profile body as context.

Lineage records

This execution lineage is written by the optional MLOps adapter. {goal, hypothesis, proposal} is the lineage triple the scheduler stamps onto metadata.research of every run page it launches: which goal the run serves, which hypothesis it’s meant to move evidence on, and which backlog proposal produced it. Combined with the coding lane’s dispatch hints (a launched task carries a hypothesis [[ref]]), the full chain goal → hypothesis → task/proposal → run → observation is traversable as ordinary page links, from a hypothesis to every run that tested it or from a run back to the goal it served, with no separate lineage database to query.

See research loops for the workflows that create, drain, and consume these pages, and MLOps overview for the tracker/launcher layer the run pages themselves come from.