RIGOR Process, Analysis, and Scientist Extensions

Status: Maintained implementation guide
Updated: 2026-08-28

RIGOR uses role-owned extension paths rather than one unrestricted plugin interface. Scientific services extend ASCEND through a Scientist Skill and an explicit remote MCP Tool surface. Experiment-planning knowledge extends Composer through a process Skill. Deterministic execution extends through semantic instrument Capabilities and versioned Workflow/Procedure modules. Post-run analysis extends through PRISM Analysis Skills. The paths meet only at typed artifacts, immutable lineage, and semantic identifiers.

Goal
  -> Composer selects a Procedure and semantic Capabilities
  -> PACE executes an immutable RunSpec
  -> LabFlow schedules Procedure steps
  -> LabBridge binds each Capability to a controller or simulation
  -> Operations and artifacts enter a checksummed delivery
  -> PRISM selects versioned Analysis Skills
  -> typed metrics, quality, uncertainty, and decision checkpoints

Scientific question
  -> ASCEND selects a managed Scientist Skill
  -> exact allow-listed remote MCP Tools
  -> evidence-aware answer or explicitly unverified process proposal
  -> Composer process Skill compiles the proposal against the local laboratory

Owner	Owns	Does not own
Composer	Process knowledge, scientific adaptation, semantic Procedure generation	Device truth, execution, result analysis
LabBridge	Capability/device/material/resource facts and command enforcement	Scientific recipe or parameter selection
LabFlow	Deterministic Procedure validation and scheduling	Scientific reasoning or inventory substitution
PACE	Immutable package, lifecycle, evidence and stale-plan gate	Procedure authoring
PRISM	Evidence-driven Analysis Skills and typed findings	Experiment planning or control
ASCEND	Long-lived goal, iterations, decisions and recomposition	Bypassing module-owned validators

Process support

A Capability is the equipment-independent unit

LabBridge publishes each independently callable instrument function as a CapabilitySpec v2. A Capability declares its semantic identifier, typed input and result schemas, access, side effect, risk, timeout, idempotency, cancellation, preconditions, observable state, expected evidence, concurrency resources, and evidence authority. Direct Agent calls and LabFlow steps both use the same call_capability service, so adding a new call path does not bypass Operation, policy, Rehearsal, audit, or verification.

RIGOR currently supplies two implementation forms:

• A controller-backed device registers device and Capability metadata at runtime. The controller keeps vendor SDK, serial, MQTT, robot, or algorithm details below the semantic contract and reports terminal results.
• A SimFleet DeviceModel package contains device.yaml, model.py, and optional visual assets. The loader validates package identity, source hash, schemas, assets, and execution handlers before the model enters the catalog.

This split supports a furnace, balance, liquid handler, electrochemical workstation, XPS instrument, robot, human-assisted station, or algorithmic service without changing the upstream execution contract. A physical binding still needs device-specific safety and qualification evidence.

Composer adapts process knowledge to available resources

A Composer Process Skill is the scientific planning basis, not an index into a mandatory Workflow pool. It contains applicability, references, cautions, allowed and preferred conditions, rough route, material roles and accepted substitutions, instrument categories, required observations, risks, and stop conditions. Composer reads the complete selected Skill together with the goal and a hash-addressed live LabBridge resource snapshot.

The Planner returns a device-independent rigor.procedure-spec/v1. It names semantic Capabilities, concrete inputs, material roles, dependencies, safe-stop actions, results, and analysis intent. Deterministic Composer code then selects only accepted in-stock materials, records accepted substitutions, computes feasible intersections, validates every concrete input, and compiles the Procedure into LabFlow syntax inside the current composition. Generated Procedures are not installed into the global Workflow pool.

An allowed process range is not a requirement that one device cover the whole range. If a method allows 30--600 °C and the available furnace supports 35--550 °C, the feasible interval is 35--550 °C. A chosen value of 500 °C is valid; a hard requirement of 600 °C is not. In general:

actual choices = goal hard constraints
               ∩ process allowed envelope
               ∩ device input schema
               ∩ material compatibility
               ∩ governance policy

