The Discovery Engine

A scientific operating substrate for turning activity into state, state into tasks, and tasks into action.

A quiet watercolor horizon over still water, with a small sailboat beneath delicate constellation arcs.

Science Has Parts

Science already has most of the parts. It has the engine block, the wheels, the dashboard, the fuel tank, the inspection clipboard, the factory floor, and the autopilot. The parts do not share a drivetrain.

Papers live in journals. Datasets live in repositories. Code lives in GitHub. Lab results live in notebooks, LIMS, cloud-lab dashboards, clinical records, and instrument traces. Reviews live beside papers, in private emails, in grant panels, in Slack threads, and in the memories of people who move institutions. AI outputs live in chats. Hypotheses live in feeds. Experiments live in cloud labs. Funding decisions live in grant systems. Clinical reality lives somewhere else.

The fragmentation is not only a tooling problem. It is a fragmentation of epistemic state. A paper can tell you what an author claimed. It does not, by itself, tell the next system what changed, where the change applies, what confidence moved, what contradiction appeared, what depends on the claim, who attested it, and what should be tested next.

This is why a scientist still assembles the car by hand. She searches the literature in one place, checks data in another, reads code in a third, reconstructs methods from a supplement, asks a colleague whether a failure was real, opens a model chat that will not remember the correction tomorrow, and then writes a narrative artifact that another person has to reverse-engineer later. The system contains intelligence and labor. It does not contain a shared transition object.

The future engine for science is not one app. It is a unified, open, state-centered operating substrate with modular products on top.

The closest business analogy is Rippling, but only as a structural analogy. Rippling works because the employee becomes a shared object across HR, IT, finance, payroll, identity, devices, permissions, workflows, and reporting. The power is not that one vendor made many apps. The power is that many operational surfaces read and write one underlying state. A permission change can move from HR to identity to devices to finance because the object underneath them is shared.

Science needs an equivalent shared object, but the object is not a person, a paper, a dataset, a project, a lab, an agent, or a grant. The shared object is the scientific state transition.

Fig. 01. The trilogy. The public frame is Record, Engine, Body. In the essay-world, the same movement is Sky, Engine, Body: the shared record, the transition loop, and the physical infrastructure that acts on it.

This page is the middle artifact. Constellations of Borrowed Light argues that science needs a shared record. The Terafactory Age asks whether the engine reaches the physical world as an open public body or as closed private bodies first. This page names the architecture between them.

The public structure is Record, Engine, Body. Inside the essay-world, it is Sky, Engine, Body.

The claim here is narrower and more mechanical than the vision around it: if scientific work is going to compound across humans, agents, world models, and labs, the basic operating unit has to change from an artifact to a governed state transition.

The Shared Object

The primitive is not the paper. The primitive is the state transition.

You only need three objects at first: a proposed change, a reviewable diff, and an accepted event. The rest of the product language exists to serve those three.

A proposal says: here is the change I believe should be made.

A ScientificDiff says: here is what would change in the frontier if the proposal were accepted.

A ScientificCommit is the accepted transition package. It carries enough structure for another system to replay the effect, audit the evidence, inspect the provenance, recover the review target, and understand the conditions under which the change holds.

A Vela Event records the signed, replayable state change. An Atlas renders the living frontier updated by those events.

Two boundaries matter. A ScientificDiff is pre-merge: it is the review surface for a proposed change. A ScientificCommit is post-attestation: it is the semantic payload of accepted change. A Vela Event is the signed log envelope that orders the commit, makes it replayable, and lets another implementation inherit it.

The minimum runtime contract is intentionally small: content-address the evidence, describe the prior state, describe the proposed change, name the scope, attach reviewer signatures, record the event in order, and let another implementation replay the update into the same frontier. If a system cannot do that, it is not yet part of the engine. If it can do that, everything above it can remain modular.

The object is small enough to be boring and strong enough to carry the system:

Transition object
scientific state transition =
  1. prior state
  2. proposed change
  3. evidence packet
  4. context and scope
  5. provenance
  6. attestation target
  7. replay effect
  1. 01 Artifact

    paper, lab run, model output, review note

  2. 02 Relay

    capture the source and provenance

  3. 03 Carina

    compile it into typed scientific objects

  4. 04 Proposal

    name the intended frontier change

  5. 05 Scientific Diff

    show what state would move

  6. 06 Attestation

    scope, sign, reject, or contest

  7. 07 Scientific Commit

    package the accepted transition

  8. 08 Vela Event

    record the signed replayable envelope

  9. 09 Atlas

    materialize current frontier state

  10. 10 Research Task

    rerank the next useful work

Transition lifecycle. The engine is a lifecycle, not a pile of names. Activity becomes useful only when it passes from artifact capture into typed objects, proposed diffs, governed commits, signed events, and new frontier tasks.

That is the equivalent of a commit in software. It is also the equivalent of the employee object in Rippling: the thing every surface can read, update, audit, and use as its coordination anchor.

Fig. 02. Scientific diff. The review surface should show a proposed state change, not just prose. A reviewer can see exactly which status, scope, confidence, and downstream queues would change if the proposal merges.

ScientificCommit transition package
  1. 01 Proposal
  2. 02 ScientificDiff
  3. 03 Evidence
  4. 04 Provenance
  5. 05 Context
  6. 06 Attestation target
  7. 07 Replay effect
Accepted as Vela Event

content-addressed, signed, replayable, federated

Fig. 03. ScientificCommit anatomy. A ScientificCommit is the accepted transition payload, not the whole conversation around it. It carries the proposal, diff, evidence, provenance, context, attestation target, and replay effect that other systems can inherit.

Fig. 04. Event file. A real substrate artifact should look inspectable. The event is a small signed object that points to the proposal, diff, evidence, context, attestation target, and replay effect.

This distinction is the load-bearing one. A dataset is not state. A model prediction is not state. A robot run is not state. A review comment is not state. Each can become part of state only when it is converted into a proposed change, reviewed against a frontier, attested under governance, and recorded as an event that future work can inherit.

Take a schematic mechanism claim in Alzheimer’s: a vascular-inflammatory signature predicts early cognitive decline. Today a new cohort result may narrow that claim to APOE4-positive patients above sixty-five, but the change disperses through papers, talks, private reviewer judgment, grant summaries, trial-design spreadsheets, and model context windows. In the engine, the new evidence becomes a proposed state transition. The diff says the broad claim weakens, the subgroup claim strengthens, two dependent trial assumptions need review, and a model calibration record is stale. A reviewer is not asked to read another paper in isolation. She is asked whether this proposed change should merge.

Scientific work has always had a state machine, but it has been implicit and lossy. A lab runs an experiment. A result changes private belief. A paper turns some of that belief into prose. Reviewers inspect the prose. Readers infer what they think changed. Future labs reconstruct the implied update again. The state transition exists, but it is carried by narrative, memory, status, and citation rather than by an object designed to be replayed.

The Discovery Engine makes the transition explicit. That is what lets software surfaces, lab surfaces, review surfaces, funding surfaces, and learning surfaces remain modular without losing the frontier between them.

The Engine Loop

The engine is an operating loop, not a database.

Core loop
  1. 01 Goal
  2. 02 Frontier
  3. 03 Task
  4. 04 Activity
  5. 05 ScientificDiff
  6. 06 Attestation
  7. 07 Event
  8. 08 Atlas update
  9. 09 Next action

The loop starts with a goal: cure a disease, prove a theorem, build a better material, explain a climate signal, identify a safety risk, or decide which experiment deserves scarce lab time. The goal is not a slogan; it is a pressure on the frontier. It determines which uncertainty matters enough to become work.

The goal becomes a frontier: what is known, what is unknown, what is contested, what depends on what, and which uncertainties are worth spending effort to reduce. A frontier becomes tasks. Tasks are assigned to humans, agents, models, reviewers, labs, funders, or institutions. Activity produces artifacts: papers, extractions, simulations, protocols, robot runs, code, clinical observations, field measurements, and reviews.

Activity is still not state. It passes through the drivetrain.

