Runtime architecture

The Galen → Ledger pipeline

Every record on the public Ledger arrives via a fixed, role-separated path. Galen reasons. The operator authorises. Bankr broadcasts. The chain validates. The indexer reflects. The explorer renders.

Galen
  │  drafts a typed envelope against protean.ledger.v1
  ▼
Operator approval token
  │  5-minute TTL, single-use, mode-0600, actor + capability bound
  ▼
Bankr automation wallet  (AUTOMATION_WRITER_ROLE only)
  │  spend-capped: per-tx cap, per-day cap, allow-list, halt switch
  ▼
ProteanLedger.registerRecord(...)  on Base mainnet (chainId 8453)
  │  emits RecordRegistered + RecordContentEmitted
  ▼
Vercel cron indexer  (every minute, Neon Postgres)
  │  12-block confirmation window; sha256 digest recomputed
  ▼
Public explorer at protean.sh/ledger

Four principals, four distinct authorities. Galen holds zero on-chain roles. The operator holds OPERATOR_WRITER_ROLE and operational roles where granted. Bankr holds exactly AUTOMATION_WRITER_ROLE. The treasury wallet (proteanlabs.base.eth) holds DEFAULT_ADMIN_ROLE, UPGRADER_ROLE, PAUSER_ROLE, RETRACTOR_ROLE, LINEAGE_REVOKER_ROLE, and IP_DECLARANT_ROLE. Operator compromise is not governance compromise.

The cycle contract

A cycle has a fixed contract. It cannot reorder its stages, skip them, or recurse. The stage list is the canonical source in the cycle executor. The full sixteen-stage walkthrough lives in How a discovery cycle works; this page describes the execution layer that runs it.

The runtime is responsible for:

• maintaining cycle cadence and lock ownership
• routing model capabilities by task (Model routing)
• keeping deterministic validators authoritative
• producing review-ready candidate state
• applying bounded feedback only inside the declared envelope (Bounded learning)
• drafting the Ledger record envelopes that propagate this cycle's scientific objects to chain

What it does not do: it does not modify its own scoring contract, validators, prompts, or model routes; it does not recursively retrain; it does not remove failure-motif penalties; it does not publish without review; and it never signs or broadcasts on chain — that is Bankr's job, gated by the operator's approval token.

RecordTypes that ride the cycle

A single cycle can emit any of seventeen typed records on the Ledger. The ones produced by the standard cognition path:

• RuntimeCycle — the temporal root of the cycle. Anchors every other record produced in the same run.
• EvidenceBundle — the curated input record set the cycle consumed.
• Hypothesis — a reviewable scientific question raised inside the cycle, with confidence labels.
• Experiment — a computational study design tied to one or more hypotheses.
• Candidate — a peptide candidate proposed inside the constraint surface. Published candidates carry full sequence, sequence hash, salted commitment, provenance, and operator attribution.
• CandidateFamily — a family or cohort of related candidates with membership and lineage.
• CandidateLineage / FamilyLineage — explicit parent-child and family-derivation publication records.
• Thesis — a daily synthesised reasoning document.
• ScientificAsset — a citable aggregation of records (typically the assembled paper + supporting hypotheses + experiments). Carries a stable identifier that external citations resolve against.
• IPAsset — a provisional-IP intent record. Gated behind IP_DECLARANT_ROLE in addition to a writer role. Bankr cannot mint these.

Lineage edges (DerivedFrom, Tests, Supports, Contradicts, Supersedes, Retracts, Includes, Produces, Cites, ReviewedBy, Anchors, AssetOf, ProtectedBy, ParentOf, ChildOf, MemberOfFamily, VariantOf, FamilyDerivedFrom, PublishedAs, plus the Unknown sentinel) wire the records into a graph that any third-party indexer can reconstruct from the event log alone.

Supersession and retraction

Records on the Ledger are immutable as written, but their state evolves. Two state machines run in parallel:

• Lifecycle state uses the deployed enum: Draft, ReviewReady, Anchored, AssayRequested, AssayReturned, IPReview, PatentFiled, Published, Superseded, Disputed. A new record can supersede an old one by registering a Supersedes edge; the superseded record is preserved on chain with its lifecycle state updated.
• Disclosure state uses PrivateCommitmentOnly, RedactedPublic, CounselReviewed, PatentPending, Public, and Retracted. Retraction is a one-way move from any disclosed state to Retracted via the treasury-only RETRACTOR_ROLE. The retracted record stays on chain — public retraction is the point.

Either move emits an event the indexer picks up on the next cron tick. The explorer surfaces the current state alongside the original record content.

Off-chain artifact (supplemental, not primary)

Every cycle also writes a local snapshot directory to the operator's filesystem. This directory is not the canonical replayable record — the Ledger is. The snapshot serves three downstream purposes:

1. Operator audit. A reviewer with the directory can re-hash every artifact and re-derive the corresponding Ledger record's contentDigest.
2. Mirror publication. The reviewed public subset, including full sequences for intentionally published candidates and families, is committed to mirror_sources/artifacts/mainnet/ and published to GitHub and Gitlawb public verification rails.
3. Replay against the chain. The cited replayPointer on the on-chain record lets an external verifier fetch the mirror artifact, recompute its sha256, and confirm the on-chain commitment.

The snapshot writer uses atomic primitives (O_CREAT|O_EXCL + fsync + os.replace) so the directory is either fully present or absent — never half-written. The local validator re-hashes every file in the directory and compares against an internal manifest; this is integrity scaffolding, not the primary trust object.

Locking

Each cycle holds three layers of lock so that concurrent invocations cannot stomp on each other:

• a PID check against the in-process status file
• a process scan for any other cycle in flight
• a per-cycle lock file opened with O_CREAT|O_EXCL

The continuous daemon uses its own lock. A one-shot invocation is idempotent against an actively-running cycle but not against the daemon's sleep window — issuing a one-shot run while the daemon is between cycles produces a parallel cycle.

Verification — what a reader actually does

The deployed verification path has four parts. Each is grounded in chain state, not in our claims.

1. Read the record from chain. cast call 0xE3c261F3C05D4c4710003cd6066EfD95094cf5f0 "getRecord(bytes32)" <recordId> --rpc-url https://mainnet.base.org. The returned struct is the record's on-chain state — title, summary, recordType, lifecycle, disclosure, contentDigest, replayPointer, writer, registeredAt.
2. Reproduce the indexer digest. Clone proteanlabs1/ledger-mirror, run scripts/index_ledger_from_genesis.py against any Base RPC, compare the result to /ledger/api/v1/indexer/digest. Equality means the indexer state is reproducible from event logs alone.
3. Recompute the replay artifact sha256 (when the record's replayPointer is a mirror anchor). Fetch the artifact, run shasum -a 256, compare to the sha256 suffix on the pointer.
4. Walk lineage. Every edge is stored as EdgeState and emitted as EdgeLinked. The explorer's lineage panel and the LedgerEdge query API both surface the same event-derived data.

If all four pass, the reader has just personally reproduced our claim that this record exists, in this state, descended from these parents, at this block. No login. No wallet connect. No trust in us.

Runtime state

The platform tracks operational state across cycles so that repeated runs remain observable rather than opaque:

• source and evidence availability
• candidate counts and rejection reasons
• model route availability and capability health
• embedding availability (text + sequence)
• scoring weight normalisation status
• failure-memory influence (the failure-similarity contribution)
• learning mode and bounded adjustment status
• ledger-submission queue depth and per-record status (drafted, awaiting-approval, broadcast, confirmed, indexed)
• explanation coverage and warning burden

This state is operator-facing and is composed into the kernel's status report by Galen.

What this layer does not do

The runtime executes cycles. It does not classify health, schedule recovery, sign transactions, or contact wet-lab providers — those are the kernel's, Bankr's, and the operator's responsibilities, respectively. The runtime trusts the kernel to verify the workflow DAG and emit policy state; the kernel trusts the runtime to keep cycles bounded and Ledger envelopes well-formed.

This separation is what makes Galen the kernel, not the truth layer, and the Ledger the record, not a copy of the record.