PACE-PRISM-ASCEND Closed-Loop PRD

Status: Historical implemented PRD — superseded by docs/agent-first-system-design-prd.md Last updated: 2026-07-18 Primary owner: ASCEND / PACE / PRISM Scope: SDLX control plane, simulated devices, analysis automation, and Web operations

Archive note: this file preserves the completed PACE-PRISM-ASCEND P0 release scope and its nine acceptance criteria. It is not the current delivery plan.

1. Product Decision

SDLX uses the following product names and boundaries:

• ASCEND: Autonomous Scientific Coordination Engine for Novel Discovery.
• Coordination: the durable top-level ASCEND object that owns one scientific objective and its immutable Iterations.
• PACE: executes one approved Iteration and delivers its complete execution record.
• PRISM: Processing and Reasoning for Interpreting Scientific Measurements, an independent nanobot-based data-analysis service and Agent runtime.

Campaign is removed from ASCEND code, APIs, schemas, tools, and English UI. The canonical identifiers are coordination_id, coordination_iterations, /api/coordinations, ascend_create_coordination, and the coord_ prefix. This is a development-stage breaking change. No compatibility endpoint, alias, or database migration is required.

2. Product Goal

A researcher should normally define an objective and autonomy boundary with ASCEND once. SDLX then coordinates composition, execution, human intervention, result delivery, data analysis, and bounded next-round decisions until a stop condition, approval boundary, or unrecoverable block is reached.

The target loop is:

Researcher -> ASCEND Coordination
  -> Composer package
  -> PACE Iteration execution
  -> LabFlow / LabBridge / Human Tasks
  -> immutable PACE delivery archive
  -> PRISM Analysis Run
  -> PRISM data-analysis Agent with analysis-only Skills
  -> immutable analysis archive and structured Analysis Result
  -> ASCEND decision Agent
  -> next Iteration | stop | request human | blocked

PACE must hand completed results directly to PRISM. ASCEND must show the analysis lifecycle as it happens, but the ASCEND Agent must not receive PRISM's analysis Skills or perform the primary interpretation of raw device results.

3. Implemented Baseline

The following foundations are implemented and covered by module or system tests:

• ASCEND has an independent nanobot runtime, Web UI, durable top-level records, immutable Iterations, automation policy, decision proposals, notifications, and Composer/PACE references.
• Composer exposes POST /api/composer/jobs and produces reviewable PACE packages.
• PACE executes packages, preserves process facts, measurements, observations, tasks, incidents, TODOs, evidence, and artifact URIs.
• PACE exposes pace-result-bundle/v1, creates deterministic delivery archives, and owns a durable direct-to-PRISM results outbox.
• LabFlow and LabBridge support durable external waits, Human Tasks, rejection, resubmission, cancellation, artifacts, and restart reconciliation.
• PACE already has durable outbox patterns for TODO and incident delivery.
• PRISM owns durable Analysis Runs, PRISM-only Analysis Skills, controlled nanobot tools, per-run Podman sandboxes, processed artifacts, immutable analysis archives, and an Attention Event outbox.
• ASCEND persists PRISM lifecycle events through its global Attention Inbox and makes bounded decisions only from committed prism-analysis-result/v1 objects.
• Composer and ASCEND already use isolated module-local nanobot runtimes and the shared sdlx-agent-base Podman image.

The former direct Result Bundle decision path has been removed. No compatibility route or second post-execution path is retained.

3.1 Measured delivery status

As of 2026-07-16, the expanded closed-loop P0 implementation is 100% complete against the nine release-gate acceptance criteria below. Deployment qualification with physical instruments remains outside this PRD.

Phase	Status	Measured completion	Evidence
Phase 0: contracts and naming	Complete	100%	Coordination naming and executable delivery, Analysis Result, and callback contracts are committed
Phase 1: PACE delivery	Complete	100%	Deterministic archive, registry, durable outbox, idempotent dispatch, retry, and recovery are implemented
Phase 2: PRISM foundation	Complete	100%	Independent module, database, API, nanobot runtime, shared-image sandbox, Web, and manual upload are implemented
Phase 3: Agent analysis	Complete	100%	PRISM-only Skills, strict tool allowlist/audit, artifact validation, result commitment, archive, and callback outbox are implemented
Phase 4: ASCEND closure	Complete	100%	Analysis lifecycle, committed-result decision boundary, cancellation, and policy-bound continuation are implemented
Phase 5: system qualification	Complete	100%	Three simulated Iterations, restarts, duplicate delivery, callback retry, replay, next-round lineage, and deterministic stop pass

