Isn't this just BioRxiv / arXiv with extra steps?
Preprint servers move artifacts: a paper, a PDF, a snapshot at one moment. Vela moves state: which findings a field currently believes, what evidence they rest on, what would weaken them, and what depends on them.
A retraction on bioRxiv is metadata next to the paper. A Correction in Vela is an event that propagates through the dependency graph and notifies every downstream finding, trial, or review article that depended on the original claim. Different primitives, different unit of work.
Isn't this just Zenodo / figshare / OSF?
Those are content-addressed deposit registries. They store data, code, supplementary materials, and DOIs reliably. They're load-bearing for the work Vela depends on.
What they do not maintain is the live state of a claim. A dataset on Zenodo doesn't know which findings cite it, which ones have been retracted, or which downstream experiments would fail if the dataset turned out to be wrong. Vela is the layer that carries those edges.
Isn't this just OpenAlex / Semantic Scholar?
OpenAlex and Semantic Scholar are read-mostly graphs over the existing literature. They're invaluable as indexes; they let you find what's been written. Vela is a write target. The point is not to index what was published; the point is to give findings, failures, and corrections somewhere to live before they become a paper — and somewhere to update after they do.
A useful test: can an agent write a contradiction event into OpenAlex that other agents inherit? No, because OpenAlex is a snapshot of someone else's metadata. That gap is the gap Vela exists to fill.
Isn't this just nf-core / Galaxy / Snakemake?
Workflow systems are how an experiment runs reproducibly. They are upstream of Vela: a Vela EvidenceObject can point at a Galaxy or nf-core pipeline as the provenance of a numerical result. The substrate doesn't replace pipelines; it gives the things pipelines produce a place to be addressed and contested.
Isn't this just PubPeer + Retraction Watch?
Both do critical work and Vela cites them. PubPeer surfaces problems faster than journals do. Retraction Watch documents what journals quietly fix without proper correction trails. Both are read by humans. Neither produces machine-readable events that downstream pipelines can subscribe to.
A Correction event in Vela is structured enough that a Phase II trial's enrollment criteria can be programmatically updated when a foundational claim narrows in scope. PubPeer can tell you the foundational claim is contested; it cannot make the trial know.
Isn't the protocol overprescriptive? Fields are different.
The four primitives — Finding, EvidenceObject, Correction, dependency edge — were chosen because every field already uses them implicitly. A claim, the evidence behind it, the events that change it, the things that depend on it. Vela makes them addressable; it doesn't impose a schema on what counts as evidence inside a field.
Schema specialization happens above the protocol. An oncology frontier and a climate-model intercomparison frontier share the same primitives and disagree freely on what an EvidenceObject's metadata should look like. The primitives appendix documents the minimum surface that has to be shared.
What about credit? Tenure committees don't count this.
This is the load-bearing political problem and Vela does not pretend to solve it from inside the protocol. Without parallel credit reform — search committees, tenure committees, study sections counting signed contributions the way they count first-author papers — the people best positioned to deposit will reasonably refuse.
What the substrate does is make a signed Correction or a signed null result something that could be counted, the way a GitHub commit can be counted. The technical preconditions exist. The political work happens at the institutions that decide what counts.
What stops one company from capturing the substrate?
Three structural defenses, not aspirational ones.
Local-first by design. Every reducer can replay the canonical state from a folder of signed events. The hub is a mirror, not the source of truth. If the canonical hub disappears tomorrow, anyone with the event log can stand up another one.
Signed events portable across hubs. Ed25519 signatures travel with the events. A finding signed for one hub is verifiable on every hub that implements the protocol. There is no central key authority that gates participation.
Three independent reducer implementations — a Rust reducer
in crates/vela-protocol, a stdlib-only Python reducer in
clients/python/vela_reducer.py, and a stdlib-only TypeScript
reducer in clients/typescript/vela_reducer.ts. Each replays the
event log to byte-identical finding state. CI runs all three parity checks
on every push. Anyone worried about implementation lock-in can verify
against a different reducer in twenty minutes.
The defense isn't "we promise to stay open." The defense is that closing wouldn't accomplish anything: every event is already portable, every reducer is already replaceable, and every hub is already mirrorable.
Why Rust?
The reducer is the load-bearing piece: deterministic, byte-identical replay across machines and across years. Memory safety and freedom from undefined behavior matter when "did the same input produce the same output" is the central guarantee. The TypeScript and Python reducers exist to prove the guarantee isn't accidental.
Why Ed25519 specifically?
Compact (32-byte public keys, 64-byte signatures), fast, deterministic signatures, well-understood security model, and no dependency on a particular curve choice that might be deprecated. The signature scheme is part of the protocol; the implementation uses standard libraries on every reducer.
How is this different from the OpenAI Foundation Alzheimer's initiative?
The OpenAI Foundation initiative is a research program with funded teams producing findings. It is exactly the kind of effort that needs the substrate Vela proposes. Multiple teams producing discoveries in parallel still leave no shared map unless their failed attempts, partial replications, biomarkers, target hypotheses, and changing confidence enter one record. Vela is the candidate record.
They are not in conflict; they are complementary. The initiative's outputs become much more cumulative if there is a writeable substrate they all deposit into. Without one, six well-funded teams will produce six private maps.
Has anyone outside the founding team used this?
Not yet. Every signature on the live hub today is by a key under the founder's control. The technical substrate works. The social substrate begins when the first credentialed external scientist deposits a signed finding. Until then, technically real, socially unproven.
How do I try it?
Two paths. Thirty-second proof: curl -sSL https://vela-site.fly.dev/try | bash
downloads a real signed packet and a stdlib-only Python verifier and recomputes every
file's SHA-256 against the manifest. Ten-minute deposit: see
/quickstart for the full flow from
empty folder to first signed finding on the public hub.
How do I get involved or contribute?
Repository at github.com/vela-science/vela. The protocol design and reducers welcome pull requests. The focused anti-amyloid frontier welcomes proposed findings, evidence pointers, artifacts, and correction drafts via signed events. Email and DM for everything else because Vela has no formal signup yet. Every mechanism that exists is meant to work without one.