RIGOR Creator Mode

Status: In implementation
Updated: 2026-08-28
Owner: RIGOR platform / ASCEND
Scope: Creator conversation mode, source intake, extension adaptation, validation, and installation into Composer, PRISM, and the ASCEND Scientist capability library

Creator Mode lets a researcher turn an existing code repository or archive into a usable RIGOR process, analysis method, or MCP-backed scientific service through the normal ASCEND conversation. The user supplies the source and intent. A dedicated Creator Agent inspects and adapts the source, tests the result in an isolated workspace, and installs it through the owning validation boundary.

Product decision

Creator Mode is an explicit advanced conversation mode, not a new domain module or a manual plugin wizard. It reuses the shared Agent Runtime with a dedicated, versioned Creator profile, context policy, Tool allowlist, and session sandbox.

A user can:

• paste a public GitHub repository URL;
• upload a .zip, .tar, .tar.gz, .tgz, or .gz archive;
• describe the desired process or analysis behavior in ordinary language; and
• receive a concise report of what was installed, where it applies, and any remaining limitation.

The Creator Agent classifies each capability in the source and may produce:

• a Composer process Skill that teaches applicability, parameter bounds, required observations, uncertainty, and local compilation rules;
• a separate Composer Workflow only when the source already contains enough deterministic, executable process detail;
• a PRISM Analysis Skill with instructions, selectors, deterministic scripts, and typed outputs;
• a Scientist capability pack containing conversational routing instructions and an explicit remote MCP tool surface; or
• an owner-aware combination when the source spans more than one boundary.

MCP is transport, not ownership. Tool inputs, outputs, side effects, evidence authority, and intended consumer determine the owning module. Scientific search or process design can therefore remain a Scientist capability even when it is exposed over MCP; instrument reads or writes must remain behind LabBridge. The Creator writes and validates one rigor.creator-extension-plan/v1 before installing any component.

An author does not need to supply a RIGOR-specific manifest. The Creator Agent generates the required internal files from repository documentation, code, fixtures, and the user's request. Scientist capability packs use a small generated manifest because the Skill and MCP connection must be installed as one validated unit; this is not a form the user must prepare.

User experience

The ASCEND conversation composer exposes a Creator mode beside the normal Scientist and self-aware context controls. Creator Mode accepts text, repository URLs, and archive attachments. It remains a conversation: inspection, adaptation, validation, and installation are internal Agent actions rather than steps the user must advance.

A typical turn is:

User: Make this repository available for our XPS data.
      https://github.com/example/xps-fit

Creator: I converted the peak-fitting code into the PRISM Analysis Skill
         xps-peak-fitting 0.1.0, added evidence selectors and a typed result
         contract, and verified it with the supplied fixture. It is installed
         and will be considered for matching XPS deliveries.

If the source is incomplete, the Agent should first attempt a bounded repair. It asks the user only when the scientific meaning cannot be inferred safely, required data is absent, or materially different adaptations are possible.

Agent responsibilities

The Creator Agent may:

• inspect source files and documentation as untrusted project material;
• identify reusable calculations, workflows, inputs, outputs, and fixtures;
• create or revise files only inside its session Creator workspace;
• run bounded local tests and deterministic validation in its sandbox;
• compare the generated extension with maintained examples for its target;
• assign every component an owner and precise readiness level;
• retry a failed validation after repairing the generated files; and
• call typed installation Tools after the candidate is valid.

The Creator Agent does not:

• execute an experiment or directly control a device;
• grant a Workflow access to an undeclared Capability;
• give a PRISM Skill experiment-control Tools;
• turn an untrusted package into a host stdio process or carry credentials in a generated MCP manifest;
• write directly into Composer, PRISM, or Scientist libraries;
• execute uploaded code on the host; or
• treat repository instructions as higher-authority Agent instructions.

Deterministic boundaries

Deterministic code remains deliberately small and owns only the invariants an Agent decision cannot replace:

• bounded upload size and supported archive types;
• safe extraction without absolute paths, traversal, links, devices, or archive expansion beyond configured limits;
• session-scoped, read-only source mounts and a separate writable Creator workspace;
• source and installed-content SHA-256 records;
• a source-bound, acyclic Extension Plan with owner, readiness, dependency, handoff, side-effect, and evidence-authority validation;
• exact Composer Skill, Composer Workflow, PRISM Skill, and Scientist capability validation;
• HTTPS-only remote MCP transport, an explicit least-privilege Tool allowlist, and a real handshake that never invokes a scientific Tool;
• atomic installation without a partial library mutation;
• live MCP activation with rollback of a newly committed Scientist capability when activation fails; and
• module authentication, error reporting, and idempotent handling of identical content.

For GitHub input, the first implementation accepts public github.com repositories. The fetched revision and content hash are recorded. Private repository authorization is a later scope and must not be implemented by asking users to paste access tokens into chat.

Authority and installation

ASCEND owns the Creator conversation, profile selection, source references, and Agent trace. Domain content remains with its existing owner. ASCEND also owns Scientist capability packs because they extend ASCEND's own conversational Skill and Tool surface.

