RIGOR Agent-First System Design PRD

Status: Accepted; the software/simulated implementation exists and is under release requalification; production qualification remains open; physical device integration and qualification are outside the current product scope Updated: 2026-08-11 Primary owner: RIGOR platform / ASCEND Scope: Software platform, simulated laboratory, algorithmic analysis, governed human-assisted work, product flow, authority, evidence, deployment, and qualification

This is the normative product design for RIGOR. Read it to understand what the platform must do and which module owns each decision. Use Current Progress for implementation and open work; schemas, typed contracts, code, and tests remain authoritative for exact interfaces.

The former 1,500-line design and delivery snapshot is retained in the repository at docs/archive/prds/agent-first-system-design-prd-2026-08-03-detailed.md. It is historical reference, not a second active PRD or current status source.

1. Product Decision

RIGOR is an Agent-first laboratory operating system. A researcher defines or changes a scientific goal, constraints, success criteria, and autonomy policy. The platform advances routine planning, composition, execution, verification, analysis, and iteration without asking a person to operate its internal lifecycle.

People do not advance the platform lifecycle. They define or change goals and constraints, provide genuinely required human input or evidence, and make important decisions.

A normal user should need only to:

• express a goal and constraints;
• inspect progress, evidence, and decisions;
• respond to Needs you when policy, required human input, ambiguity, or failed recovery genuinely requires a person;
• Pause, Stop, or Take over through governed actions.

Compose, Sync, Prepare, Start, Refresh, polling, delivery, analysis dispatch, and continuation are internal actions. They advance automatically when policy and evidence permit.

Every side-effecting experimental LabBridge capability call must first pass an automatic, isolated, traceable Rehearsal against the exact immutable intent or RunSpec. Rehearsal is a first-class execution gate coordinated by ASCEND and enforced by LabBridge; it is neither an optional Composer feature nor a seventh domain module.

1.1 Current scope decision

The current product scope is deliberately limited to:

• the Agent-first software platform and its deterministic execution kernel;
• simulated laboratory devices and environments;
• algorithmic analysis and committed software evidence;
• governed Human Tasks for required manual input, review, or supplied evidence;
• production operation of those software and simulated capabilities.

Real instruments, robots, mobile platforms, firmware delivery, physical-effect verification, controller calibration, and physical-device qualification are not current deliverables, release gates, or scheduled roadmap work. They must not consume current delivery capacity or delay the software/simulated release.

Physical integration may resume only through a later accepted PRD revision that names a concrete device and owner, defines its evidence and safety profile, and adds separate acceptance criteria. Existing semantic Capability, Operation, verification, and evidence-authority boundaries are retained so that future work does not require redesigning the upstream platform.

2. Outcomes and Non-Goals

RIGOR must:

1. turn bounded research intent into an inspectable, versioned plan;
2. execute semantic laboratory capabilities through deterministic policy and safety controls;
3. preserve immutable Operations, evidence, analysis, and scientific lineage;
4. continue, ask, block, pause, or stop from explicit policy and committed evidence;
5. let simulated, human-assisted, and algorithmic capabilities share the same upstream semantics without confusing their evidence authority;
6. remain modular enough that each domain can evolve, fail, recover, and be tested independently;
7. make forward progress observable and bounded so a stalled stage recovers, asks, or reports a problem instead of remaining indefinitely Working.

RIGOR does not:

• deliver or qualify real instruments, robots, mobile platforms, firmware, or physical effects in the current product scope;
• let an LLM directly control GPIO, MQTT topics, serial commands, robot poses, trajectories, joints, or vendor SDKs;
• treat chat, animation, model confidence, transport dispatch, or simulation as verified physical evidence;
• require every atomic action to become a saved Workflow or PACE package;
• merge all domain modules into one process, database, or state machine;
• expose internal IDs and engineering lifecycle steps as the normal product;
• store or require hidden model chain-of-thought.

3. Design Principles

3.1 Goal first, lifecycle second

The primary object is a durable research Goal with constraints, policy, Iterations, evidence, and decisions. Internal jobs and states exist to deliver that goal; they do not define the user's journey.

3.2 Models propose; deterministic services authorize and execute

LLMs interpret goals, propose hypotheses, select bounded intents, explain evidence, and recommend next steps. Deterministic code owns schemas, policy, authorization, validation, locks, idempotency, timeout, cancellation, safe-stop, verification, persistence, and evidence commitment.

3.3 Human attention is one exception channel

Human intervention uses ALLOW | ASK | DENY policy outcomes and typed Attention/Human Tasks. Producers declare the reason, evidence, input schema, allowed decisions, consequences, and recovery action. Modules do not invent parallel approval inboxes.