The existing pre-PRISM software platform remains approximately 90-93% complete because physical integration and production operations are separate work. The combined approved software P0 is approximately 93-95% complete.

4. Problem Statement

Device results are heterogeneous. A fixed parser and fixed scientific pipeline in PACE, LabBridge, or ASCEND would couple the control plane to every device data format and analysis method. Giving raw artifacts directly to the main ASCEND Agent would also mix data processing with Coordination policy and next-round decision making.

SDLX needs an independent Agent that:

1. receives the complete output of one PACE Iteration;
2. receives the relevant device-result Analysis Skills directly;
3. autonomously chooses allowed tools and analysis steps;
4. produces traceable processed data and a stable structured result;
5. archives the complete analysis run; and
6. notifies ASCEND only after the result is committed.

5. Product Principles

5.1 Preserve raw evidence

PACE delivery is immutable. PRISM never overwrites source files or PACE records. Every processed value must retain evidence references to source artifacts.

5.2 Agent-directed analysis

PRISM does not execute a hard-coded ordered list of device processors. The data-analysis Agent receives relevant Skills and independently selects tools, files, scripts, and analysis order within its sandbox and policy.

5.3 Skill isolation

Analysis Skill content is available only inside PRISM analysis sandboxes. PACE and ASCEND may store Skill IDs, versions, and hashes, but do not load the Skill instructions or bundled scripts.

5.4 Structured handoff

The PRISM Agent may use flexible internal methods, but it must commit a strict prism-analysis-result/v1 object. ASCEND makes decisions from this committed result, not from chat text or uncommitted working files.

5.5 Durable asynchronous boundaries

LLM calls, containers, HTTP requests, and processes may fail. Delivery records, Analysis Runs, Attention Events, and ASCEND state transitions must be idempotent and restart-safe.

6. Ownership Boundaries

Module	Owns	Does not own
ASCEND	Coordinations, Iterations, autonomy policy, analysis references, decisions, stop/continue state	Raw-data analysis, PRISM Skills, PACE execution
Composer	Experimental package generation and package review	Execution, data analysis, Coordination state
PACE	Iteration execution, result commitment, delivery archive, results-ready outbox	Scientific interpretation, next-round decisions
LabFlow	Deterministic workflow execution and durable waits	Cross-Iteration analysis or policy
LabBridge	Device operations, Human Tasks, artifacts, device state	Scientific analysis and next-round decisions
PRISM	Analysis Runs, analysis Agent, analysis Skills, tool sandbox, processed artifacts, analysis archive	Experiment execution, package generation, next-round decision

7. PACE Delivery Requirements

7.1 Delivery finalization

When a Loop Run reaches a terminal result state, PACE must atomically:

1. commit pace-result-bundle/v1;
2. build an immutable delivery manifest;
3. create or register the PACE delivery archive;
4. persist its URI, checksum, size, and version; and
5. write one pace.loop.results_ready/v1 outbox event.

The outbox event must not be emitted before the Result Bundle and archive record are committed.

7.2 Archive naming

The human-readable default is:

<coordination-name>_loop<iteration-number>.tar.gz

Object identity must use immutable IDs rather than the filename.

7.3 Required archive contents

manifest.json
coordination/
  objective.json
  iteration.json
package/
  pace.yaml
  workflows/
execution/
  tasks.json
  timeline.ndjson
  decisions-and-approvals.json
human-tasks/
  tasks.json
devices/
  operations.json
artifacts/
  index.json
quality/
  incidents.json
  todos.json
checksums.sha256

manifest.json must explain what was planned, what actually ran, which devices and capabilities were used, where human work occurred, what data was produced, and how every data artifact maps back to an operation and workflow step.

Small artifacts may be embedded. Large artifacts may remain in object storage, but the archive must contain role, media type, size, immutable URI, checksum, source operation, sample, and acquisition metadata. A later full-portable export may materialize every referenced object without changing the committed manifest.

7.4 Delivery event

Minimum payload:

{
  "schema": "pace.loop.results_ready/v1",
  "event_id": "evt_...",
  "coordination_id": "coord_...",
  "iteration_id": "iter_...",
  "loop_run_id": "loop_...",
  "result_bundle_uri": "s3://.../result-bundle.json",
  "delivery_archive_uri": "s3://.../coordination_loop1.tar.gz",
  "delivery_checksum": "sha256:...",
  "result_version": 1
}

