Panel Creation Standard

#1. Claim and panel — two things, one object

A claim is an intellectual entity: a proposition, its evidence, its methods, its epistemic status, its date, its authors. A panel is a material artifact: the figure image, the analysis script, the stats CSV that materializes the claim. Every claim has a panel; the panel is how the claim enters the world.

The distinction matters because the same claim can be re-rendered, the panel style can change, the figure can be revised — the material artifact changes while the intellectual entity persists. It also matters for provenance: what gets registered in the knowledge graph, cited by downstream work, and reviewed is the claim. What gets produced by the three-stage pipeline (§3) is the panel.

The claim is the atomic unit of scientific knowledge production. Not the paper — that is a publication artifact, a bundle assembled for a journal. Not the dataset — that is raw material, not interpretation. Not the sentence — too fine-grained to carry a complete argument. The claim is where those collapse into one: one experimental condition, one analytical result, one interpretive proposition, one panel materializing it.

Papers are claim assemblies. A paper's contribution to knowledge is the sum of its claims. Writing a paper means: select the claims that tell a coherent story, then write the connective tissue between them. The paper exists for readers; the claims exist for knowledge.

This has practical consequences. Review is claim-level. "Figure 3B: the statistics are underpowered for a cluster-robust claim" is a reviewable statement. "The statistics are underpowered" is a complaint. Claim-level review is more precise and more actionable because the claim is the unit that can actually be fixed, re-analyzed, or replaced.

Knowledge extraction from historical papers is the backward pass — recovering claim structure from publications where it was never natively captured. Going forward, claims are created, not extracted. The ms_mat.md format (§4) captures this structure at creation time.

#2. The patent claim framing

A patent claim is a precisely bounded assertion of priority — scope, date, adversarial testing, public record. It does not merely describe; it asserts, with a specific date and against a specific background of prior art. Scientific claims work the same way, but the formalism has been informal.

Patent claims have a compositional structure: independent claims stand alone; dependent claims explicitly reference a prior claim ("the method of claim 1, wherein..."). Invalidity propagates from independent to dependent — if claim 1 falls, everything downstream falls with it. This is the upstream/downstream structure formalized: the upstream field in ms_mat.md IS the "of claim N" reference.

The patent framing makes explicit something scientific culture handles informally: the claim entity with its date establishes scientific priority. The claim is simultaneously the proposition and the act of asserting it with evidence in a specific context. Act and content are unified — you cannot separate "what was found" from "who found it, when, how, and against what prior claims."

This has an implication for the knowledge graph. When a claim cites upstream work, it is not merely acknowledging intellectual debt — it is building a chain of priority. A claim built on a flawed upstream claim inherits that fragility. The dependent relationship is load-bearing, not decorative.

A worked example of patent-style claim chaining across the serotonin literature:

Claim 1 (Mainen & Sejnowski 1995): Neocortical neurons produce reliable spike timing in response to repeated current injection — variability is not intrinsic to the neuron but reflects input noise. This claim stands alone; it has no upstream claims in this chain.

Claim 2 (Fonseca 2015): The method of claim 1, applied to DRN serotonin neurons: phasic optogenetic activation of DRN 5-HT neurons promotes waiting behavior in a fixed-ratio task. Depends on claim 1 for the electrophysiological methodology and the concept of reliable spiking as a precision signal.

Claim 3 (Cazettes 2021): The observation of claim 2, wherein DRN activation produces graded pupil dilation as a real-time readout of serotonin state. Claim 3 extends claim 2 by adding a peripheral behavioral measure — pupil — that indexes the same internal state.

Claim 4 (Hubert 2026): A unifying account of claims 2 and 3, wherein DRN serotonin signals state prediction error — the mismatch between expected and actual environmental state. Claim 4 is a synthesis: it takes the behavioral effect (claim 2) and the graded readout (claim 3) and provides a computational account of what the signal encodes.

In this chain: claim 4 is invalid if claims 2 and 3 are; claim 3 is invalid if claim 2 is; claim 1 is independent. The upstream field traces this dependency structure explicitly.

#3. Claim types

Five epistemic types with distinct weight in argument and review. Note: empirical and interpretive differ in evidence character, not structure. Synthesis and assessment have additional required belongings (§6) — they are structural variants, not just type labels.

empirical — Supported by data and formal analysis: a statistical model (LME, GLM, Bayesian), test statistics, and confidence or credible intervals. This is the highest-weight type: it makes a generalizing claim about a population or process, grounded in a formal inferential procedure. One empirical claim can be directly contradicted by another — that is the currency of the literature.