Needs you contains only work a person can still complete: an open or currently processing decision, or a non-terminal Human Task. A failed delivery after the person has already decided is a recoverable Problem, not another request to decide; retry reuses the exact persisted decision and input. ASCEND reconciles mirrored Attention against producer-owned terminal or missing resources and closes orphaned cards without rewriting their audit history. Qualification and module tests must use isolated Attention dispatch and must not invent production Coordination lineage.

3.4 Capabilities, not protocols

Agents and schedulers select semantic Capabilities such as weighing, running a heat program, capturing an image, or moving a carrier. LabBridge and device controllers own protocol and SDK details.

3.5 Immutable history, revisable plans

Plans may be revised by appending a new PlanRevision. An executed Operation, evidence record, decision, Analysis Result, or Iteration is never rewritten for a later plan.

3.6 Evidence authority is explicit

Every output states whether it is predicted, simulated, physical, human-supplied, algorithmic, or unverified. Promotion, visualization, or a successful model response cannot strengthen that authority.

3.7 Provenance is a product projection, not a generated claim

For every committed round result, ASCEND automatically projects one typed, read-only Provenance view from the records already owned by ASCEND, Composer, PACE, LabFlow, LabBridge, and PRISM. The fixed presentation sequence is Goal, Plan, Rehearsal, Execution, Operations, Evidence, Analysis, and Conclusion. Stages may be complete, partial, unavailable, or not applicable; a missing record remains visible as a gap and is never guessed from a neighboring round.

The projection does not copy or replace module-owned records, calculate a single trust score, or strengthen evidence authority. It reports completeness, authority, verification/data quality, and gaps independently. An optional bounded Provenance Explainer Agent may organize the fixed facts into a concise summary and call out existing node references. Its output cannot add nodes or edges, change status or authority, suppress warnings, or become evidence. If the Agent is unavailable, the factual source chain remains usable.

3.8 Analysis decisions are reviewable records, not hidden thought

PRISM must expose how an analysis moved from supplied evidence to findings and conclusions without exposing or reconstructing private chain-of-thought. The reviewable record contains objective runtime events plus concise structured decision checkpoints: the scientific question, evidence used, finding or choice, rejected alternatives when material, uncertainty, and references to validation output and artifacts.

Recording completeness cannot depend on an Analyst remembering to call a logging Tool. The runtime captures inputs, Tool calls/results, errors, files, and validators automatically; the Analyst profile must return typed decision updates as part of its required output contract. A deterministic builder checks and links those records. An optional Agent may explain the resulting fixed graph, but cannot infer a missing decision, add support, or hide a gap.

4. Module Authority

Module	Owns	Does not own
ASCEND	Goals, Research Definition, Governance Policy, Coordination, immutable Iterations, mandatory Rehearsal orchestration, Attention, decisions, user projection	Workflow execution, device protocols, raw analysis
Composer	Bounded planning, Skill/Procedure selection, capability matching, validation, immutable RunSpec/package construction	Experiment execution, self-approval, scientific result commitment
PACE	Immutable RunSpec execution, Loop Run integrity, result completeness, archives, evidence delivery	Procedure authoring, device control, next hypothesis
LabFlow	Procedure schema, deterministic scheduling, waits, locks, cancellation, safe-stop, run export	Scientific coordination, device SDKs, evidence interpretation
LabBridge	Semantic capabilities, devices, Operations, Rehearsal environments and execution gate, Human Tasks, artifacts, spatial state, controller boundary, audit	Scientific planning, workflow policy, result interpretation
PRISM	Isolated evidence analysis, Analysis Skills, committed structured results, reports, archives, callbacks	Starting experiments, controlling devices, deciding the next round

Shared packages own reusable mechanics—Agent runtime, jobs, RunSpec loading, migrations, sandbox inspection, object storage, UI contracts, localization, chat, and maps—without absorbing domain authority.

5. Primary Product Flow

Researcher goal + constraints + autonomy policy
  -> ASCEND creates or revises the durable plan
  -> Composer constructs a validated immutable RunSpec when needed
  -> ASCEND and LabBridge rehearse every experimental capability intent
  -> PACE and LabFlow execute deterministic multi-step work
  -> LabBridge creates governed semantic Operations
  -> simulated devices, algorithms, or governed Human Tasks perform the work
  -> PACE commits complete evidence and delivers it
  -> PRISM analyzes committed evidence in isolation
  -> ASCEND continues, asks, blocks, pauses, or stops

The backend projects one of five user-facing phases:

Working
Needs you
Paused
Completed
Problem

