Galen operations

Operational posture

Galen reports. Operators decide. There is no autonomous remediation path open today, by design and in code.

The runtime separates two surfaces. The cycle executor runs the science. Galen runs the kernel — health classification, workflow verification, operational state, and the operator approval contract. Both surfaces write to disk; operators read those records, classify health, and decide whether to act.

Continuous integration runs the full safety battery on every push: leak scanner, public-export verifier, public-export parity, runtime test suite, Galen workflow verification, contract tests, and the site/lab typecheck + build.

Runtime health classes

Galen classifies runtime health into four states. The classes are emitted by the capability surface and consumed by every operator-facing report.

ok                   all critical runtime systems healthy
ok_with_warnings     optional provider unavailable
                   deterministic backend active
                   cached ingestion fallback in use
                   probe mismatch
degraded             scientific-operational artifacts missing
                   critical retrieval / embedding /
                   lineage / provenance capability incomplete
failed               runtime crash, corrupted snapshot,
                   invalid artifact, orchestration failure

Anomaly model

Operations anomalies are tracked separately from health. The same anomaly can be observed across multiple cycles; the model tracks its current state.

active        recent / current failure
            affecting runtime or provenance integrity
resolved      historical anomaly only; latest runtime
            and manifest are healthy
recurring     repeated active failure inside the
            configured observation window
suppressed    operator-muted but retained in
            append-only history

Historical runtime tracebacks remain auditable. They do not trigger an action-needed status when newer healthy cycles prove recovery and cryptographic self-tests pass.

State machine

Galen drives a ten-state operational machine. Five states are reachable today; five are reserved for future writers. The reserved set matters as the shape of eventual telemetry, not as states observed today.

The reachable transitions cover the bulk of operational ground: a cycle moves from healthy to warning when optional capabilities degrade, to degraded when critical capabilities fail, to failed when a stage crashes outright. The awaiting_review state is entered when a review-gated artifact is produced; it exits back to healthy when the review completes.

Workflow DAG verification

Galen verifies that the runtime's declared workflow matches the canonical contract. The verification is shape-only: it confirms that each step is in the expected order, each failure_policy is declared, each review_gate is named, and the step cap (16) and recursion depth (0) are honoured.

Telegram approval flow

The Telegram interface is an operations channel, not a remote shell. Three rules hold without exception:

• No shell access. Galen exposes no command-execution surface to Telegram. The bot can read status, list pending actions, and request approval — that is the entire surface.
• Allowlisted users only. Every interaction validates the operator against an allowlist. Unknown users see nothing.
• Fixed action IDs. Approvals are HMAC-signed receipts for predeclared action IDs only. The set of action IDs is hardcoded and reviewed at CI time.

Today. The HMAC-signed receipt infrastructure is in place; the remediation surface apply_approved() returns { status: "refused" } for every input. There is no operator-side path open to mutate scientific state.

On the short-term path. A verified-receipt consumer wired against a small idempotent allowlist (log rotation, snapshot pruning — never scientific state). Opening that path will be a single reviewed change with CI coverage; until then, the refusal stands.

Refusal policy

The remediation surface refuses unconditionally. This is not a policy assertion; it is the function's implementation. A denylist plus an unconditional refuse in the apply path together form the contract.

Refusal applies to every category, today and at every release:

• code mutation
• scoring contract or validator mutation
• learning rule or prompt mutation
• model route mutation
• unreviewed sequence publication
• review-gate bypass
• wet-lab order submission

The fact that refusal is enforced by a function — not by a policy document — is the point. A future allowlist for low-risk, idempotent actions (log rotation, snapshot pruning) would open only the allowlisted paths, only with an HMAC-signed operator receipt, and only with a reviewed change to the apply path. Scientific state never enters the allowlist.