ATLAS

ATLAS is the coordination space for an investigation. A project begins with a question and a set of research objects, then gains tasks, dependencies, evidence, computation receipts, figures, and reports as the work advances. Its planner routes work through registered capabilities; it does not turn an outline into a scientific result by itself.

The core habit is to make a plan legible before execution. Each task should state what it needs, what it may produce, and which upstream objects or decisions it depends on. That makes it easier for a colleague to notice a missing unit, a stale source, or a service that is not configured before time is spent on a run.

Create a project for one coherent research program. Record the question, intended scope, target or subject, and any assumptions that affect the work. Use research objects for the scientific entities, source records, datasets, or results that need stable identity and version history. Inspect an object's sources and relationships before using it as an input to a later task.

Keep the initial record specific enough that a collaborator can tell what evidence would answer the question. If the scope changes, capture that change as a decision or a new object revision instead of silently replacing the original intent. The first workspace is empty by design; ATLAS does not seed invented findings into a new investigation.

Open Plans & execution and add the work in the order it needs to happen. Define task type, inputs, parameters, conditions, dependencies, and bounded iterations. A task graph is useful when a later analysis depends on a particular evidence review or computation; encode that relationship rather than relying on a note in a separate document.

Before a task can be run, review the proposed dry run. Confirm the source versions, requested external calls, execution permissions, and available engine. ATLAS starts execution disabled. An unavailable or unauthorized engine should remain visible as a blocker with its output absent; do not treat a planned task or a submission receipt as a completed scientific result.

ATLAS coordinates product capabilities; it does not replace them. Vann can provide literature context, Mendel can provide biological connector requests, Kekulé can validate structures, Planck can submit an existing electronic-structure problem, Ising can run a configured particle model, Gauss can compare supplied measurements, and Turing can render datasets. Each connector must be configured and authorized in its own service. ATLAS exposes health and configuration errors so a URL alone does not count as a healthy connection.

When results return, attach their receipts and provenance to the relevant objects. Record what was reviewed, who made the decision, and which exact versions were considered. Treat planned outputs, absent engine outputs, and failed requests as different states; that distinction is essential when a project is revisited later.

Use the reporting workspace after the evidence and results are assembled. Select the research objects, source-linked findings, figures, and methods that belong in the narrative. Review the generated content as a draft: inspect source links, verify the language around uncertainty, and remove any text that makes a stronger claim than its inputs support.

ATLAS can export Markdown, HTML, Word, and LaTeX reports as well as JSON research packages. A report export is a communication artifact, not an independent validation of the investigation. For a handoff, include the relevant frozen plan and preserve source and result identifiers so the next team can see what the report was built from.

Local research is stored in `data/atlas.sqlite`. Keep the database together with its write-ahead log files while the application is running. Use SQLite backup facilities for a live backup, or stop the application before copying the database files. Research packages offer another way to preserve project content for a controlled handoff.

External service credentials belong in deployment configuration, not in research objects. When a task is blocked, inspect workspace policy and engine health instead of editing the scientific record to conceal the block. Revisit the plan whenever a source version or assumption changes, because downstream tasks may need another review.

A project is the working boundary for a coherent research question. Within it, objects carry their own identity, source reference, version, classification, and relationships. This lets a task name the exact molecule, source, dataset, or result it consumes instead of depending on a mutable label such as “latest.” Use the object inspector to check these details before adding an object to a plan.

When an object is revised, the earlier version remains part of the record. A reviewer can compare the versions, identify what changed, and see which downstream tasks refer to the prior state. Rejected, superseded, or changed source records can mark dependent work stale. That warning means the recorded basis has changed; it does not automatically establish that the result is wrong or that a new run will be equivalent.

The planner represents work as a directed graph. A task should state its operation, inputs, parameters, prerequisites, conditional results, and outputs. If a report depends on a reviewed figure, or a calculation depends on a validated molecular version, encode that dependency. An explanatory note is useful, but it cannot substitute for an explicit edge when execution order matters.