The reference implementation can have many named surfaces, but the loop itself is simple. Capture preserves the artifact and provenance. Compilation turns it into typed scientific objects. Diff exposes the proposed change. Attestation decides whether it merges. The event log records the accepted transition. The Atlas renders the new frontier. Registry and telemetry exist so the loop can be governed rather than merely executed.

Goal, frontier, task, activity, diff, attestation, event, and Atlas forming a closed operating loop A circular operating loop where work begins as a goal, becomes frontier tasks, passes through activity, diff, attestation, and event, then updates the Atlas. 01 Goal 02 Frontier 03 Task 04 Activity 05 Diff 06 Attestation 07 Event 08 Atlas state transition activity becomes state, state chooses the next action
before status: contested

one BBB finding spans incompatible cohorts

after status: scoped

APOE4+ split, replication request, model recalibration

  1. frontier.rank BBB delivery discord rises
  2. diff.ready APOE4 subgroup split proposed
  3. event.commit Atlas update and task rerank

Fig. 05. The engine loop. The operating unit is not the paper. It is a governed transition: work proposes a change, review decides whether it should merge, the event updates the Atlas, and the next task is selected from the new state.

This is why the architecture is not simply a knowledge graph. A graph can store relationships. It does not, by itself, decide what should change next, who can propose it, who can merge it, what evidence is sufficient, or what physical action follows. A graph is a map. An engine needs a clutch.

It is also why the architecture is not simply an agent runtime. Agents can produce activity. They can extract, summarize, design, critique, and execute. Without a governed transition layer, their work becomes more output for another agent to summarize later.

The engine closes the loop:

Complete loop
  1. 01 State
  2. 02 Task
  3. 03 Model
  4. 04 Proposal
  5. 05 Diff
  6. 06 Review
  7. 07 Action
  8. 08 Evidence
  9. 09 Event
  10. 10 State

The loop is the drivetrain. Every product in the ecosystem matters only insofar as it helps the loop run with more fidelity, more throughput, more legitimacy, or less waste.

The design pressure is that the loop must be mundane enough for ordinary work. A graduate student should be able to extract a method, an agent should be able to open a provenance audit, a reviewer should be able to sign a narrow correction, and a lab should be able to write back a failed run without turning the act into ceremonial publication. The engine is only real when the smallest transition can travel.

The Four Planes

A discovery engine has four planes. The separation keeps the system from collapsing into metaphor.

discovery-engine/planes.live 4 planes synced
01

State

known, contested, scoped, actionable

Finding / Evidence / Frontier
without it activity cannot compound
02

Control

what should happen next

ResearchTask / Queue / SafetyGate
without it agents create noise
03

Model

what might happen if we act

Simulation / Prediction / Calibration
without it predictions float
04

Action

what touched reality

Protocol / RobotRun / LabResult
without it experiments vanish

Fig. 06. Four planes. The architecture separates what is known, how work is coordinated, how outcomes are forecast, and what physically changes. The planes share one event spine, but each one has a different shape of work.

The state plane is what is currently known, unknown, contested, scoped, weakened, deprecated, and actionable. It contains Atlases, findings, evidence, contexts, confidence histories, provenance, discord, frontiers, and scientific commits. Its job is to make scientific state typed, replayable, attestable, and federated. If the state plane fails, the engine becomes another pile of activity.

The control plane coordinates work. It contains ResearchTasks, queues, assignments, agent workspaces, review tasks, lab tasks, replication requests, funding tasks, and safety gates. It decides what should happen next and who is allowed to do it. This is the lesson from software agent orchestration: serious work needs tasks, isolated workspaces, review output, permissions, and boundaries, not one enormous conversation. Codex-style software orchestration is a useful adjacent pattern because it treats agent work as bounded tasks with reviewable outputs. The science version needs the same discipline, but with scientific state as the merge target.

The model plane predicts what might happen. World models, digital twins, simulations, counterfactuals, prediction records, model-state coupling, calibration records, and sim-to-real gaps all live here. Model outputs are powerful, but they do not become state by being generated. A prediction has to record which state it trained on, where it was validated, where it failed, and what evidence later contradicted it.

prediction 72%
lab result 58%
after update 63%
WorldModelCard