The idempotency key is loop_run_id + result_version.

8. PRISM Module Requirements

8.1 Repository layout

PRISM is developed as an independent top-level module:

prism/
  backend/src/prism/
  web/admin/
  skills/
  tests/
  config/
  workspace/
  run/
  README.md
  PRD.md
  pyproject.toml

PRISM, Composer, and ASCEND must use the same immutable sdlx-agent-base image. PRISM must not introduce a second analysis-specific base image unless a proven dependency cannot be delivered as a versioned Skill or runtime-mounted tool. PRISM may reuse shared UI packages, but it must have its own configuration, database, process, module-local nanobot source/runtime, sessions, workspace, logs, model key, and Podman containers.

PRISM uses the same nanobot model-configuration shape as Composer and ASCEND:

llm:
  provider: deepseek
  model: deepseek-chat
  base_url: https://api.deepseek.com
  api_key: ""
  chat_completions_path: /chat/completions
  timeout_seconds: 90

Sharing an image does not permit runtime-state sharing. A PRISM Analysis Run must never attach to a Composer or ASCEND session/container.

8.2 Analysis Run lifecycle

QUEUED
  -> PREPARING
  -> ANALYZING
  -> COMMITTING
  -> COMPLETED

QUEUED | PREPARING | ANALYZING | COMMITTING
  -> BLOCKED | FAILED | CANCELED

An Analysis Run stores:

• analysis_run_id;
• Coordination, Iteration, and PACE Loop IDs;
• delivery archive URI and checksum;
• resolved Skill IDs, versions, and hashes;
• model and runtime configuration identity;
• sandbox identity and heartbeat;
• tool-call audit records;
• output artifacts;
• committed Analysis Result and archive references;
• retry lineage and terminal error.

8.3 PACE handoff API

PACE submits the durable event to:

POST /api/analysis-runs
Idempotency-Key: <loop_run_id>:<result_version>

PRISM returns the existing Analysis Run on duplicate submission. Acceptance of the request means the job is durably stored, not that an Agent is already running.

8.3.1 Deterministic delivery preflight

Before the first model turn, PRISM must verify the delivery checksum index and build a compact prism-delivery-preflight/v1 inventory. The preflight records delivery identity, integrity, files, result-bundle counts, planned conditions, device operations, and whether scientific evidence is available. It is mounted with the read-only input and included in the Agent context.

The Agent remains free to choose the relevant Analysis Skills and tools. It must not spend tool rounds rediscovering integrity or an empty evidence set that the deterministic preflight has already established. Strict ingress and result validation therefore bound a flexible analysis process without creating a fixed device-processing pipeline.

8.4 Skill resolution and injection

Each device-result Analysis Skill declares matching metadata such as device type, capability, artifact role, media type, and optional device ID. PRISM resolves all Skills relevant to devices and outputs present in the PACE manifest.

The complete matched Skill contents are mounted or injected directly into the data-analysis Agent. The Agent sees all relevant Skills for the Iteration and autonomously chooses which tools and scripts to use. PACE must not order or execute these Skills.

Each Skill package may contain:

SKILL.md
references/
scripts/
schemas/
fixtures/

A Skill must document input artifacts, field semantics, units, recommended methods, quality checks, available tools, expected output, and uncertainty or failure rules. Skill versions are immutable once referenced by a committed Analysis Run.

8.5 Analysis sandbox

Each run uses an isolated container such as:

prism-agent-<analysis_run_id>

The sandbox mounts separate read-only input and Skill paths plus one writable output path:

/workspace/input/
/workspace/skills/
/workspace/output/

Allowed tools initially include archive inspection, object-store reads, Python execution, table processing, image processing, plotting, and output artifact registration. Tool availability is controlled by an allowlist. Tool arguments, exit status, generated files, and timing are audited. Hidden model reasoning is not stored or exposed.

8.6 Analysis commitment

The Agent completes by writing a candidate analysis.json. Deterministic PRISM code validates its schema, verifies referenced artifacts and checksums, records the used Skill/tool versions, builds the analysis archive, and atomically marks the Analysis Run COMPLETED.

The Agent cannot mark its own run complete by chat output alone.

9. Analysis Result Contract

The committed result uses prism-analysis-result/v1:

{
  "schema": "prism-analysis-result/v1",
  "analysis_run_id": "analysis_...",
  "coordination_id": "coord_...",
  "iteration_id": "iter_...",
  "loop_run_id": "loop_...",
  "status": "COMPLETED",
  "summary": "Concise scientific interpretation.",
  "data_quality": {
    "status": "ACCEPTABLE",
    "issues": []
  },
  "device_results": [],
  "cross_device_findings": [],
  "metrics": [],
  "anomalies": [],
  "uncertainties": [],
  "evidence_refs": [],
  "analysis_artifacts": [],
  "skills_used": [],
  "analysis_archive_uri": "s3://.../analysis_v1.tar.gz",
  "committed_at": "2026-07-14T00:00:00Z"
}

Metrics require a semantic ID, value, unit when applicable, source evidence, and uncertainty or an explicit reason uncertainty is unavailable. The Analysis Result may report PARTIAL or NEEDS_REVIEW; ASCEND must not treat either as a fully successful scientific result.

9.1 Analysis archive

Default name:

<coordination-name>_loop<iteration-number>_analysis_v<version>.tar.gz

Required contents:

analysis.json
report.md
data-quality.json
skills-used.json
tool-calls.json
evidence-index.json
plots/
tables/
processed-data/
checksums.sha256

The original PACE archive remains immutable and separate.

10. ASCEND Integration Requirements

10.1 Coordination and Iteration states

ASCEND adds the following states:

PAUSED
ANALYSIS_QUEUED
ANALYZING
ANALYSIS_BLOCKED
DECIDING
COMPOSING_NEXT

PAUSED is a control-plane hold, not a claim that active downstream equipment has been frozen. ASCEND therefore accepts pause only at safe boundaries such as draft, package review, ready-to-prepare, ready-to-run, decision, or blocked. Resume restores the recorded pre-pause state. Completed and canceled Coordinations are terminal; restart creates a new Coordination carrying only the definition and automation policy.

Blocked-stage retry must create a new external Composer job, PACE run, or PRISM replay. ASCEND stores immutable attempt records with retry_of lineage and must not replace the historical failed reference.

Expected success path:

EXECUTING
  -> ANALYSIS_QUEUED
  -> ANALYZING
  -> DECIDING
  -> COMPOSING_NEXT
  -> EXECUTING

When PACE submits the Analysis Run, ASCEND must be updated with the analysis_run_id and transition to ANALYSIS_QUEUED or ANALYZING. This may be delivered from the same PACE outbox record with independently retried targets.

10.2 PRISM Attention Event

After atomic result commitment, PRISM sends an idempotent global Attention Event to POST /api/inbox/events:

{
  "schema": "sdlx.attention-event/v1",
  "event_id": "evt_...",
  "source": "prism",
  "kind": "analysis.completed",
  "severity": "info",
  "occurred_at": "2026-07-15T00:00:00Z",
  "correlation": {
    "coordination_id": "coord_...",
    "iteration_id": "iter_...",
    "loop_run_id": "loop_...",
    "resource_type": "analysis_run",
    "resource_id": "analysis_..."
  },
  "title": "Analysis completed",
  "summary": "The committed Analysis Result is ready for an ASCEND decision.",
  "data": {
    "schema": "prism.analysis.completed/v1",
    "analysis_run_id": "analysis_...",
    "analysis_result_uri": "s3://.../analysis.json",
    "analysis_archive_uri": "s3://.../analysis_v1.tar.gz",
    "checksum": "sha256:..."
  }
}

ASCEND persists the event before applying the analysis projection or starting a model turn. Duplicate events must not create duplicate decisions or Iterations.

10.3 Decision Agent input

ASCEND's decision Agent receives:

• Coordination objective and acceptance criteria;
• current and prior Iteration candidates;
• autonomy policy, bounds, budget, and stop conditions;
• committed prism-analysis-result/v1 objects;
• concise decision and approval history.

It does not receive PRISM Skills, raw archives, arbitrary LabFlow logs, or uncommitted PRISM workspace files. It may follow evidence references through a read-only inspection tool when review is necessary.

10.4 Next-round action

The Agent proposes exactly one action:

next_iteration | stop | request_human | blocked

Deterministic ASCEND code validates parameter bounds, maximum Iterations, budgets, stop conditions, required approvals, and duplicate lineage before applying a proposal. When policy permits autonomous continuation, ASCEND must be able to create the next Iteration, invoke Composer, prepare PACE, and start the run without an unnecessary UI step.

10.5 Responsive control-plane reads and Attention delivery

ASCEND must not reload an entire Coordination, Analysis Result, decision history, and chat transcript on every status check. The read contract is split into bounded projections:

• Coordination summaries and compact detail exclude full Analysis Results and decision payloads;
• selected evidence and activity are loaded only when their views are opened;
• chat history is newest-first and cursor-paginated;
• a process-local event stream invalidates Inbox and chat projections, with a low-frequency visibility-aware refresh only as a recovery fallback.

Attention decisions use a durable ASCEND-owned outbox. Accepting an operator decision returns 202 Accepted after the action and idempotency key are stored; the browser shows a queued delivery state instead of blocking on the producer. The dispatcher claims, retries with bounded backoff, and records the terminal producer response. A restart recovers claimed but unfinished deliveries. Producer acknowledgement then reaches the UI through the event stream. This contract applies to every producer-declared Attention action and contains no Composer-, PRISM-, or demo-specific approval branch.

11. PRISM Web Requirements

The first screen is an operational Analysis Runs workspace, not a landing page. It follows the SDLX visual system and shared localization contract, including the compact segmented English, Simplified Chinese, and Spanish language control.

Required views:

1. Analysis Runs: filterable status list with Coordination, Iteration, PACE run, model, duration, Skills, and result quality.
2. Run Detail: source manifest, loaded Skills, artifact inventory, progress, collapsed tool calls, live logs, output preview, errors, and lineage.
3. New Test Run: select an existing PACE Loop or upload a delivery archive, choose model/Skill versions, and run analysis independently from ASCEND.
4. Skill Library: inspect, validate, version, and fixture-test Analysis Skills. Skill content is not exposed through ASCEND.
5. Results: render Markdown reports, metrics, quality warnings, plots, processed tables, evidence links, and archive metadata.
6. System: PRISM Agent, model, Podman, PACE, ASCEND, and object-storage connectivity.

Replay creates a new Analysis Run and archive version; it never overwrites an existing committed result. Tool calls and streaming logs are collapsed by default. The sanitized Agent activity log can enter full screen and must remain full screen across polling updates. Internal chain-of-thought is never shown.

Polling must preserve the operator's selected Analysis Run while that run still exists. Operators may cancel active runs and delete terminal local run/result records. Deletion removes PRISM-owned workspace, report, archive, audit, and callback records only; it never deletes or mutates the source PACE delivery.

Results are grouped by Coordination, process, and Analysis Skill presentation profile. An Analysis Skill may declare a localized, versioned presentation schema containing profile identity, priority, labels, and ordered context, metric, quality, or summary columns. PRISM snapshots that schema with the committed result so future Skill changes cannot silently alter its scientific meaning. The Web uses the schema for series-specific table headers and semantic metric selection; it uses a generic evidence table when no Skill declares a profile. Scientifically empty deliveries stay visible in a separate expandable list and are never mixed into measured rows.

Legacy committed results are not rewritten. PRISM may derive result context from the immutable PACE manifest and apply the currently matching Skill schema as an explicitly marked read-only projection. A replay is required to create a new committed result with a frozen presentation snapshot.

12. Failure and Recovery

• PACE retries PRISM delivery and ASCEND state delivery independently.
• PRISM resumes durable queued work after restart.
• An Analysis Agent heartbeat loss moves the run to recoverable BLOCKED or retryable FAILED; it does not silently start a duplicate sandbox.
• Analysis output validation failure preserves workspace diagnostics but does not emit a completion event.
• PRISM Attention Event delivery uses an outbox and retries until ASCEND acknowledges the event.
• ASCEND records ANALYSIS_BLOCKED with the Analysis Run and diagnostic refs.
• Cancellation propagates from Coordination to active PACE and PRISM work.
• Every retry records a parent Analysis Run and uses a new output version.

13. Security and Governance

• PRISM uses the shared SDLX proxy identity contract and .sdl.digauto.org session cookie at deployment.
• Internal PACE/PRISM/ASCEND requests use service credentials and idempotency keys.
• Analysis Skills cannot grant tools; deterministic PRISM policy owns the tool allowlist.
• Input archives and Skills are read-only in the sandbox.
• Secrets are injected at runtime and never embedded in archives, logs, Skills, prompts, or repositories.
• Object-store writes are restricted to the Analysis Run output prefix.

14. Non-Goals

• Real-device controller implementation or physical-robot recovery.
• Requiring every device to emit a common scientifically interpreted schema.
• Executing device Analysis Skills inside LabBridge, LabFlow, or PACE.
• Giving Analysis Skills to the ASCEND main Agent.
• A deterministic fixed-order analysis pipeline for every experiment.
• Replacing PACE, Composer, or ASCEND with PRISM.
• Preserving old Campaign APIs, database tables, IDs, tools, or UI names.
• Email, enterprise chat, or external webhook notification in the first PRISM release.