Each projection includes durable experiment start/end timestamps, a human blocking reason, and backend-provided available_actions. Frontends render this contract and do not maintain a full state-transition map.

6. Execution Paths

6.1 Direct semantic action

A low-risk atomic intent may travel directly through ASCEND Policy, Rehearsal, Execution, and LabBridge. It still produces policy, Rehearsal lineage, Operation, audit, timeout, verification, evidence, and trace records. It does not require an artificial Workflow or PACE package merely to satisfy architecture ceremony, but an experimental write cannot skip Rehearsal.

A versioned, curated rehearsal_only preset may also create a bounded PlanRevision in ASCEND and run it directly in an isolated LabBridge Rehearsal Lab. This path does not call Composer, PACE, LabFlow, or PRISM, cannot promote itself, and ends with predicted findings and replay only. It exists for plan inspection, training, and truthful demonstration—not formal execution or scientific evidence.

6.2 Reproducible multi-step work

Reusable, multi-step, risky, or scientifically reproducible work uses a validated Procedure/Workflow and immutable RunSpec/package. Composer constructs the package, PACE owns loop integrity and evidence completeness, LabFlow owns deterministic scheduling, and LabBridge owns each device Operation.

6.3 Human-assisted work

Required manual input, review, or supplied evidence is a typed Human Task with instructions, required inputs, evidence, claim/submit/reject behavior, expiration, and provenance. A Human Task is part of execution, not an informal chat request. This does not place physical-device integration in the current scope.

6.3.1 Human-aware shared-workspace coordination

The normative privacy, fail-closed, evidence-authority, safety, and qualification contract is defined in Human-Aware Shared-Workspace Coordination.

6.4 Rehearsal and execution

Rehearsal environments may fork, reset, accelerate, compare, and inject faults. Before prepare, start, retry, promoted Plan execution, or a direct experimental action can cause a LabBridge write, the exact capability intents must have a completed selected branch tied to an immutable PlanRevision and ExecutionSnapshot. ASCEND revalidates snapshot freshness, PACE rejects missing lineage, LabFlow transports it in its signed workflow context, and LabBridge rejects missing, stale, mismatched, or uncovered capability input.

The gate is automatic and remains part of the user-facing Working phase; it does not add Compose/Rehearse/Promote/Start buttons. Read-only discovery and diagnostics do not require it. Cancellation, stop, emergency response, and safe-stop must never be delayed by it. Explicit engineering or maintenance work outside an experiment remains governed by its existing policy and audit path.

Formal execution then uses current state, new policy evaluation, locks, timeout, cancellation, safe-stop, verification, and evidence rules. Promotion copies a plan and lineage only; it never copies world state or predicted findings into evidence. Detailed requirements live in Virtual Lab Requirements.

7. Plans, Policy, and Recovery

A PlanRevision is a bounded ordered sequence of semantic intents, linked to its context and policy. Execution stops at ASK, DENY, failure, cancellation, or an invalid precondition. Caller intent IDs are revision-scoped so replays cannot collide with history.

Recovery uses the smallest safe action:

• retry a stage only when a fresh attempt is safe and idempotent;
• recompose when the package or Procedure is the problem;
• invoke a semantic direct action only after bounded capability discovery;
• create a new PlanRevision when the intended sequence changes;
• ask a person when ambiguity, policy, required human input, or exhausted recovery requires one.

Every internal transition or worker stage has durable progress time, a bounded deadline or lease, and a recovery budget. EXECUTING is deliberately different: elapsed experiment duration is not evidence of a stall and has no generic stage deadline. ASCEND repeatedly reads the owning PACE/Operation projection; every recognized active status keeps the experiment Working, including experiments that run for hours or days. A failed or invalid status read uses a bounded communication grace period and retries only the read. It must never repeat the device action. Continued status unavailability becomes typed Attention with retry-query or governed stop actions. Explicit scientific limits, operation timeouts, cancellation, and declared safe-stop behavior remain in force.

A worker restart or expired internal-stage lease first reconciles the owning module's recorded state. Safe idempotent recovery may continue automatically; exhausted or unsafe recovery creates typed Attention when a person can resolve it, otherwise the user projection becomes Problem. A coordination cannot remain Working solely because an internal record is non-terminal, and a policy-disabled automatic transition must expose what will advance it.

Stopping Experiments freezes the target scope before cancellation. Device reset then proceeds independently through automatic Operations or Human Tasks, verifies safe state where possible, and never resumes the stopped scientific execution.

8. Agent Runtime, Tools, and Context

Scientist, Planner, and Analyst are versioned profiles on one shared Agent Runtime. Each owning module controls its profile, prompt, Skills, tool allowlist, context projection, output schema, budgets, and sandbox adapter.