preferred conditions are soft objectives, not hidden hard constraints. If 500 °C is allowed but falls outside a preferred 520--540 °C band, composition may proceed and must freeze that deviation for review.

Versioned LabFlow Workflows remain optional, validated reusable fragments. A precise match may be reused; otherwise Composer generates a Procedure instead of distorting the goal to fit a template. LabFlow owns deterministic schema, scheduling, locks, retries, approvals, cancellation, and safe-stop execution; it never makes the scientific adaptation decision.

PACE freezes the Skill hashes, Procedure hash, device/material bindings, deviations, and LabBridge snapshot hash. If inventory or capabilities change before execution, PACE emits stale_planning_snapshot and ASCEND asks Composer to recompose from the new snapshot. No execution module silently swaps a material or parameter.

LabFlow also exposes a StepAdapter registry for audited non-Capability work. Built-in adapters cover MCP, allow-listed HTTP, and bounded local test helpers. Device operations should normally extend LabBridge instead, because the Capability boundary supplies the shared Operation and evidence guarantees.

Adding a process

1. Define or reuse semantic Capabilities. Specify input and result JSON Schema, evidence, verification, idempotency, cancellation, and risk.
2. Implement each new device binding as a controller or SimFleet DeviceModel.
3. Add a Composer Process Skill with domain knowledge, material acceptance, allowed/preferred conditions, observations, uncertainty, and safety rules.
4. Add a Workflow fragment only when a stable sequence is genuinely reusable; it is not a prerequisite for process support.
5. Verify live semantic binding and inventory adaptation.
6. Test substitution, range intersection, concrete-value rejection, Procedure compilation, cancellation, failure, snapshot expiry, and Rehearsal lineage.
7. Qualify every physical controller separately before treating its output as physical evidence.

The maintained ZIF-derived Fe/NC example demonstrates this path across weighing, liquid transfer, sonication, stirring, centrifugation, vacuum drying, furnace operation, plasma treatment, human setup, and electrochemical LSV.

Data-analysis support

A delivery selects immutable Analysis Skills

PACE sends PRISM a checksummed result archive. PRISM verifies the archive and manifest, inventories files, counts evidence, and normalizes public artifact references before analysis. It then scans the configured Skill library.

Each Skill is a directory containing:

skill-id/
  skill.yaml       # id, version, selectors, tools, outputs, presentation
  SKILL.md         # scientific method and interpretation limits
  scripts/         # optional deterministic analyzers
  requirements.txt # optional pinned runtime dependencies

skill.yaml may match device IDs, device types, Capability IDs, artifact roles, or media types. Values within one selector are alternatives; different active selector groups must all match. An always: true core Skill supplies the common data-quality and result contract.

PRISM calculates a content hash for every selected Skill and copies the exact version into the run workspace. The analysis container receives immutable input and Skill mounts plus a separate output directory. The Analyst can use bounded execution and scientific tools, but cannot control an experiment.

Analysis output has a shared contract

Every analysis produces report.md and analysis.json. The typed result records:

• data-quality status and issues;
• semantic metrics with units, evidence references, and uncertainty or an explicit reason that uncertainty is unavailable;
• per-device and cross-device findings, anomalies, limitations, and generated artifacts;
• reviewable question, hypothesis, finding, decision, limitation, and conclusion checkpoints;
• the Skill IDs, versions, hashes, and executed Skill-tool references.

PRISM validates artifact references and the result contract before committing the result and archive. Presentation metadata in the selected Skill defines localized series columns. Results are grouped by campaign, process_id, and presentation profile so comparable iterations appear together.

Analysis Skills available now

Skill	Match basis	Main output
Core scientific summary	Every delivery	Quality, report, typed result, decision checkpoints
Tabular measurement	CSV, Parquet, or XLSX	Normalized tables, summaries, and plots
ORR RDE analysis	run_lsv Capability	Polarization curve and ORR metrics
XPS composition control	XPS fixture Capability and tabular/JSON evidence	Evidence-bound atomic composition
XPS high-resolution peak fitting	XPS acquisition/analysis Capabilities	Fitted peaks, residual quality, and plot

Adding an analysis method

