Stable URL

vela-site.fly.dev/spec (this page)

Protocol version

v1 · embedded in every signed event as the "v" field

Reference binary

vela v0.55.0 · pinned in the masthead and in /.well-known/vela

Test corpus

/reducer-fixtures.tar.gz · the conformance witness for new reducers

Editor

Will Blair <will.blair0708@gmail.com>

Source

github.com/vela-science/vela

License

Spec text CC-BY-4.0 · Reference implementation Apache-2.0 / MIT

Conformance language is RFC 2119. Each MUST / SHOULD / MAY below has a stable anchor id (e.g. #MUST-canonical-keys) so external conformance reports can cite exact clauses. The full anchor list is at §11.

A Vela implementation is conformant if and only if, given the canonical event log, it produces a frontier state byte-identical to the reference reducer. The reference reducer is the Rust crate vela-reducer at the version pinned by the tagged release. The Python and TypeScript reducers in the same release must match byte-for-byte; the byte-equality test is the conformance test.

The protocol uses RFC 2119 keywords. MUST means a non-conformant implementation is rejected by the hub. SHOULD means a non-conformant implementation is accepted but flagged. MAY means optional.

The protocol defines five primitive object types and one event envelope.

Finding

A scoped scientific claim. Has a content-addressed id, an assertion (free text), a confidence in [0,1], a scope (set of tags), and a list of evidence references. Findings MUST be content-addressed: id is the hash of the canonical-JSON of the finding minus the id field itself.

EvidenceObject

A pointer to evidence. Either a DOI, a dataset hash, a code commit, a trial registration id, or a URL. Has a type tag and an optional note. EvidenceObjects are referenced by Findings and by Corrections.

Correction

An event that updates a Finding. Has a kind (scope-narrow, confidence-down, confidence-up, retract), a reason (free text), and a list of supporting EvidenceObjects. Corrections propagate through the link graph: every claim that depends on the corrected Finding is notified.

Link

A typed edge between two claim ids. Kind is one of supports, depends, contradicts, narrows, or supersedes. The link graph is what makes Correction propagation meaningful. Cross-frontier targets use the vf_<id>@vfr_<id> form once a frontier dependency has been declared.

Frontier

A named scope of findings owned by a registered actor. Has a content-addressed vfr_<hash> id, a snapshot hash over the canonical state, and an event log that any conformant reducer can replay byte-identically.

The event envelope wraps every payload:

{
  "v":        1,                          // protocol version (uint)
  "id":       "ev_<hash>",                // content-addressed event id
  "ts":       "<RFC3339-UTC>",            // monotonic per actor
  "actor":    "did:key:z<base58btc>",     // signer's verifying key
  "kind":     "<event-kind>",             // see §4
  "frontier": "vfr_<hash>",               // target frontier id
  "payload":  { ... },                    // type-specific body
  "sig":      "ed25519:<base64url>"       // signature, see §5
}

Every field is REQUIRED. Implementations MUST reject events missing any field. Unknown fields MUST be preserved verbatim through serialization (forward-compat).

Vela uses vela.canonical-json/v1 for every byte-stable surface (signing, hashing, content-addressing). The rules:

1. MUST sort object keys lexicographically by their UTF-8 byte sequence.
2. MUST reject any input containing duplicate keys at the same nesting depth (RFC 8259 SHOULDs are insufficient — Vela requires hard rejection so reducers cannot diverge on which value wins).
3. MUST emit no whitespace between tokens; no leading or trailing whitespace.
4. MUST use the JSON escape rules in RFC 8259 with no extensions; lone surrogates and unpaired surrogates MUST be rejected.
5. MUST serialize numbers as integers or finite IEEE-754 doubles in their shortest round-trip form (ECMA-262 ToString). Integers outside the safe range [−(2^53−1), 2^53−1] MUST be encoded as strings; NaN, Infinity, and signed-zero edge cases MUST be rejected (write 0, never -0).
6. MUST preserve array element order.
7. MUST NFC-normalize Unicode strings before hashing or signing. Content-addressing operates on the NFC-normalized canonical bytes; an event whose id was hashed pre-NFC is non-conformant and reducers MUST reject it.
8. MUST emit UTF-8 with no byte-order mark; the BOM character (U+FEFF) anywhere in input MUST be rejected.
9. MUST reject control characters (U+0000–U+001F, U+007F) in object keys; in string values they MUST be escaped per RFC 8259.

A normative edge-case test vector set ships inside the reducer fixture archive at /reducer-fixtures.tar.gz. Implementations MUST pass every vector. Vectors include duplicate keys, integer overflow, NFC vs NFD collisions, lone surrogates, the Right-to-Left Override (U+202E), -0, 1e2 vs 100, control chars in keys, and BOM handling.

Two implementations producing different bytes for the same logical document are non-conformant. The byte-equality conformance test (§1) catches this.

The protocol defines the following event kinds. Each carries a type-specific payload schema.

frontier-init

Bootstraps a frontier. Payload: name, description. The first event in any frontier.

finding-drafted

A new Finding proposed (unsigned by reviewer). Payload: assertion, confidence, scope, evidence_refs.

finding-accepted

A reviewer accepts a drafted finding into the canonical state. Payload: finding_id, reviewer_did.

evidence-attached

An EvidenceObject attached to an existing Finding. Payload: finding_id, evidence_object.

correction

A Correction event. Payload: finding_id, kind, reason, supporting_evidence.

dependency-asserted

A typed edge between two claim ids. Payload: from_id, to_id, kind.

key-rotation

Rotates an actor's signing key. Payload: old_pubkey, new_pubkey, seq, signature_by_old, signature_by_new. MUST carry a strictly-increasing per-actor seq integer. MUST have ts strictly later than the prior rotation's ts for the same actor; reducers MUST reject any rotation event whose ts regresses, regardless of clock skew or signature validity. The interval between actor.add and the first rotation is the unrevocable window for an actor — implementations SHOULD recommend a first rotation within 30 days of registration to bound the key-compromise blast radius.

frontier-snapshot

A signed snapshot manifest summarizing the canonical state at a given event sequence. Optional; advisory only.

AgentRun — provenance metadata for LLM-authored proposals.

Any event where the immediate author is an LLM agent (rather than a human signer) MUST attach an AgentRun object to the event payload. The AgentRun is informational provenance — it is captured in the signing surface but does not alter the event's content-addressed id (a test in the reference implementation, agent_run_does_not_change_proposal_id, enforces this).

{
  "agent": {
    "id":        "scout-v3.2",                  // stable identifier
    "kind":      "llm_agent",                   // llm_agent | script | human
    "operator":  "did:key:z6Mk…"                // who ran the agent
  },
  "model": {
    "name":         "claude-sonnet-4-7",        // exact model name
    "version":      "20260301",                 // pinned version, no aliases
    "temperature":  0.0,
    "max_tokens":   4096,
    "system_prompt_hash": "sha256:7a91…"        // hash of the system prompt used
  },
  "telemetry": {
    "started_at":   "2026-05-02T18:14:33Z",
    "completed_at": "2026-05-02T18:15:09Z",
    "duration_ms":  35_704,
    "input_tokens":  12_318,
    "output_tokens":  847,
    "cost_usd":     0.0432,
    "retry_count":  0
  },
  "tool_calls": [
    {
      "tool":             "fetch_pdf",
      "schema":           "anthropic.tool_use.v1",   // or "openai.function_call.v1"
      "started_at":       "2026-05-02T18:14:38Z",
      "input":            { "url": "https://doi.org/10.1038/jcbfm.2015.44" },
      "permission_state": "granted"                  // granted | denied | not_required
    }
  ],
  "permissions": {
    "data_access":   ["frontier:read", "frontier:propose"],
    "tool_access":   ["fetch_pdf", "search_pubmed"],
    "publish_scope": "proposal_only"               // proposal_only | requires_review
  },
  "eval": {
    "harness_id":   "alzheimer-bbb-frontier-v1",
    "fixture_set":  "sha256:b3c2…",
    "passed":       true
  }
}

Required fields: agent.id, agent.kind, agent.operator; for kind=llm_agent additionally model.name and model.version (pinned, never an alias); permissions.publish_scope. Recommended: telemetry.cost_usd, telemetry.duration_ms, and model.system_prompt_hash so reviewer-acceptance rates can be attributed to a specific model + prompt combination, and reproductions can be re-run from the original system prompt.

Tool-call schema mapping. tool_calls[].schema declares which provider's tool-use envelope the input follows: anthropic.tool_use.v1 (the tool_use / tool_result block format), openai.function_call.v1 (the tool_calls array format), or mcp.v1 (Model Context Protocol). Reducers MUST NOT validate the inner input shape; that is the agent author's responsibility. This keeps the protocol agnostic to provider-specific tool-use evolution while preserving replayability of the agent run.

The signing scheme is ed25519-canonical-json-v1. The signing surface is the canonical-JSON serialization of the event with the sig field removed. Signatures are produced by Ed25519 over those bytes directly — the signing routine MUST NOT pre-hash. Implementations using libraries that pre-hash (e.g., Ed25519ph variants) are non-conformant.

Verification: re-serialize the event minus sig, recompute the signature surface, run ed25519_verify(actor_pubkey, surface, sig_bytes). The actor field encodes the verifying key as a did:key with multibase base58btc and multicodec ed25519-pub. Implementations MUST verify the multicodec tag matches before treating the embedded bytes as an Ed25519 public key.

The signature is base64url-encoded with no padding. The sig field format is ed25519:<base64url>. Other signature algorithm prefixes MAY be defined in future protocol versions; implementations MUST reject any prefix they do not recognize.

The reducer takes an ordered event log and produces a Frontier state. The function MUST be pure: same input bytes, same output bytes, no system clock, no randomness, no network.

Event ordering is determined first by ts (RFC 3339 UTC), then by actor (lexicographic on the did:key string), then by id (lexicographic on the content-addressed hash). Implementations MUST reject events whose ts precedes the most recent event by the same actor in the same frontier.

The output Frontier is a struct containing:

• findings: map of finding_id → current Finding (after all Corrections applied)
• evidence: map of evidence_object_id → EvidenceObject
• dependencies: directed graph keyed by (from_id, to_id, kind)
• actors: map of did:key → current verifying key (after all key rotations)
• snapshot_hash: the canonical-JSON hash of the entire above structure

Two reducers in different languages MUST produce identical snapshot_hash for the same event log. This is the load-bearing conformance property.

A hub is a server that accepts signed frontier publications, verifies the manifest and substrate hashes, persists the canonical event order, and serves materialized frontier state. The hub is a mirror, not the source of truth: signed manifests and event hashes remain independently verifiable.

• Hubs MUST validate publish signatures on POST and reject entries with invalid signatures (HTTP 400).
• Hubs MUST preserve event-log order as (vfr_id, seq) so the stored rows reproduce latest_event_log_hash.
• Hubs MUST promote only verified latest publications to live frontier reads. Failed latest rows remain audit history and MUST NOT be silently served as canonical.
• Hubs SHOULD serve GET /entries/<vfr>/events with cursor pagination and stable next_cursor.
• Hubs SHOULD serve GET /entries/<vfr>/events/stream and GET /frontier/<vfr>/inbox as server-sent event streams.
• Hubs SHOULD serve GET /entries/<vfr>/snapshot as a derived materialized snapshot, with CDN redirects allowed as an export optimization.
• Hubs MUST publish a /.well-known/vela document listing event endpoints, snapshot endpoint, signing mode, and agent_sla.
• Hubs MAY implement rate limiting; if they do, limits MUST be documented in the well-known document.
• Hubs MUST NOT require authentication for public read endpoints.
• Hubs MUST set Access-Control-Allow-Origin: * on public read endpoints.

Local-first: any client with the event log can reconstruct the canonical state without contacting any hub. Historical rows imported with authority_mode=manifest_snapshot use the signed manifest plus verified snapshot hash as the authority bridge when older events lack full replay payloads.

Agent traffic semantics.

Hubs serving high-volume agent traffic with direct event append enabled MUST implement the following write semantics:

• MUST accept an Idempotency-Key request header on event append POST. Two requests with the same Idempotency-Key + actor + frontier triple within a 24-hour window MUST resolve to the same outcome (the second is a no-op returning the original response). Prevents duplicate proposals from agent retries.
• MUST accept newline-delimited JSON event arrays on event append POST with Content-Type: application/jsonl. Up to 1000 events per request. Validation is transactional: either all events accepted or none, with a per-event error array in the response on rejection.
• SHOULD serve a streaming inbox endpoint at GET /frontier/<vfr>/inbox?since=<event_id> using server-sent events (text/event-stream) so reviewer agents and human inboxes can subscribe without polling.
• Hubs intending to serve agent traffic MUST publish an agent_sla object in /.well-known/vela: max events/second per actor, max bytes/event, request-rejection codes, and intended retry-after semantics. A hub that does not publish agent_sla is signaling it is not prepared for agent traffic and clients should treat it as best-effort.

Every event carries a v field naming the protocol version it conforms to. The current version is 1. Future versions will be defined in backwards-compatible additions; breaking changes increment the major version. Hubs MAY accept events from multiple versions and MUST advertise supported versions in the well-known document.

Findings are citable by URI. The canonical scheme is vela: followed by the content-addressed id; HTTP resolvers MUST redirect to a frontier-scoped page on a known hub.

vela:vf_83185611d673465b              # bare id, ambiguous across frontiers
vela:vfr_bd91…/vf_83185611d673465b   # frontier-scoped, unambiguous
https://vela-hub.fly.dev/v/vf_83185611d673465b   # HTTP resolver (redirects to frontier page)

Publishers SHOULD use the frontier-scoped form in references so readers can verify which signed manifest the citation points at. Hubs that resolve vela: URIs MUST serve a stable HTTP redirect target, MUST verify the frontier signature against its registered owner, and MUST surface the snapshot hash in the resolved page so readers can recompute the canonical state.

Recommended in-text citation: (Halliday et al. 2016, vela:vfr_bd91…/vf_8318…) — the parenthetical carries both the human reference and the machine-checkable id. Reference managers and journal stylesheets adopting vela: can resolve directly to the signed evidence chain.

Retraction and corrigendum interop.

A journal-issued retraction or expression-of-concern MAY be recorded as a correction event with kind retract signed by an actor whose registered identity carries the publisher_of_record claim for that finding's source. Reducers MUST retain the superseded finding's bytes as a tombstone (id, snapshot hash, last valid signature) so historical citations resolve to a "retracted" page rather than 404. Take-downs for legal or ethics reasons (HIPAA, court order, GDPR right-to-be-forgotten) MAY redact the finding's payload while preserving the tombstone hash; the redaction event itself MUST be signed and carry a structured reason code (legal, ethics, privacy) with no requirement to disclose specifics.

Author identity, COI, contribution.

An actor's registered did:key MAY bind to an ORCID via the orcid field on actor.add; the binding is a self-attestation, not third-party verification, until the actor publishes the same did:key on their ORCID profile. A finding's contributors array MAY carry CRediT-aligned contribution roles. A coi field MAY carry declared conflicts of interest in the same schema journals use for manuscript submission, so an author's signed finding is auditable for the same disclosures the journal would require on a paper.

Archival commitment.

Findings SHOULD be deposited into a long-term archival partner (Software Heritage for the event log, CLOCKSS or Portico for journal-pinned manifests) so that vela: URIs continue to resolve after a hub goes dark. Hubs MUST publish their archival arrangements in /.well-known/vela. Citations from journals that require persistence guarantees should target a vela: id whose hub declares a partnership with at least one such archive.

The reference implementation is the Rust workspace at github.com/vela-science/vela. The Python reducer at vela_reducer.py and the TypeScript reducer at vela_reducer.mjs are independent re-implementations, used as conformance witnesses.

A new implementation is conformant if and only if its byte-output matches the reference reducer's byte-output for the test corpus published with each tagged release. The corpus lives at /reducer-fixtures.tar.gz.

Stable per-clause anchors for external conformance reports. Cite by URL fragment.

• #MUST-canonical-keys — sort object keys lexicographically by UTF-8
• #MUST-canonical-whitespace — no whitespace between tokens
• #MUST-canonical-strings — RFC 8259 escapes, no extensions
• #MUST-canonical-numbers — shortest round-trip ECMA-262 ToString
• #MUST-canonical-arrays — preserve element order
• #MUST-canonical-nfc — NFC-normalize Unicode strings
• #MUST-canonical-utf8 — UTF-8, no BOM

A protocol is not philosophy-neutral. The choice to model science as Findings plus Corrections plus typed Links carries assumptions about what kind of object a scientific claim is, how knowledge accumulates, and what counts as progress. This section names those assumptions so they can be argued with rather than smuggled.

What the protocol assumes by default.

• Confidence is a scalar updated by evidence. The confidence.score field on a Finding is a single number on [0,1]. Reducers do not prescribe how a curator arrives at it, but the data structure presupposes that something like a Bayesian-style posterior is the right summary of an evidence base. Frequentist p-values, likelihoodist likelihood ratios, and severity-test outcomes all have to be projected onto that scalar to be expressible as a Finding.
• Knowledge accumulates by edge addition. The link graph (depends, contradicts, narrowed_by, superseded_by) treats progress as the steady accretion of typed relations between persistent objects. This is a Mertonian-cumulativist picture of science: prior work persists, gets corrected at the edges, and the structure of the field grows monotonically richer.
• Disagreement is local. A Contradiction is an edge between two specific Findings. Two reviewers who disagree about the credibility of a measurement can both publish signed Findings; the resulting contradiction is a graph artifact at the leaf, not a schism in the scaffolding.
• Observation is treated as separable from theory. An EvidenceObject records a measurement, an effect size, an image, a dataset row. The schema does not encode the theoretical apparatus that made that measurement legible — the instrument calibration, the analysis pipeline, the choice of what counted as a signal. Those live (if anywhere) in provenance as free-text and DOI references.

What the protocol handles well.

• Normal-science correction. A measurement is replicated; the new value is more precise; the older Finding is superseded. The vrev chain captures this without ambiguity.
• Scope refinement. A claim that held for "humans" is shown to hold only for an APOE4-positive subset; narrowed_by is exactly the edge type for this move.
• Contradiction surfacing. Two Findings make incompatible claims at compatible scopes; the Contradiction-Finder agent emits a contradicts edge with both sides traceable to signed evidence.
• Provenance and credit. Who signed what, when, and on the basis of what evidence — these are first-class fields, not a CSV exported from a journal database.

What the protocol does not capture.

These are not bugs; they are the cost of choosing a structure. Naming them is how the protocol stays honest about what it is for.

• Framework-level shifts. When a community comes to see a whole class of prior measurements as artifacts of an outmoded apparatus — phlogiston-era calorimetry, pre-DNA classifications of life, pre-GR measurements of Mercury's perihelion — the right move is not to add contradicts edges to every individual prior Finding. It is to mark a body of work as no-longer-comparable. The current schema can record this only crudely, by mass-superseding nodes inside a frontier; the reasons for the shift live in essays and reviews outside the graph. A future methodology-disqualification primitive (§8 versioning) is on the consideration list. We are not pretending Kuhn solved by adding a field; we are pretending only that incremental corrections are well-modeled here, and that framework-level shifts will need extra structure when the community finds itself wanting one.
• Theory-laden observation. The protocol cannot adjudicate whether two laboratories looking at the same slide are seeing the same phenomenon under different theoretical descriptions, or different phenomena altogether. The graph will faithfully record the disagreement; it will not tell you whose theoretical lens to trust.
• Tacit knowledge and craft. A measurement that requires a specific reagent batch, an assayist's hand, or an undocumented protocol step cannot be re-executed from a Finding plus its EvidenceObjects. The protocol captures what was claimed and signed; it does not capture what was known how to do.
• Discipline-scale norms. Whether a 0.62-confidence Finding counts as "strong evidence" depends on the field's evidentiary norms — what's routine in epidemiology is unacceptable in particle physics. The scalar travels across frontiers; the normative weight does not.
• Adversarial reframing. A bad-faith actor who publishes signed Findings designed to pollute the graph (rather than make false claims outright) is bounded by curator review, not by the schema. Reducers are value-neutral about whether a signed Finding deserves to be in the frontier.

Where this puts Vela.

The protocol is best read as infrastructure for the parts of scientific practice that are well-modeled by signed, content-addressed, typed-edge accumulation. That is most of what most working scientists do most days. It is not a model of how scientific revolutions occur, nor a substitute for the disciplinary judgment of which measurements deserve to be believed. Treat the frontier as the audit trail of a research community; treat the philosophy of why that community changed its mind as something the trail records traces of, not something the protocol decides.

The protocol is designed against a threat model in which actors may attempt to forge signatures, replay events, equivocate across hubs, exploit encoding ambiguities, or compromise keys. The structural defenses are documented inline (§3 canonical-JSON edges, §4 rotation seq, §5 ed25519-canonical-json-v1, §7 hub model). This section names the residual risks so implementers and auditors share a common picture.

Hub equivocation.

Two colluding hubs, or a hub and a forked mirror, can serve divergent event logs for the same vfr_id with all signatures still valid — the signature surface omits the hub URL. Protocol v1 does not defend against this; clients SHOULD pin a known-good hub or compare snapshot hashes across two independent mirrors before treating a frontier as canonical. Protocol v2 is expected to require a per-frontier append-only Merkle log with signed tree heads (Sigstore / Certificate Transparency pattern).

Key-compromise window.

An actor whose private key is stolen can sign arbitrary events under that identity until a key-rotation event is published. The per-actor monotonic seq (§4 #MUST-rotation-seq) and the ts-regression bound (#MUST-rotation-ts-bound) prevent the attacker from backdating a fraudulent rotation event to take over the identity. The actor.add → first-rotation interval has no revocation semantics; deployments SHOULD recommend a first rotation within 30 days.

Identity dual path.

The protocol expresses actor identity as did:key, but the SDK surface accepts a hex-encoded raw public key (vela actor add … --pubkey <HEX>) as a convenience. Implementations MUST validate that any actor identity is parseable as a conformant did:key regardless of which input form was used; the multicodec tag check (§5) is the load-bearing defense against accidentally treating arbitrary 32-byte input as an Ed25519 public key.

Replay across frontiers.

A signed event includes its target frontier field; reducers MUST reject events whose frontier field does not match the frontier they are reducing. Without that check, an event signed for frontier A could be replayed into frontier B with the original signature still valid.

Hub denial of service.

The hub model forbids authentication on read endpoints (§7) so that any client can verify any frontier without coordination. This makes hubs vulnerable to read-side resource exhaustion. Operators MAY rate-limit reads in operational response to attacks (must be documented in /.well-known/vela) but MUST NOT require auth tokens for the canonical read paths. Write endpoints (POST /entries) MAY apply rate limiting.

Reporting.

Security disclosures via the repo security policy — please don't open public issues for vulnerabilities; use the policy's private reporting channel. PGP / age public key for sensitive disclosures is published in /.well-known/security.txt.

Incident response runbook.

When a private signing key is compromised — laptop theft, supply-chain malware, coerced disclosure, or any reason to suspect the key is no longer under the actor's sole control — execute these steps in order:

1. Within 1 hour: publish a key-rotation event from the compromised actor identity using the procedure in §4. The new key supersedes the old; the strictly-increasing per-actor seq (#MUST-rotation-seq) and the ts-regression bound (#MUST-rotation-ts-bound) prevent an attacker from backdating a fraudulent rotation that would race the legitimate one.
2. Within 24 hours: post the new public-key fingerprint out-of-band on at least three independent surfaces — the actor's institutional web page, the actor's ORCID profile, and the /.well-known/vela/key-rotation-log on every conformant hub. Readers verifying a finding signed by this actor MUST be able to cross-check the fingerprint against at least two independent surfaces.
3. Within 72 hours: publish an incident notice as a signed finding-drafted event in the vfr_incident-log system frontier with kind=key-compromise, the compromised key fingerprint, the time window of suspected unauthorized use, and any signed events from that window the actor disavows. Reducers MUST NOT auto-revoke the disavowed events; disavowal is a reader-side annotation, not a state transition.

If the actor is unreachable: the actor MUST register an alternate contact at the time of actor.add — a second person with authority to publish a key-rotation from a designated recovery key that the alternate holds. The recovery key fingerprint is published in the same out-of-band locations as the primary. Without an alternate contact, the actor's identity is unrecoverable on key compromise — the protocol cannot rescue an actor from operational silence.

The current canonical out-of-band fingerprint location for the founder's signing key is github.com/vela-science/vela/blob/main/SECURITY.md.

Date	Binary	Change
2026-05-06	v0.55.0	Focused anti-amyloid decision console, trial table, source verification, and release packet centered on inspectable translation state
2026-05-04	v0.54.0	Workbench renders nulls / trajectories / tiers; demo script walks every kernel primitive end-to-end
2026-05-04	v0.53.0	Cross-impl digest tightening — Rust / Python / TypeScript reducers byte-equivalent on findings, negative_results, trajectories
2026-05-04	v0.52.0	Proposals-first integration — agent inbox can deposit nulls and trajectories through the same review-gated flow as findings
2026-05-04	v0.51.0	Dual-use access tiers (public / restricted / classified) + serve.rs read gating
2026-05-04	v0.50.0	Trajectory primitive (vtr_) — eighth essay primitive lands
2026-05-04	v0.49.0	NegativeResult primitive (vnr_) + BBB falsifier numerator (10 events)
2026-04-27	v0.48.0	Workbench launches; HeroConstellation goes live; protocol surface stabilizes for v1 freeze
2026-04-08	v0.46.0	Bridges (cross-frontier vbr_ records) introduced
2026-03-15	v0.44.0	Causal graph queries (Pearl L2 effect, L3 counterfactual) shipped
2026-02-22	v0.40.0	Causal claim type + evidence grade added to Finding
2026-01-30	v0.38.0	Threshold signatures (k-of-n joint accept) added
2025-12-08	v0.32.0	Weekly diffs become signed events; frontier diff ships
2025-11-10	v0.28.0	Reviewer / Contradiction-Finder / Experiment-Planner agents shipped
2025-10-04	v0.20.0	Federation primitives (vela registry mirror)
2025-09-12	v0.10.0	Quantitative assertion types (measurement, exclusion)
2025-08-25	v0.5.0	Phase R workbench draft queue + Phase S registry publish loop