Every Tool has typed input and result contracts, declared side effects, idempotency behavior, policy requirements, and trace correlation. A Tool invokes an application command; it does not create a second business state machine, modify another domain's database, or bypass deterministic validation.

Every AgentRun records or references:

• profile, prompt, Skill, and tool-schema versions/hashes;
• context-policy version and immutable context snapshot;
• model and bounded generation settings;
• parent/child Specialist task lineage;
• policy outcomes, tool calls, structured results, errors, and evidence refs;
• time, turn, retry, tool-error, and token budgets.

Store concise structured reasons and evidence references, not hidden chain-of-thought. External Web content is untrusted background information until captured with provenance and admitted by the owning evidence boundary.

8.1 Context capacity, task budget, and continuation

The runtime must present and enforce two different ledgers:

• Current context is the bounded model input carried into the next model call. The runtime estimates it before every call, limits every injected item and Tool result, persists oversized results by reference, and compacts or trims only the model-facing copy before the provider context window is exceeded. The durable conversation and evidence records remain intact.
• Task budget is the cumulative model work spent in one execution segment, including repeated prompt input and generated output. It bounds cost and runaway work; it is not evidence that the model context window is full.

Reaching either boundary is a normal, recoverable runtime condition rather than an opaque failure. At a task-budget boundary the runtime must stop before any new Tool side effect, persist the conversation, completed Tool results, and a typed checkpoint, then start a fresh accounting segment when continuation is allowed. A checkpoint contains only observable progress: stop reason, context and task counters, completed iteration and Tool counts, and stable record references. It must not store or expose hidden chain-of-thought.

An active sustained Goal continues automatically in the same user-visible task, subject to a bounded number of continuation segments. An ordinary conversation pauses visibly so the scientist remains in control. ASCEND keeps a compact context-remaining ring beside the conversation composer at all times; it is quiet while healthy, changes color near the boundary, and expands on demand to show exact current-context and task-segment counters. At a boundary ASCEND also shows a concise card that says the work is saved and provides one manual Continue task action. Continuing creates a durable new turn in the same session, reuses the saved context and Tool results, resets only the segment cost ledger, and instructs the Agent not to repeat completed work. Cancel and device-safety semantics are unchanged.

The OpenAI-compatible Agent boundary includes an additive sdlx_runtime extension with stop_reason and a versioned budget checkpoint. Products must consume this structure instead of parsing human-readable error text. Legacy responses without the extension remain valid and are treated as completed.

8.2 PRISM reviewable analysis record

PRISM owns an immutable, read-only decision graph for each Analysis Run. It is more specific than the cross-module Provenance chain: Provenance answers “where did this conclusion come from?”, while the decision graph answers “how did this analysis reach that conclusion?”. The Provenance Analysis stage links to the graph for the same immutable Analysis Run.

The graph is compiled from two bounded sources:

• the runtime automatically records input/evidence, Tool call, Tool result, error, produced artifact, and deterministic validation nodes;
• the Analyst emits typed question, hypothesis, finding, decision, limitation, and conclusion checkpoints, each with concise reason, uncertainty, and existing record references.

Edges use a fixed vocabulary such as uses, produces, supports, contradicts, rejects, triggers, and validates. Stable identifiers make runtime retries and graph rebuilding idempotent. Executed versioned Skill tools use skill:<skill-id>/<relative-path> identities rather than model-invented runtime IDs. The graph builder rejects dangling references, groups repeated links by one root record without deleting raw gaps, and checks that material conclusions lead to findings, findings lead to data or Tool results, rejected material alternatives include a concise reason, and warnings remain visible.

Graph validation has its own complete, partial, or unavailable state; it does not replace evidence authority or scientific data quality. Missing required links trigger one bounded structured-repair attempt. If repair fails, PRISM retains all objective records and the scientific result, marks the review record partial or the result needs_review according to severity, and exposes the exact gaps. It never generates substitute reasons. Legacy runs with only Tool traces are labeled legacy trace only; a later Agent summary cannot turn them into a complete decision record.

The optional Decision Explainer receives only validated nodes and edges. It may select and phrase a concise scientist-facing path, but its references must resolve to that graph and it cannot change the graph, result, evidence authority, validation state, uncertainty, or warnings. Explainer failure leaves the deterministic graph usable.

9. User Experience

ASCEND is the normal researcher surface, centered on Goal/Conversation, current activity, Needs you, evidence, devices, and decisions. Raw traces and module consoles remain progressively disclosed.

The user interface must:

• explain what the system is doing in domain language;
• show why it is blocked and what each available action will do;
• distinguish predicted, simulated, physical, human, algorithmic, and unverified output;
• remain usable on desktop and mobile;
• obtain action availability and lifecycle meaning from backend contracts;
• keep localization separate from identifiers, evidence, and audit records.
• keep Docs and disclosed operations/settings reachable through configured browser URLs.
• keep spatial contexts explicit: ASCEND Lab observes the current laboratory, Experiment pages replay a frozen scene, and LabBridge configures a future layout; all three may share a renderer but never mix live entities, revision geometry, replay records, authority, or mutations.
• make ASCEND Lab follow Observe → Inspect → Act: show environment/reality and source age, current work and exceptions before inventory counts, keep one map/list selection, expose governed actions from backend contracts, and move layout maintenance behind a contextual settings entry that opens the same complete Console workspace as the global Console control. In LabBridge, the 2D canvas is the sole management surface for placed equipment and spatial objects; Add to layout lists unplaced fixed and movable equipment plus space objects, while Selected equipment explains the current map selection. Selecting equipment opens an anchored, non-obscuring action bubble for the applicable move, remove, and robot-work-point actions; movable equipment carries a visible mobility mark but is not segregated into a second workflow. The map authors only explicit Access Points; service targets, ports and localization anchors belong to DeviceModel/controller definitions, while any derived navigation ID or route stays private. Typed preflight failures first state a human-readable cause class and recovery direction, and only a continuously qualified draft with no hard blocker can become an immutable current revision through Review & use.

Composer, PACE, LabFlow, LabBridge, and PRISM Web applications are Engineering Consoles, not parallel normal-user surfaces. ASCEND Creator Mode adapts GitHub repositories or archives in a session sandbox. Before installation it validates a source-bound owner/readiness plan; MCP transport never decides ownership. Composer separately owns process Skills and executable Workflows, PRISM owns Analysis Skills, ASCEND owns validated Scientist Skill + remote MCP capability packs, and device Tools remain behind LabBridge. An advisory Scientist process design can reach Composer only as an immutable, explicitly unverified typed proposal; Composer preserves its hash and compiles it against local Capabilities, SOPs, policy, and safety rather than treating it as an executable Workflow. All normal safety boundaries remain in force.

The Evidence page is the normal Provenance surface. It uses a stable layout: conclusion and independent status badges first, then the optional Agent explanation, the source chain, explicit gaps/warnings, and progressively disclosed technical references. Selecting a source opens its bounded details; it does not navigate the user through module consoles by default. Experiment and Round pages show only a compact Provenance state and link to the Evidence page. The raw event Trace remains an advanced engineering view.

Provenance generation is automatic after a committed result becomes visible; there is no normal-user Generate provenance action. Dynamic records populate the fixed contract and UI skeleton rather than an Agent-invented presentation.

9.1 Experiment-owned records

Experiment is the only normal data-management root. ASCEND projects every owned record, artifact/archive reference, logical location, status, and retention class; private paths stay hidden and every new record carries coordination_id at creation.

Deleting an Experiment stops its work and runs one durable, idempotent owner purge in dependency order; each owner deletes its metadata, files, artifacts, snapshots, and derived records, while shared content remains until unreferenced. ASCEND deletes its root last and keeps it on owner failure. Cleanup acknowledgement does not wait for transient Agent sandbox termination: durable state is removed first and bounded container reclamation continues in the background. Owner failures are isolated per record and repeated infrastructure failures are circuit-broken; partial/failed purges return typed issue categories, affected owner/count, retry guidance, and explicit retained-root state. A minimal platform purge receipt remains; legacy unowned data is reported for governed reconciliation and never silently attached to a new Experiment. An engineering-owned map revision may reclaim a pre-lineage rehearsal chain only when every affected snapshot has empty owner context and every derived rehearsal environment is closed. The deletion preview reports the cleanup count; the map and derived records are removed in one transaction, while owned or live evidence remains a hard blocker.

9.2 Scientific analysis review

The Evidence page shows How this analysis reached its conclusion as a first-class conclusion/limitation/support summary and on the Provenance Analysis stage; no manual generation action is required. Its default view is a scientist-facing story of roughly 6–12 key checkpoints, not a raw Agent log. It starts with the conclusion and unresolved limitations, then lets the researcher follow supporting evidence and decisions backward.

The same immutable record has three coordinated views:

• Story is the default readable sequence of question, evidence, finding, decision, limitation, and conclusion;
• Graph defaults to the scientific network for branches, evidence, validation, and alternatives; low-level runtime nodes are an explicit advanced layer;
• Timeline groups each Tool call/result and replays failures and retries for advanced review.