15. Implementation Gap

Capability	Current state	Remaining production work
Coordination naming	Complete; old route is explicitly absent	None for this development-stage contract
PACE delivery and notification	Complete, including optional immutable S3/MinIO commitment	Provision production credentials, retention duration, and backup restore; local file:// remains a development fallback
Independent PRISM module	Complete	Provision production route, process supervision, secrets, and storage policy
Analysis Agent and Skills	Complete	Add instrument-specific Analysis Skills as physical devices arrive
Controlled analysis tools	Complete	Version any additional scientific dependencies before allowlisting them
Analysis contract and archive	Complete, including verified S3/MinIO input and result/archive commitment	Provision production retention and add governed portable-export/purge operations
Skill-driven result presentation	Complete, including generic fallback and read-only legacy projection	Add presentation schemas as new process-specific Analysis Skills are validated
ASCEND lifecycle and decisions	Complete, including safe pause/resume, terminal restart-as-new, and stage-attempt retry lineage	Calibrate policies and model prompts with real experiment evidence
ASCEND read performance and approvals	Complete, including compact projections, chat pagination, event stream, and durable decision outbox	Add multi-instance event fan-out when ASCEND is horizontally scaled
Automatic continuation	Complete within declared approval policy	Physical execution still depends on controller recovery guarantees
Closed-loop recovery qualification	Complete	Add long-duration soak and failure-injection runs in deployment
Operational Web and localization	Complete for EN, zh-CN, and es	Add new product copy to all three locale dictionaries before release

16. Delivery Phases

Phase 0: Contracts and naming - complete

• Complete the Campaign-to-Coordination breaking rename.
• Freeze delivery event, archive manifest, Analysis Result, and global Attention Event schemas.
• Update architecture and module ownership documentation.

Phase 1: PACE delivery - complete

• Build and register delivery archives.
• Add results-ready outbox, idempotent PRISM dispatch, and ASCEND state update.
• Test terminal result and restart delivery.

Phase 2: PRISM foundation - complete

• Create the independent module, database, API, aligned model config, module-local nanobot runtime, shared-image Podman sandbox, and operational Web shell.
• Support manual test runs from an uploaded archive or existing PACE Loop.

Phase 3: Agent analysis - complete

• Implement Skill library/resolution and direct Skill injection.
• Add controlled tools, streaming progress, deterministic output validation, analysis archive creation, and Attention Event outbox.

Phase 4: ASCEND closure - complete

• Add analysis lifecycle states and event ingestion.
• Replace direct Result Bundle evaluation with Analysis Result evaluation.
• Complete autonomous policy-bound next-round preparation and start.

Phase 5: System qualification - complete

• Run at least three simulated Iterations.
• Include one Human Task, one PRISM retry, one service restart, one analysis replay, and one deterministic stop condition.
• Verify no duplicate Analysis Run, decision, Iteration, or PACE execution.

17. Acceptance Criteria

The first end-to-end release is accepted when:

Current result: 9 of 9 criteria are satisfied by automated module, cross-process, Web build, localization, and Playwright checks. This is the P0 software release gate; it does not certify physical instruments or production deployment operations.

1. A simulated PACE Loop completes and produces one checksummed delivery archive that reconstructs the intended and actual experiment flow.
2. PACE creates exactly one durable PRISM Analysis Run and ASCEND displays ANALYZING without manual refresh.
3. The PRISM Agent receives only the relevant Analysis Skills, independently chooses allowed tools, and produces processed artifacts.
4. PRISM commits a valid prism-analysis-result/v1 and immutable analysis archive before notifying ASCEND.
5. ASCEND reads the committed Analysis Result, records one evidence-bound decision, and either stops or creates the next immutable Iteration.
6. Restarting PACE, PRISM, or ASCEND at each asynchronous boundary does not lose work or create duplicate records.
7. PRISM Web can independently submit, observe, inspect, replay, manage, and compare Analysis Runs in English, Simplified Chinese, and Spanish.
8. The ASCEND Agent cannot load PRISM Analysis Skills, and PRISM cannot start a PACE Loop or apply an ASCEND decision.
9. Composer, ASCEND, and PRISM run isolated nanobot sessions and containers from the same sdlx-agent-base image without sharing runtime state.