BBB transport twin

trained on
Atlas state: 2033-11-17
failure
overpredicted APOE4 transport
gap
sim-to-real +14 points

Fig. 07. Model calibration. The model plane needs its own record. Predictions become useful when they are coupled to the state they read from and recalibrated against the evidence that returns.

The action plane touches the world. Experiments, protocols, robot runs, lab results, clinical observations, simulation jobs, field measurements, instrument traces, and executed funding decisions all live here. Review belongs to governance and attestation. Funding usually belongs to control and allocation, unless it triggers an external execution event. The action plane is where the engine meets bodies, instruments, patients, organisms, materials, weather, and capital.

The complete engine is the relationship among the four:

Plane coupling
  1. 01 State guides control
  2. 02 Control assigns work
  3. 03 Models forecast action
  4. 04 Action produces evidence
  5. 05 Evidence proposes state transitions
  6. 06 Governance decides what merges

No plane can replace the others. A state plane without control is a museum. A control plane without state is a task manager. A model plane without state is a prediction market floating above reality. An action plane without writeback is the current lab system with better robots.

Products on the Substrate

The product form is a discovery operating system. The protocol form is Vela. The theory form is cumulative state theory.

That does not mean one closed monolith. It means a shared substrate that lets specialized products exist without fragmenting the frontier. The operating system is not one app. It is the set of objects and permissions that let many apps act as one system when state changes.

The substrate contains the open objects and rules: event log, schemas, signatures, replay semantics, federation, identity, signer recognition, provenance, capability declarations, safety classes, and governance hooks. Above it sit modular products, but the first fundable unit is not the full suite. It is one frontier where signed state transitions, a registry, and a review queue work together.

The names divide into layers. Vela is the event and transition protocol. Carina compiles captured material into typed objects. Atlas renders the materialized frontier. Registry handles identity, schemas, signer recognition, safety classes, and governance. Navigator, Relay, Observatory, Studio, lab write-back, world-model records, review allocation, and funding markets are surfaces around the same core.

state

Atlas

cockpit

Navigator

control

ResearchTask

review

ScientificDiff

forecast

World Models

execution

Lab Write-Back

shared state substrate one replayable scientific state substrate
  • Vela protocol
  • Carina object model
  • Registry
  • Signatures
  • Federation

Fig. 08. Modular products on one substrate. The discovery engine is not a single app. Products can specialize at the surface because they share lower-level state, schemas, identity, replay, and attestation.

The build order should be narrower than the eventual ecosystem. First make state transitions real in one serious frontier. Then make review, frontier state, task routing, lab write-back, and model write-back read and write the same transition substrate.

phase layer object first user action state effect
0 Protocol object Vela Event record a signed transition accepted change becomes replayable
1 Typed kernel Carina object compile artifact to evidence activity becomes proposal-ready
2 Review surface ScientificDiff scope, approve, contest, reject proposal becomes commit or hold
3 Frontier surface Atlas inspect current state events become navigable state
4 Control plane ResearchTask assign the next work state creates action
5 Write-back Lab and model connectors submit trace or prediction world contact becomes evidence

What gets built first. The product sequence is not build every science app. It is make state transitions real, then build the first surfaces that read and write them.

The Rippling analogy becomes concrete here. Rippling is strong because workforce objects can move across HR, IT, finance, payroll, identity, devices, and workflows. A Discovery Engine is strong because a scientific state transition can move across literature, evidence, code, lab execution, model prediction, funding, review, and governance.

The shared object lets the ecosystem remain plural. Different teams can build better search, better review surfaces, better lab orchestration, better education products, better safety gates, better model registries, and better funding markets. The products can compete while the state remains inheritable. That is the difference between an ecosystem and a suite.

Four Users

The engine should be concrete enough that a user can ask it for work, not only knowledge.

A disease foundation says: “We want to make progress on pediatric high-grade glioma.”

The engine responds with the current Atlas, the top unresolved frontiers, the highest-value discriminating experiments, the claims most fragile to provenance gaps, the agents already assigned, the expert reviews needed, the labs capable of execution, the safety class, the proposed ScientificDiffs, and what changed this week. The foundation is no longer buying isolated papers or grant reports. It is buying movement in the frontier.