1. Choose stable Capability, artifact-role, media-type, or device selectors.
2. Create a versioned Skill with explicit inputs, method, output files, scientific limits, and tool allowlist.
3. Prefer a deterministic script for calculations. Preserve source checksums, units, sample identity, exclusions, and parameter choices in its output.
4. Emit semantic metric IDs, evidence references, and uncertainty through prism-analysis-result/v1.
5. Add a presentation profile when results should form a cross-iteration table.
6. Test selection, hashing, sandbox mounting, analyzer behavior, malformed evidence, missing uncertainty, artifact references, and result commitment.

Scientist capability support

A Scientist capability is for a scientific service the ASCEND Agent should use directly during conversation, such as a database-screening or design service. It is neither a Composer process nor a PRISM post-run analyzer. One installed directory contains:

capability-id/
  scientist-capability.yaml # id, version, HTTPS MCP endpoint, exact Tools
  SKILL.md                   # routing, lineage, and response rules
  references/                # optional text-only detailed instructions

Creator validates the Skill identity and all text files, rejects executable or linked content, permits only remote HTTPS SSE or Streamable HTTP MCP, and requires a non-wildcard Tool list. It completes an MCP handshake and confirms every declared Tool without invoking one. The Skill and connection manifest then enter ASCEND under one content hash and one atomic directory rename.

The manifest declares readiness. advisory supports scientific answers and unverified designs only. planning_ready additionally defines a complete typed handoff suitable for Composer. For process design, ASCEND commits an immutable rigor.scientific-process-proposal/v1 that preserves exact dataset-or-design lineage and remains proposed_unverified. Composer requires its companion Skill, verifies the proposal content hash, and resolves local Workflow, Capability, equipment, SOP, observation, and safety gaps. The proposal itself never authorizes execution.

The running Agent merges the installed MCP declaration with operator-managed configuration and hot-loads it. Subsequent Scientist turns admit Skills only from ASCEND's owner-managed capability root, mounted read-only and separately from the Agent's writable workspace, and expose only the exact wrapped MCP Tool names. A failed first activation removes the new directory only if its hash is unchanged and restores the previous runtime configuration.

Current extension limits

The existing design has clear boundaries, but it is not yet a complete plugin platform:

• Role extensions still use separate owner manifests. Creator now produces a source-bound owner/readiness Extension Plan for one installation session, but there is not yet a signed published bundle registry with update and rollback lifecycle.
• Analysis matching tests presence only. It has no selector priority, exclusions, version ranges, or conflict resolution beyond deterministic Skill ordering.
• PRISM commits one highest-priority presentation profile even when several domain Skills match a delivery.
• Metric semantic IDs and units lack one centrally validated ontology.
• Skill dependencies rely on the shared sandbox image or a Skill-specific command; the runtime does not resolve a standard dependency lock manifest.
• Workflow fragments support semantic resource binding, but several maintained examples still name concrete device IDs in their materialized steps.
• Creator Mode can adapt public GitHub repositories and uploaded archives, classify MCP Tools by consumer/side effect/authority, and install Composer Skills and Workflows separately through Composer, PRISM Skills through PRISM, or Scientist capabilities through ASCEND. LabBridge integration installation, inventory, disable, version update, rollback UI, and private-repository authorization remain later work.

A future registry may add a shared manifest for published cross-owner bundles, but Creator Mode deliberately does not require source authors to provide one. The Creator Agent generates each target's existing contract from the supplied source, while each owning module keeps its validator and library authority.

Compatibility identifiers

The public product name is RIGOR. Some machine-facing schema values, Python package names, headers, configuration paths, and stored-object namespaces still use the earlier identifier. RIGOR keeps them stable during the rebrand because changing them without versioned readers and data migration would break existing archives, databases, clients, and deployments. New user-facing text should use RIGOR; compatibility identifiers should change only through an explicit versioned migration.

Implementation references

The repository sources are contracts/capability-spec-v2.schema.json, labbridge/docs/controller-protocol.md, labbridge/docs/simfleet.md, labflow/docs/runtime-contract.md, composer/backend/src/composer/schema.py, prism/backend/src/prism/skill_library.py, prism/backend/src/prism/contracts.py, and ascend/backend/src/ascend/scientist_capabilities.py.