interpretive — Supported by argument or close reading without formal inference. Shows what was observed and argues for its meaning; does not claim statistical generalization. Evidence of pattern, not inference from pattern. Often necessary as ground for empirical claims (you need to see the data before you can model it), but cannot stand alone as a claim about mechanism. Also covers schematic arguments and theoretical proposals where the evidence is conceptual.

existence — "This phenomenon occurs." A representative or illustrative instance: a single trial, a single cell, a single recording, a schematic. Lowest inferential weight. Evidence of type "this exists" or "this is what it looks like," not "this is how things generally work." Existence claims are often the most memorable panels in a paper and the least defensible as evidence. Treat them accordingly.

synthesis — Integrates across multiple prior claims into a summary argument. Requires composed-from belongings listing the claims being integrated (§6). Often the last figure in a paper. A synthesis built on weak empirical claims is still weak regardless of how clean the summary looks. Review of a synthesis claim is always conditional on its constituents.

assessment — Directed at another claim: a replication, a critique, a methodological evaluation. Requires a directed-at belonging naming the target claim (§6). Assessment claims are how the literature corrects itself; they should be registered and traversable, not buried in footnotes.

Type is epistemic classification, not visual format. A bar graph can be empirical or interpretive. A scatter plot can be interpretive or existence. The type is determined by the inferential procedure applied to it, not its appearance.

#4. The three-stage creation pipeline

The pipeline is language-agnostic. The stages are intellectual contracts, not software specifications. R, Python, Julia, MATLAB — the interface between stages is structured output files, not function calls across a language boundary.

#Stage 1 — Analyze

One analysis unit per claim-group. Input: raw or processed data. Output: structured statistical results — model object, parameter estimates, confidence or credible intervals, descriptive statistics — written to CSV or equivalent. No figures are produced here. The analysis is fully reproducible from data plus script; anyone with the data and script can recover every number in the ms_mat.md Result section.

The reference implementation is Solène's analyze.R pattern: lme4 for mixed models, clubSandwich for cluster-robust standard errors, effects and emmeans for contrasts. This pattern covers the majority of neuroscience panel types. Python equivalents (statsmodels, pingouin), Julia equivalents (MixedModels.jl), and Bayesian workflows (brms, Stan) are equally valid — what matters is that the statistical outputs land in CSVs that Stage 2 can read.

The analyze script is the reproducibility contract. It must run end-to-end from data to output CSVs without manual steps.

#Stage 2 — Panel function

A pure function that takes analysis outputs (CSVs from Stage 1) and returns a figure object. Named makepanelX() in R; equivalent naming in other languages. The function:

• Does not save files
• Does not read raw data
• Reads only from the analysis CSVs
• Returns the figure object to the caller

This separation is load-bearing. Changing the visual style — colors, fonts, axis labels, margins — never touches the statistics. Re-running the statistics never requires touching the figure code. The two can be iterated independently, which matters because visual revision cycles and statistical revision cycles run on different timescales.

The panel function also saves an individual panel image (fig3B.png, or equivalent) alongside the figure object it returns. This is required for the browser (§8) and for the ms_mat.md figure field. The individual panel image is a first-class output, not a byproduct.

The reference implementation is Solène's figure functions using thememanuscript() from templates/thememanuscript.R. The three-stage pipeline this standard formalizes emerged from that codebase — the standard generalizes it and adds the YAML registration layer on top.

#Stage 3 — Assemble

Composes panel functions into figure composites. Manages layout (cowplot, patchwork, or equivalent). Saves:

• Composite PDF or PNG for publication (journal submission, arXiv)
• Individual panel PNGs for the browser (delegated to each panel function in Stage 2)

The final step of assembly is register_panels.py (§6). Assembly produces publication artifacts and updates the knowledge graph simultaneously. These are not separate operations.

The reference implementation is fig4/fig4recovery_v1/ in Solène's repo — the most complete worked example of the three-stage structure.

#5. The ms_mat.md format

One ms_mat.md per panel or per closely related panel group (e.g., panels sharing an analysis). It is simultaneously human-readable scholarly prose and machine-parseable metadata via YAML frontmatter.

---
panel: F3B
claim-type: empirical
claim: "Serotonin responses habituate across days of repeated exposure to the same stimuli"
concepts: [serotonin-habituation, novelty-response, associative-learning]
upstream: []
data: data/Datatable.parquet
analysis: fig3/habituation/analyze.R
figure: fig3/habituation/_fig3_habituation_v1/fig3B.png
stats: fig3/habituation/contrasts.csv
epistemic: empirical
status: unpublished
---

### Result
[Prose result statement with inline statistics, cross-checked against the stats CSV]