For a foundation, this changes the week. A $5 million program does not begin with a blank call for proposals. It begins with a portfolio frontier: three candidate experiments, two fragile assumptions, one lab-capacity constraint, one safety class, and a reviewer queue. If a failed replication weakens the broad claim on Wednesday, Friday’s funding decision should know.

A student says: “I want to help cure brain tumors.”

The engine routes her to a frontier, then to a task appropriate to her current competence: link evidence for this claim, compare these two papers, check this method, extract the protocol conditions, inspect why a replication failed, draft a proposal, learn from the review. The student does not begin with a textbook/test pathway detached from real work. She begins with a small edge of the frontier that has somewhere for her contribution to land.

A robotic lab says: “Experiment E completed.”

The engine captures the protocol trace, instrument calibration, raw data, measured outcome, uncertainty, and execution context. It creates an evidence object, computes the ScientificDiff, routes for attestation, updates the Atlas if accepted, and updates the relevant model calibration records. The lab does not merely finish a run. It writes back.

robot run run_2033_11_18_B17
instrument trace cytokine signature
Instrument signal trace with highlighted peaks A cytokine-signature trace with a baseline, two highlighted peaks labeled APOE4+ and replication, and a receipt tying calibration, evidence, and diff output together. APOE4+ replication
calibration
ok
evidence
ev_perturb_441
diff
confidence -0.13

Fig. 09. Instrument writeback. The lab surface should look like instrumentation, not project management. The useful object is the connection between plate position, signal trace, calibration, raw data, and the state transition it proposes.

A model says: “I predict intervention X will work.”

The engine converts the prediction into a counterfactual proposal, checks the context and assumptions, ranks expected information gain, applies the safety gate, routes to lab or simulation, and writes back the outcome. The prediction is not trusted because it is fluent or because the model is impressive. It is trusted, weakened, or rejected through its relationship to state, action, evidence, and calibration.

These scenarios are intentionally ordinary. The engine is not interesting because it creates theatrical AI science demos. It is interesting because the mundane work of science stops being lost between systems.

  1. Mon
    Foundation asks what to fund next

    frontier gaps ranked

  2. Tue
    Student extracts protocol conditions

    evidence object improves

  3. Wed
    Lab failed run writes back

    claim scoped; model weakened

  4. Thu
    Reviewer signs subgroup diff

    Atlas state updates

  5. Fri
    Scheduler reranks the queue

    funding decision changes

A week in the engine. The operating substrate matters because ordinary actions land in the same frontier. A grant question, student contribution, lab failure, review decision, and scheduler update become one governed week of state movement.

Frontier Neurovascular Alzheimer's / BBB transport
state@vela:7f3c2a
ResearchTasks priority queue
  1. RT-1842
    BBB delivery claim split review · human
  2. RT-1843
    replicate assay in APOE4+ organoid line lab · robot
  3. RT-1844
    trace cohort-stratification provenance audit · agent
  4. RT-1845
    recalibrate vascular inflammation prior model · world model
ScientificDiff awaiting attestation
finding

Pericyte loss precedes cognitive decline in early Alzheimer's.

- broad sporadic AD population

+ APOE4-positive sporadic AD, age 65+, vascular-inflammatory subgroup

+ replication request opened against discordant animal model

Merge surface 2/3 signatures

domain reviewer signed

clinical statistician signed

trial liaison pending

on merge Vela Event → Atlas update → next task rerank

frontier bbb.transport.apoe4

capability clinical-stat-review

workspace scoped evidence + logs

safety class 2 / no public raw data

output diff or archived hold

expiry 14 days

Fig. 10. A frontier work docket. The control plane should feel less like chat and more like an operational docket: bounded tasks, explicit authority, proposed state changes, and a visible path from work to attested event.

Scaling Intelligence

You do not scale to millions or billions of scientific agents by letting every agent talk to every other agent.

You scale with structure.

Frontiers become shards: pediatric high-grade glioma, blood-brain-barrier delivery, protein binder design, a disputed theorem, climate attribution, drought-tolerant cultivars, direct-air-capture sorbents. Agents operate inside frontiers, not in one global chat.