Selecting a node opens a detail drawer with its scientific meaning, referenced data, bounded Tool input/output summary, concise decision reason, alternatives, uncertainty, validation outcome, related artifact/report section, and runtime version/time metadata. Technical identifiers and full trace details remain progressively disclosed.

The page displays trace completeness, evidence authority, validation/data quality, and unresolved gaps independently; it does not collapse them into one trust score. Missing checkpoints, unsupported claims, failed Tools, and legacy trace-only runs remain visible and understandable in plain language.

Researchers may annotate or question a node, mark the record reviewed, or request clarification. These actions create ASCEND-owned review/Attention records referencing immutable PRISM node identifiers; they do not edit the original analysis. A material request for clarification or reanalysis starts a new governed Analysis Run or plan decision rather than rewriting history. PRISM Web retains the complete engineering console and raw trace, while ASCEND remains the normal user surface.

9.3 Truthful showcase mode

ASCEND may provide a presentation-oriented Showcase Mode for demonstrations and progress reviews. Showcase Mode is a read-only projection of the same selected live or historical scene; it is not a new lifecycle, execution path, or evidence source.

• Mobile devices move from typed controller, SimFleet, or replay state: current pose, semantic equipment target, resolved work position, recorded path, motion status, and progress. Before any branch exists, LabBridge resolves the frozen layout's compatible mobile work positions and device-owned target, choosing a collision-free candidate for the current stage and returning all typed blockers; renderers cannot invent a destination, path, mobile assignment, or arrival.
• A navigable map revision freezes geometry, equipment placements and explicit device-relative Access Points. In the editor, the 2D canvas is the precise manipulation surface for placed equipment, occupied footprints, restricted zones, and walls; Add to layout lists unplaced fixed and movable equipment with declared DeviceModel geometry plus those three spatial-object types. Movable equipment uses the same select/add/move/remove interaction and a visible mobility mark, while its saved authoring pose remains a revision-only validation start and never becomes a live position. Selecting equipment opens a map-anchored action bubble that avoids its target and offers applicable move, removal, mobile assignment, and exact robot-work-point actions; Selected equipment is an informational summary, not a second control surface. Read-only maps use hover for transient detail and one external right-side Device panel for selection; they render neither a selected-marker label nor an in-map inspector. Spatial-object editing remains in the non-obscuring context bar; walls stay clearly visible and selectable in both views, may be removed from either selection context, and switch to 2D for unambiguous whole-wall or endpoint dragging. Users opt fixed equipment into robot service and may place one exact Access Point per compatible mobile unit while seeing occupied and safety envelopes. Each point declares whether it supports delivery, operation, pickup, or a combination; disabled service exposes no map target. Service faces, ports, docking/localization semantics and internal target IDs belong to the versioned DeviceModel/controller, not the map editor. Frozen-map materialization derives private role-aware approaches, evaluates all compatible collect-and-deliver paths against frozen mobile traffic, and records the lowest-cost feasible mobile and target; a small mobile-change penalty prevents churn without pinning the carrier when another route is materially better. A delivered carrier is received by the equipment work area; a later mobile collects it there, so changing mobile units is not modeled as a robot-to-robot handoff. Semantic plans name equipment and work role; no UI exposes a parallel station fact, and the server may propose a repair but cannot silently move a user-chosen point. Editing opens or resumes one workspace-owned mutable LayoutDraft; autosave and continuous qualification keep object-addressed bounds, collision, clearance, and connectivity blockers selectable without changing runtime truth. Review & use requalifies server-side, atomically publishes and activates one immutable MapRevision, and discards the draft; blocked drafts remain editable, while existing runs and replay retain their frozen revision. The overlay distinguishes occupied/safety envelopes from mechanical working reach; reach is never inferred and appears only when declared by the versioned DeviceModel.
• A guided camera, Agent activity core, capability pulses, handoff packets, and evidence-return particles are display effects. Their source mode and evidence authority remain visible.
• Agent activity uses bounded typed summaries, current stage, tool/Operation references, and evidence events. It never exposes or synthesizes hidden chain-of-thought.
• Live, replay, rehearsal, and demo data are labeled. A demo animation cannot be presented as a physical run, and a rendered completion cannot create or strengthen evidence.
• Public documentation may embed this same read-only map through an ASCEND-owned truth-labeled projection. Docs cannot select authority, issue actions, or reconstruct missing historical motion.
• LabBridge Spatial remains the engineering diagnostic view. The polished researcher narrative and automatic camera direction belong to ASCEND.

9.4 Conversation live feedback