Review every proposed step for method fit and data readiness. Check bounded iterations and stop conditions before releasing a plan. Structured results determine conditions; absent or malformed values cannot be treated as convergence. Use plan history to compare revisions and branch from the revision that matches the question. Releasing a plan freezes that revision for later run comparison.

The run screen exposes task states, attempts, iterations, events, and engine summaries. A workflow policy and the current workspace policy both apply; the more restrictive autonomy or resource limit wins. Dispatch budgets and parallelism are checked before execution. A delayed task can retain a deadline without using active runtime while it waits, and a browser refresh does not stop server-side execution.

After a restart, active work is paused for deliberate continuation. Inspect which steps may have caused external effects before retrying. The application keeps local monitoring state distinct from a remote provider's state: cancelling a local monitor does not prove the remote job was cancelled. Reuse is conservative and optional; it requires compatible inputs, recorded output versions, hashes, review states, and engine identity rather than matching a task name alone.

Hypotheses & tests stores a versioned argument: a statement, its uncertainty, the evidence that supports it, evidence that challenges it, proposed tests, and an assessment rationale. Keep observation and interpretation distinct. A change in evidence or context can make an earlier assessment incomplete; preserve the former assessment and create a new one instead of editing the history into apparent certainty.

Use this area to prepare a research meeting or to translate an unresolved mechanism into a discriminating experiment. ATLAS does not calculate an automatic probability that a hypothesis is true. It can keep competing explanations visible and link the next test to the question it addresses. Use a rationale that explains why a result would support, weaken, or leave the hypothesis unresolved.

Clinical landscape queries ClinicalTrials.gov study records and preserves the registry fields that matter to interpretation: population, eligibility, intervention, endpoint timeframes, recruitment status, dates, and reported-result availability. Compare up to four studies in a saved, source-pinned report. Keep the difference between an endpoint described in a protocol and a result actually reported in the registry visible.

A registry comparison organizes records; it does not pool clinical outcomes, establish efficacy, or certify a treatment. Check the retrieval date, registry identifier, inclusion rationale, and missing fields. If the evidence question requires full publications or validated clinical synthesis, gather and review those sources through the appropriate process instead of inferring an answer from registry metadata alone.

The figures and visualizations workspace accepts supported observation files and keeps units with imported fields. Confirm the import preview before accepting data. ATLAS hands figure work to the existing Turing renderer; it does not contain an independent general-purpose plot engine. Save changed figure settings as a new version so a later reviewer can tell which view the report used.

Reports combine selected objects, source-linked findings, methods, figures, and tables. Narrative drafts persist separately from committed report revisions. Review source status and report checks before release; stale, rejected, missing, or unreviewed inputs can block a report from being marked ready. Exports include Markdown, HTML, Word, LaTeX, structured JSON, or a publication ZIP. The HTML print view can be used to create PDF.

Next research actions are generated from recorded state by explicit deterministic rules. The system can propose evidence gathering for an open question, reassessment for a contested hypothesis, result review, or research communication. Each proposal carries its source references and rule rationale so a collaborator can inspect why it appeared.

Accepting a proposal creates an inspectable plan; it does not launch a run. Defer or reject with a rationale when the action is premature or irrelevant. Changed source versions or review states can invalidate acceptance and require a new proposal. Treat these suggestions as a structured reminder of recorded gaps, not autonomous experimental design or unrestricted scientific reasoning.

A snapshot freezes a project state for comparison or handoff. Research packages include immutable object and workflow history, runs, and recorded events. Import remaps identities, resets execution permission, and retains prior execution records as an archive; an imported job is never automatically resumed. This makes import a controlled transfer of research context, not a way to bypass a new project's policy checks.

Local SQLite persistence includes write-ahead log files. Use SQLite backup facilities for a live backup or stop ATLAS before copying database files. Integrity verification, the research journal, and Nightingale's capture outbox answer different questions: local integrity checks do not prove a remote delivery succeeded, and a delivered provenance object does not replace the complete local execution history. Keep both states explicit during recovery.