Tasks become the coordination primitive. Check an evidence span. Extract a method. Propose a discriminating experiment. Review a contradiction. Verify a proof. Audit a provenance chain. Draft a lab protocol. Inspect a model’s sim-to-real gap.

A ResearchTask is not a prompt. It is a work contract: objective, frontier, input state, required capability, workspace boundary, allowed tools, safety class, evidence standard, expected output, reviewer requirement, expiry, budget, and downstream dependencies. The scheduler can deduplicate near-identical tasks, lease work to qualified actors, expire stale tasks, retry failed work, archive dead ends, and route high-risk outputs to heavier review.

Frontier sharding and merge authority Frontier nodes and agent workers route proposals into a central merge gate, showing that proposals can scale while merge authority remains scarce. BBB HGG Protein Climate Materials Proofs Trials a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 merge gate review · safety · attestation
proposal intake 18,421/day merge authority scarce

Fig. 11. Frontier sharding. At scale, agents do not enter one global room. They attach to frontiers, pick up bounded tasks, and route proposed changes through scarce merge authority.

Agents specialize. One is excellent at PubMed extraction. Another at Lean proofs. Another at protein design papers. Another at trial protocol critique. Another at statistical power checks. Another at lab safety. Another at reconciling contradictory clinical cohorts. Specialization matters because scientific work is not one job. It is a chain of jobs with different failure modes.

Every agent has a reliability record: accepted proposal rate, rejection reasons, later contradiction rate, citation hallucination rate, calibration, domain competence, review usefulness, and safety violations. The record does not have to be punitive to be essential. Reliability affects routing; routing produces work; review and later contradiction update reliability; reliability decays by domain and time. In a world of abundant generation, reliability is infrastructure.

Merge authority remains scarce. Millions of agents can propose. Few can merge.

The open-source law carries over:

Open-source law

Proposal access is broad.

Merge authority is governed.

At large scale, planning becomes hierarchical:

Planning hierarchy
  1. 01 Global goals
  2. 02 Atlas goals
  3. 03 Frontier goals
  4. 04 ResearchTasks
  5. 05 Agent workspaces
  6. 06 ScientificDiffs
  7. 07 Review queues
  8. 08 Vela Events

Markets and schedulers appear because scarce resources remain scarce: human review, lab time, funding, model recalibration, safety approval, clinical access, material transfer, regulatory attention. The engine does not abolish politics or allocation. It makes the allocation surface visible enough to govern.

The worst version of abundant agents is not that they produce nothing. It is that they produce too much low-legibility work for any institution to sort. The engine’s job is to make generation submit to structure: task boundaries, isolated workspaces, replayable evidence, calibration, review queues, signer reputation, safety classes, and merge authority. Agent spam, stale shards, poisoned evidence, model overconfidence, queue saturation, and reviewer capture are not edge cases. They are exactly what the control plane exists to absorb.

Governance and Capture

The bottleneck is not only intelligence. It is trustworthy integration.

Votes, comments, stars, citation counts, social attention, and agent output are not trust. They are signals. Trust enters when someone recognized for a domain, by a registry, under a revocable credential, signs a transition under rules that other institutions can inspect, contest, and inherit. The signature is not magic. It has scope, conflict metadata, expiration, appeal paths, and a registry that can itself be audited.

This makes governance a product requirement. Proposal access can be broad. Merge authority has to be governed. Identity, signer recognition, schema evolution, dispute handling, safety classification, maintainer turnover, and registry federation cannot be afterthoughts.

The first operator should not be a company pretending to be a commons. It should be a chartered nonprofit registry or consortium for a bounded frontier: member institutions hold seats, conflicts are logged, registry snapshots are portable, audits are public, data tiers are explicit, and a fork path exists if the registrar fails its charter. The first pilot is fundable because it is narrow: signed state transitions plus reviewer queue plus registry for one frontier, not a universal science operating system on day one.