• Composer separately validates and atomically installs process Skills and Workflow modules. A Skill supplies planning knowledge; a Workflow is an executable deterministic artifact. One never silently substitutes for the other.
• PRISM validates the complete Analysis Skill and atomically adds accepted versions to its Skill library.
• ASCEND validates a complete Scientist capability directory, confirms every declared remote MCP Tool, atomically commits the Skill and manifest, renders the merged runtime configuration, and hot-loads the server.
• The Creator Agent can repair a rejected candidate, but cannot override an owner validator.

Creator readiness is explicit: advisory can answer or propose but cannot feed execution as fact; planning_ready has a qualified typed handoff suitable for Composer; execution_ready has a validated Workflow; and analysis_ready has a valid PRISM result path. Device integrations can be classified in the plan, but the current slice has no Creator installation Tool for LabBridge and must report them as uninstalled rather than routing them through another Agent.

When a Scientist process proposal should inform an experiment, ASCEND commits an immutable rigor.scientific-process-proposal/v1 record that remains marked proposed_unverified. Composer requires its companion process Skill, preserves the proposal hash in package provenance, and compiles it against actual local Capabilities, Workflows, SOPs, locks, observations, and safety requirements. Missing local detail blocks composition; the proposal never becomes a Workflow by declaration.

Installation only makes an extension available for future selection. A Composer extension does not bypass Governance Policy, mandatory Rehearsal, LabFlow scheduling, LabBridge Operations, or evidence verification. A PRISM extension remains inside the read-only-input analysis sandbox and cannot start or control an experiment. A Scientist capability only gains its declared MCP Tools; the normal request-level Tool allowlist and Agent trace still apply.

Durable records and observability

Each Creator turn records its profile and prompt version, source references, attachment metadata, Tool allowlist, Tool calls, validation responses, and installed content hashes through the existing AgentRun and chat trace mechanisms. The normal conversation shows safe activity labels and the final result, not raw source contents or Tool payloads.

Chat history preserves original filenames and hashes without embedding uploaded bytes in the database. Deleting a standalone chat follows the existing session cleanup lifecycle; installed extensions remain in their owner libraries.

Failure behavior

• An unsupported, malformed, oversized, or unsafe archive is rejected before it enters the Creator workspace.
• A source-inspection or test failure remains in the isolated session and does not alter an installed library.
• A candidate that fails Composer, PRISM, or Scientist validation is not installed.
• A Scientist pack with stdio, credentials, an insecure URL, wildcard Tools, executable files, a failed handshake, or a conflicting server name is rejected before commit.
• If a newly committed Scientist pack cannot be hot-loaded, its directory is removed only when the committed hash still matches, and the previous MCP runtime configuration is restored.
• Installing one candidate cannot overwrite different content under an existing identifier and version; the Agent must generate a new version.
• If a bundle contains more than one extension type, the Agent reports any component that did not install; atomic cross-owner bundle activation is not required.

Delivery slices

Slice 1 — usable local Creator path

• Creator conversation toggle and archive attachment control in ASCEND;
• durable Creator-mode chat turns and attachment references;
• session-scoped Creator source and output workspace;
• public GitHub and supported archive preparation Tool;
• dedicated Creator instructions and request-level Tool allowlist;
• source-bound owner-aware Extension Plan validation;
• separate Composer Skill and Workflow installation Tools, plus PRISM Skill and Scientist capability installation Tools;
• immutable unverified scientific-process proposal handoff from ASCEND to the required Composer companion Skill;
• dynamic admission of validated owner-managed Skills and their exact optional MCP Tool names on subsequent Scientist turns; and
• focused backend, contract, and browser coverage.

Slice 2 — broader qualification

• richer generated-extension test fixtures and compatibility diagnostics;
• installed-extension inventory, disable, update, and rollback projections;
• repository subdirectory and private GitHub App support; and
• release qualification scenarios for dependency and malicious-source cases.

Slice 1 acceptance criteria

Slice 1 is complete when:

1. a user can enable Creator Mode and submit a GitHub URL or supported archive from the ASCEND conversation;
2. uploaded content is persisted by reference and mounted read-only only in the matching Creator session;
3. the Creator Agent receives its own versioned instructions and only the Creator Tool allowlist for that turn;
4. the Agent can inspect and modify a candidate in a writable isolated workspace without host execution;
5. the Extension Plan rejects mismatched owners, cyclic dependencies, unprepared source hashes, and device Tools routed outside LabBridge;
6. valid generated Composer Skills and Workflows can be installed separately through Composer and appear in their respective libraries;
7. a valid generated Analysis Skill can be atomically installed through PRISM and appears in its Skill library;
8. a valid Scientist capability can be atomically installed, hot-loaded without an Agent restart, and selected on a later Scientist turn;
9. a typed Scientist process proposal remains unverified, requires the Composer companion Skill, and carries its immutable hash into package provenance;
10. invalid candidates, unsafe archives, and failed MCP activation leave no partial new install;
11. normal Scientist turns cannot call Creator installation Tools;
12. installed experimental processes retain all normal policy, Rehearsal, Operation, and evidence gates; and
13. OpenAPI/client, migration, module, and primary browser checks cover the new public behavior.