ASCEND conversation uses one stable, accessible live-reply surface driven by a typed durable backend projection. It exposes truthful phase, elapsed time, safe Tool status, ordered partial output, and backend-provided reply-only actions; refresh/reconnect is replay-safe, reduced-motion remains equivalent, and no live presentation becomes evidence. The normative contract is ASCEND Conversation Live Feedback.

10. Deployment and Data Boundaries

Normal deployment exposes four responsibility units:

Unit	Current processes
Control	ASCEND and Composer
Execution	PACE and LabFlow
LabBridge	LabBridge gateway, adapters, and selected controllers
Analysis Worker	PRISM API, worker, callbacks, and sandbox Agent

Wrappers co-deploy existing processes without merging APIs, stores, or domain authority. Supervisor and Docs are required operational infrastructure outside the four domain units. deployments/topology.json is the machine-readable unit topology; health and logs are runtime observations, not architecture facts.

ASCEND is also the governed public transport edge for module MCP services. Each module keeps ownership of its tools, policy, Operations, evidence, and failure boundary; ASCEND provides an allowlisted service directory, identity boundary, and stable /mcp/<module> routing. Standard remote clients use Streamable HTTP. Custom WebSocket routing under /xiaozhi/mcp/<module> exists only for Xiaozhi and explicitly compatible clients and does not make WebSocket a requirement for every module. Both transports fail closed when neither trusted proxy identity nor a configured access token is available.

Large artifacts and immutable archives use scoped object-store identities and deterministic keys. Domain databases store metadata, lifecycle, checksums, and references. Agent context and cross-service events carry bounded projections, not large object bytes or credentials.

11. Safety, Security, and Audit

• Capability writes always enter through LabBridge semantic capabilities.
• Experimental capability writes fail closed unless LabBridge validates a completed, current Rehearsal lineage covering the exact semantic input; cancellation, stop, emergency, and safe-stop are fail-safe exceptions.
• Policy cannot replace controller-local safety in any future physical adapter; that invariant is preserved but physical adapter delivery is out of scope.
• Cancellation reports uncertainty and safe-stop outcome; it does not invent a verified final state.
• Operation completion and effect verification are separate. Every terminal result carries an explicit verification status; a missing, unknown, legacy, or transport-only status is unverified, never implicitly verified.
• Service, user, and object-store identities are least-privilege and separate.
• Secrets remain in deployment providers or ignored local configuration and are redacted from logs, traces, fixtures, prompts, and errors.
• Local runtime configuration has one revisioned source plus a separate secret store. Services consume generated projections, not business-setting process environment overrides; applying or rolling back configuration preserves the matching secret revision and reports affected deployment units.
• Every cross-domain command is authenticated, idempotent where required, and correlated to Goal, PlanRevision, RunSpec, Operation, evidence, and decision.
• Production claims require the production profile in Release Qualification. The retained physical profile applies only if a later accepted PRD reopens physical integration.

11.1 Current release qualification scope

The accepted release scope is the Agent-first software platform, simulated laboratory, governed human-assisted work, and their auditable execution and evidence boundaries. Production deployment qualification remains an active operational gate for this scope.

Physical-device integration and qualification are outside this PRD's delivery scope, acceptance criteria, release gates, and recommended work order. Simulated, predicted, algorithmic, human-supplied, or unverified output still cannot be relabeled as physical evidence. A later accepted PRD may reopen a concrete physical path without weakening the retained LabBridge, idempotency, safe-stop, observed-verification, and fail-closed evidence boundaries.

12. Acceptance Criteria

RIGOR satisfies this design when:

1. a researcher can submit a bounded goal and routine internal stages advance without lifecycle-button operation;
2. every interruption is a typed Human Task, important policy decision, material ambiguity, or unrecoverable problem with explicit actions;
3. direct atomic and reproducible multi-step paths share policy, Operation, audit, cancellation, verification, evidence, and trace semantics;
4. plans are versioned while executed scientific history remains immutable;
5. frontends render backend phases, blocking reasons, and available actions;
6. shared Agent runtime mechanics do not merge role authority, context, Skills, tools, or sandboxes;
7. a Specialist output cannot commit domain state without deterministic schema, policy, and evidence validation;
8. predicted, simulated, algorithmic, human-supplied, and unverified outputs retain their declared authority and cannot be promoted into a stronger evidence class by UI, replay, or Agent output;
9. every Agent decision can be traced to bounded context, versioned behavior, policy, tool calls, Operations, and evidence without hidden reasoning;
10. restart, retry, duplicate delivery, cancellation, and safe-stop paths retain idempotency and durable recovery;
11. each active stage has a durable liveness signal; internal transitions use bounded deadlines/recovery, while EXECUTING uses authoritative status reads without an elapsed-duration limit, superseded prompts expire, and persistent read failure becomes typed Attention without reissuing a device action;
12. deployment, object storage, identity, and backup qualification fail closed when external proof is absent;
13. module boundaries and public contracts are enforced by tests and generated client/schema drift checks;
14. missing or unknown verification is treated as unverified, and transport dispatch cannot satisfy an effect-verification gate;
15. Lab views label reality and source freshness, never mix active, revision, draft, or replay entities, and animate mobile units only from typed motion; the 2D editor separates placed-object management, additions, and robot validation setup, while its autosaved draft exposes blockers and Review & use rejects invalid geometry, starts, Access Points, or connectivity; derived navigation stays private;
16. Showcase Mode can narrate Agent-to-device work, device handoffs, and evidence return without issuing commands or changing lifecycle state;
17. public MCP routes are allowlisted and authenticated through ASCEND while tool execution, policy, audit, Operations, and evidence remain with the owning module;
18. a software release is requalified from a clean source tree with static, contract, generated-client, deterministic Web build, module, recovery, and browser gates passing against the exact released artifacts;
19. prepare, start, retry, promoted Plan execution, and direct experimental action cannot bypass the automatic Rehearsal gate, while read-only and safety actions remain available and predicted findings remain non-evidence.
20. every committed round exposes an automatic, fixed-schema Provenance projection bound to that exact iteration, with completeness, authority, verification/data quality, and gaps shown independently;
21. the Evidence page shows conclusion, optional constrained Agent explanation, source chain, and gaps without requiring a manual generation action; Agent failure cannot hide or invalidate the deterministic chain;
22. a Provenance explanation can reference only supplied source nodes and cannot add facts, edges, authority, verification, or evidence claims;
23. every new PRISM Analysis Run automatically retains objective runtime events and requires typed decision checkpoints without relying on an optional logging Tool call; an omitted checkpoint remains an explicit graph gap;
24. deterministic graph validation exposes dangling or unsupported claims, material rejected alternatives without reasons, failures, and missing checkpoints as explicit gaps, and bounded repair cannot fabricate them;
25. the Evidence page opens the exact Analysis Run in coordinated Story, Graph, and Timeline views, with conclusion-to-evidence navigation and independent completeness, authority, data-quality, and unresolved-gap states;
26. scientist annotations, review state, and clarification requests reference immutable PRISM nodes through ASCEND-owned records and cannot rewrite the original result or decision graph;
27. an Explainer failure, legacy run, or partial decision record leaves objective evidence and Tool history available and visibly labeled instead of presenting a falsely complete decision path.
28. an active ASCEND conversation turn immediately shows truthful queue, activity, elapsed-time, and reply-only stop feedback; supported answer text streams in order, reconnect restores durable progress without repeating the turn, reduced-motion users receive an equivalent static state, and no live presentation is treated as evidence.

13. Delivery Status

Scope	Status
Agent-first behavior and automatic routine advancement	Implemented; durable internal-stage deadlines, bounded recovery, execution status polling without a duration deadline, and typed stalled/status-unreachable/disabled-automation Attention locally requalified
Shared runtime, frontend contracts, durable jobs, and four-unit wrappers	Implemented
Hierarchical ASCEND primary interface	Source slice complete; released Web artifact consistency must pass requalification
Agent architecture convergence	Implementation and live Scientist/Planner/Analyst quality thresholds complete
CoN4Cl real-data study-design benchmark	Software-qualified; physical execution is outside the current scope
Maintainability convergence baseline	Implemented; ongoing hotspot reduction required
Agent-native virtual laboratory	Phases 0-3 and mandatory formal-execution Rehearsal gate implemented; physical substitution is outside the current scope
Truthful browser Showcase Mode	Implemented for typed scene replay and SimFleet motion
Evidence Provenance view	Implemented: fixed contract, automatic ASCEND projection, constrained Agent explanation, and primary Evidence UI
PRISM reviewable analysis decision graph	Implemented: required Analyst checkpoints, one bounded non-fabricating repair, deterministic immutable graph, read-only API, ASCEND Story/Graph/Timeline UI, legacy degradation, and immutable researcher review records
ASCEND MCP transport gateway	Streamable HTTP and Xiaozhi WebSocket routing implemented; production identity provisioning remains open
Software/simulated release	Requalified from the selected clean software tree on 2026-08-06; see the dated release record
Production deployment	Not yet qualified
Physical devices and effects	Outside the current product scope; require a later accepted PRD revision

The maintained detail, evidence links, and recommended order are in Current Progress. A checked box or passing software test does not qualify production operations or a scientific claim. The current scope makes no physical-device or physical-effect claim.