The capture point is often above the nominally open layer. Git itself remained open, but much of software collaboration moved into platform-owned issues, pull requests, Actions, review history, social graphs, and contribution reputation. The scientific analogue is sharper. A protocol can be open while the canonical registry of signers, reviewer reputation, lab capabilities, safety gates, and regulatory recognition is closed. Open code with a closed registry is captured infrastructure with a permissive license file.

root keys

rotated by foundation charter

forkable under audit failure

signer recognition

domain consortia issue credentials

regulators query registry state

safety classes

public, delayed, permissioned, excluded

classification is itself reviewable

disputes

plural canonical views allowed

discord is represented as state

Fig. 13. Registry as governance. The registry is a social object as much as a technical one. It decides which signatures, safety gates, credentials, and disputes other institutions can trust.

state class public record delayed permissioned excluded
Commit metadata public no no no
Evidence summary public sometimes sometimes no
Raw clinical data no sometimes permissioned sometimes
Hazardous protocol detail no no no excluded
Dispute status public no no no
Signer credential public no no revocable

State visibility. Open state does not mean every byte is public. The protocol has to distinguish public record, delayed disclosure, permissioned evidence, and excluded detail.

The Discovery Engine has to be open protocol first, reference implementation second, ecosystem third, SaaS fourth.

Commons governance needs several properties:

  1. Multiple independent implementations can read and write the protocol.
  2. The canonical registry can be forked under chartered failure conditions.
  3. Signer recognition is federated, not owned by one company.
  4. Safety gates are inspectable and tied to existing institutional review where possible.
  5. Public and private state boundaries are explicit: public transition, delayed evidence packet, trusted-reviewer room, regulator-only packet, or excluded deposit.
  6. Disagreement can be represented as state, not forced into premature consensus.
  7. Review authority can be revoked, rotated, appealed, and audited.
  8. Registry snapshots, signer graphs, conformance tests, dispute records, and reputation exports are portable enough that capture can be contested.

This is where the middle page connects back to both other essays. Constellations argues for maintainers, plural canonical views, and structural separation. Terafactory argues that the orchestration layer and identity registry above physical facilities are the capture points that decide whether the body stays open.

The Discovery Engine is the architecture that makes those claims operational. Without governance, the engine becomes a faster way to manufacture apparent consensus. With governance, disagreement itself can become state: not noise around the record, but part of the record.

The states have to be explicit: contested, minority view, scope split, replication failed, under appeal, safety held, and retracted. Each has a different effect on what can be shown, routed, funded, repeated, or merged.

The Three Artifacts

The three pages should not repeat the same idea in three tones. Each has a specific job.

Constellations of Borrowed Light is the thesis. It begins with the human reason this matters and ends with the need for a shared frontier where corrections, failures, dependencies, and evidence can compound. Its purpose is moral and conceptual: why science needs a sky.

The Discovery Engine is the architecture. It names the shared object, the loop, the planes, the products, the users, the scaling problem, and the governance requirements. Its purpose is operational: what system must exist for the thesis to become infrastructure.

The Terafactory Age is the future scenario. It asks what happens when the architecture reaches labs, factories, clinical systems, materials, agriculture, funders, regulators, and geopolitical capital. Its purpose is civilizational: what world appears if the engine gets a body.

The internal architecture can still be state, runtime, and network. State is the substrate. Runtime is the coordination and execution layer. Network is federation across institutions. But the public trilogy should be clearer than the internal taxonomy:

The public trilogy is simpler than the internal taxonomy: why shared state matters, what engine makes it work, and what world follows if it scales.

The future of science is not more activity. It is activity that can become state, state that can guide action, and action that can return to the record.

That sentence is the hinge between the three essays. The first essay argues for the record. This one specifies the engine. The third asks what happens when the engine reaches enough physical capacity that scientific state can act in the world.

At small scale, that makes one researcher faster.

At large scale, it lets millions of agents and thousands of labs work without collapsing into noise.

Across the next thousand years, the details change. The invariant remains:

Intelligence and experimentation can become abundant. Trustworthy state integration remains the bottleneck.

Vela should make that bottleneck governable without owning it.

A quiet closing watercolor plate echoing the opening horizon, with borrowed light continuing forward.