### Interpretation
[What this panel means — the claim in argumentative form]

### Methods
[Statistical model formula, sample description, key parameters]

### Upstream claims
[List any claims from this or other papers that this claim builds on, with brief rationale]

### Review
[Empty until reviewed. Filled by reviewer with: methods assessment, results assessment,
interpretation assessment, reproducibility assessment]

Field definitions:

• panel: Figure letter + panel letter. F3B = Figure 3, Panel B. If a group of panels shares an analysis, list all: F3B,F3C. This names the material artifact; the claim entity gets its own ID in the knowledge graph (§6).
• claim-type: One of empirical / interpretive / existence / synthesis / assessment. See §3. synthesis requires composed-from belongings; assessment requires directed-at belonging.
• claim: A single declarative sentence — the proposition this panel asserts. This is the intellectual entity that gets registered in the knowledge graph. The claim is what a future reader cites, refutes, or replicates. It should be falsifiable.
• concepts: List of concept entity IDs this claim engages. Links to the knowledge graph. Concepts are not keywords — they are named entities in the ontology (e.g., serotonin-habituation as a process, not "serotonin" as a molecule). Use existing concept IDs when possible; propose new ones only when the existing vocabulary doesn't fit.
• upstream: List of claim IDs in <paper-slug>/<panel> format that this claim builds on — the "of claim N" reference in patent framing. Creates the dependency chain. An empty list is common and acceptable for independent claims. See §6 for the ID format.
• data: Path to data source, relative to the manuscript root.
• analysis: Path to the analysis script. This is what runs to produce the stats CSV.
• figure: Path to the individual panel image (not the composite). This is what the claim browser displays.
• stats: Path to the statistics CSV produced by the analysis script. The audit tool (§8) reads this field.
• epistemic: Same as claim-type — redundant but explicit. Makes the inferential weight visible to parsers without type inference.
• status: published / preprint / unpublished. Governs access control in the claim browser.

The Result section is the load-bearing prose. Every number in it must appear in the stats CSV. The audit tool (§8) checks this automatically. Write the Result section after running the analysis, not before — it is a report, not a prediction.

#6. Claim identity scheme

Claim IDs follow the format: <paper-slug>/<panel-letter>

For published papers: <doi-slug>/<panel> e.g., cazettes-2021-cub/F3B

For unpublished manuscripts: <lab>/<project-slug>/<panel> e.g., mainenlab/hubert-2026/F3B

The doi-slug is constructed from first-author last name, year, and a short title token — the same convention used for citation keys. Consistent with how the literature is already navigated.

At publication, unpublished IDs acquire a canonical DOI-rooted ID. The lab-namespaced ID becomes a redirect alias in entities.db. This is a one-time migration at the moment of publication — not ongoing maintenance. Manuscripts that never publish keep their lab-namespaced IDs permanently.

This scheme means claim IDs are stable references — and stable priority records. A claim cited in a downstream ms_mat.md upstream field retains its ID regardless of whether the source paper has been published yet. The date on the claim entity is the priority date.

#7. Registration

scripts/register_panels.py runs as the final step of assembly. It registers claim entities — the panels are the material artifacts; the claims are what get added to the knowledge graph.

• Reads all ms_mat.md files in the project
• Parses YAML frontmatter
• Creates or updates claim entities in entities.db
• Creates about belongings for each concept in the concepts field
• Creates extends belongings for each claim in the upstream field
• For synthesis claims: creates composed-from belongings for each constituent claim
• For assessment claims: creates directed-at belonging naming the target claim
• Links the figure file path as a quality of the claim entity (the panel, as material artifact)
• Sets epistemic status and publication status

This is the bridge between the manuscript working directory and the shared knowledge graph. Running assembly produces publication artifacts and updates the knowledge graph simultaneously. The two operations are not separable — a claim that has been analyzed and rendered but not registered has not been added to the knowledge base.

The registration script is idempotent: running it twice produces the same result. Assembly scripts should call it unconditionally.

#8. Audit

scripts/auditpanels.py runs automated integrity checking across all msmat.md files in a project:

• Reads each ms_mat.md
• Extracts all numerical values from the Result section (including statistics in parentheses, p-values, confidence intervals)
• Cross-checks each value against the referenced stats CSV
• Reports per claim: pass (all values match within tolerance), warn (minor rounding differences — typically display rounding vs. stored precision), fail (value not found in CSV, or significantly mismatched)
• Produces an audit report per claim and a summary for the manuscript

This replaces the manual checklist pattern (AUDIT_GUIDE.md in the reference implementation) with a reproducible automated check. The manual checklist can still serve as a human supplement for things the automated tool cannot check — biological plausibility, interpretation accuracy, figure-caption consistency. But the numerical integrity guarantee is automated, not human.

