Configuration & security

Environment versus runtime configuration

Environment variables provide infrastructure and credentials. Published runtime configuration selects the workflow, allowlisted model, prompts, enabled tools, retry limits, time budget and gate thresholds.

Use the environment variables required by the provider selected in your runtime configuration. Actual secret values are not editable configuration fields and must never be sent to the browser, written into documentation or stored in graph state.

Published versions and snapshots

Publishing appends a new configuration version after schema validation. New research snapshots the active version; a saved run keeps its own input and configuration. Reverting a configuration creates another new version rather than editing history.

Seeding initializes defaults on an empty database. On an existing database, it refreshes defaults only when the active version is owned by the system seed publisher; it does not overwrite an administrator’s published configuration. Matching defaults are a no-op.

Prompt changes therefore require publication before new runs use them. Historical configurations without newer optional settings retain their compatibility defaults. A code restart and a configuration publication are separate operations.

Budgets and review policy

The current defaults select the simplified workflow, a 300-second total run budget, a 60-second model-call timeout, a 16,000-token output budget and one source-retry allowance. The simplified workflow permits at most one report repair.

These are defaults, not timing promises. Several independent review batches can be needed. The total budget remains the outer execution limit, and a model or source can fail before it is reached.

Supported provider/model combinations are explicitly validated in src/server/config/schema.ts. Provider-specific transport behavior and restrictions must also be respected; accepting a model identifier does not establish that the provider allows every workload or data-sharing arrangement.

Owner-scoped access

Research access uses a signed, HttpOnly owner cookie. The session has a seven-day lifetime and is secure in production. Run retrieval, event streams, mutations and PDF downloads check the owning principal; a run ID alone is not an access credential.

In non-production loopback development, address lookup or run creation can bootstrap a local session when signing is configured. This is a development capability, not verified user identity. Nonlocal bootstrap requires an explicit configured credential. Cross-origin mutations are rejected.

An access token issues a session; it does not make every session the same owner. Retain the issued cookie when returning to research. Clearing it can remove your capability to access earlier runs through that browser.

Private administration and source permissions

Administration APIs require the configured admin bearer token. Do not place it in a public frontend bundle or publish it in a request example. Run diagnostics and historical source observations are private operational data, not a public health or research endpoint.

Grid-source access is a separate opt-in. A technically reachable export and a locally enabled adapter are not evidence of commercial reuse or redistribution permission. Resolve licensing before deployment or redistribution.

Drain active work before restarting a worker to load code changes. Restarting the development web server does not automatically reload an independently running worker process.