Bounded infrastructure

Specialised systems

The runtime is composed of named systems that each own a specific scientific task. None of them is a general-purpose agent; each is a small, replaceable component with a clear boundary.

• Evidence systems. Maintain research context. BAAI/bge-m3 for text embeddings, BAAI/bge-reranker-v2-m3 for reranking, urchade/gliner_large-v2 for entity extraction, a local SQLite index for retrieval.
• Constraint systems. Compose the design space surface from evidence, failure memory, and project priorities. The composition is deterministic; the surface is the contract proposal obeys.
• Proposal systems. Explore candidates inside the constraint surface. facebook/esm2_t12_35M_UR50D for sequence embeddings, local Qwen models for proposal augmentation, deterministic samplers for the base path.
• Validation systems. Reject weak or invalid candidates against the deterministic gate list. Validators are authoritative; the proposal layer cannot override them.
• Scoring systems. Multi-axis ranking against the seven canonical BASE_WEIGHTS. Bounded adaptation within ±20% of base (±50% with trusted assay data), normalised at write time.
• Claim-QA systems. tasksource/ModernBERT-base-nli checks generated statements against the local evidence index. Conservative warnings reach the reviewer.
• Feedback systems. Single bounded pass per cycle when preconditions exist. Writes delta vector + reason + prior state + rollback path into supplemental operator-audit state; public truth is the approved Ledger record.
• Review systems. Prepare candidates for scientific evaluation. Drafts only; no auto-submit.

Why specialised, not unified

Specialisation has three practical benefits. First, each system has a declared input and output, so the platform's behaviour is composable and observable. Second, each system can be replaced independently — swapping the entity extractor does not affect the scoring contract. Third, the safety properties hold by construction: a validator that refuses to be rewritten by another system cannot be rewritten.

A general-purpose agent does not give the platform any of those properties. It hides the boundaries, makes failure modes harder to reason about, and creates upgrade-coupling between unrelated subsystems.

The coordination layer

The bounded operations kernel (Galen) composes status across the specialised systems, verifies the canonical workflow DAG, and drives the operational state machine. Galen is the coordination layer; it does not become the truth layer.

The runtime executor (the cycle executor) calls into the specialised systems in the canonical order defined by the workflow DAG. Each call has a declared envelope: input shape, output shape, time budget, failure policy. The kernel verifies that the executor honours the envelope.

What this posture refuses

The posture refuses several things explicitly. Refusal is the point.

• The runtime does not have a "general agent" that mediates between systems. Composition is explicit and code-level.
• The runtime does not allow one system to mutate another. Validators cannot be rewritten by proposal; scoring cannot be rewritten by learning; learning cannot be rewritten by claim QA.
• The runtime does not have an implicit shared memory across systems. Each system reads from explicit artifacts written by its predecessor.
• The runtime does not surface model behaviour as platform behaviour. Models propose; deterministic code decides.

What bounded operation means here

Bounded operation means the cycle can run fixed local operations without operator intervention on the canonical happy path. It does not mean the runtime makes scientific decisions, modifies its own contract, or replaces human review at any boundary that matters.

The platform automates bounded cycle work so that human attention can focus on the decisions that require it — candidate selection for review-gated assay-preparation drafts, publication intent, IP review, and the bounded set of operator-side remediation actions documented in Galen operations.