A claim that passes audit has a verifiable chain from data to prose numbers. A claim that fails audit has a broken chain somewhere — either the analysis was re-run without updating the ms_mat.md, or the prose was written from memory rather than from the CSV.

#9. The claim browser

The claim browser reads from entities.db and presents the knowledge graph as a navigable surface. The underlying files stay in the manuscript repository — the browser is a view over the graph, not a separate data store.

A claim in the browser displays:

• The panel figure (from the figure path, individual panel PNG — not the composite)
• Claim proposition (from the claim field, prominent — this is the headline)
• Claim-type badge (empirical / interpretive / existence / synthesis / assessment)
• Concepts as linked tags — click to see all claims engaging that concept
• Result and Interpretation prose sections from ms_mat.md
• Upstream and downstream claim links, traversable (the patent-style dependency chain)
• Epistemic status and publication status
• Review section, empty or filled

Navigation modes:

• By concept: all claims tagged with a given concept, across manuscripts and labs
• By claim chain: independent → dependent traversal — follow an assertion through the literature as it is extended, refined, or contested. This is the primary navigation mode; it corresponds directly to the upstream/downstream dependency structure.
• By thread: upstream/downstream traversal from any claim — follow a finding through the literature
• By author/lab: all claims from a project or collaborator
• By status: published / preprint / unpublished — access-controlled; unpublished claims visible only to authorized users

The browser is a design specification for a component to be implemented separately. The Compositor (method/35) owns the claim registry and render pipeline; the Designer (method/30) owns the browser surface. This document specifies what data the browser should expose, not how to build it.

#10. Reference implementation

/Users/zach/projects/mainenlab/5HT-novelty/ is the reference implementation. Specifically:

• CREATE_GUIDE.md — the original creation workflow (predates this standard; this standard formalizes it)
• AUDIT_GUIDE.md — the manual audit checklist (predates the automated audit tool)
• templates/analyze_template.R — the Stage 1 reference
• templates/theme_manuscript.R — visual style for Stage 2
• fig4/fig4recovery_v1/ — the most complete worked example of the three-stage structure

What the reference implementation has that this standard formalizes:

• The three-stage pipeline (analyze / panel function / assemble) — present in practice, not written as a standard
• Versioning via symlinks (fig4recovery_v1/ as a timestamped snapshot)
• The individual panel image as a named output

What this standard adds beyond the reference implementation:

• YAML frontmatter (ms_mat.md) as machine-parseable metadata
• The claim field as a first-class knowledge entity
• Concept tagging and upstream linking for graph integration
• register_panels.py as a required assembly step
• The automated audit tool replacing manual cross-checking
• The panel identity scheme for stable cross-manuscript references

The reference implementation demonstrates that the pipeline works. This standard defines what working correctly means, so it can be applied to future manuscripts across labs without renegotiating the structure each time.

#11. Open questions

These questions are for Naga (ontologist role) — they require grounding in the relational situational ontology before the registration script can implement them correctly.

Does the patent claim framing — unified act and content — hold in the relational situational ontology? A claim is simultaneously the proposition and the act of asserting it with evidence in a specific context. In the ontology, act and content are typically distinct: a situation (the assertion event) and a quality (the propositional content). If the ontology preserves this distinction, the claim entity as framed here may need to be modeled as a situation with the proposition as a quality belonging, not as a single flat entity. The answer has consequences for whether priority (the date) attaches to the entity itself or to the situation in which it was asserted.

Are synthesis and assessment genuinely structural variants, or are they type labels on the same entity structure? The claim here is that synthesis requires composed-from belongings and assessment requires directed-at — making them structurally distinct from empirical, interpretive, and existence claims, not merely epistemically different. But if the ontology handles these relations uniformly (all claims can have upstream dependencies; the type of dependency is a quality of the belonging, not the entity), then synthesis and assessment may be reducible to type labels with mandatory upstream fields. Settling this determines whether the registration script needs separate entity creation logic for these types or can use a uniform path.

How does the upstream relation ground in the quality vocabulary? extends is the current candidate quality name. But upstream could also be replicates, contradicts, corrects, or applies — these have different epistemic weight. Should upstream be a single quality with a subtype, or should distinct quality types be registered for distinct epistemic relations? The answer has downstream consequences for how the claim chain browser presents the dependency graph and whether invalidity propagation (if claim 1 falls, claim 2 falls) can be computed from the graph structure.

Methods 99 — Panel Creation Standard — 2026 — Zachary F. Mainen / HAAK