Vela
A control plane that scores and gates whether a code change, human or agent written, can be trusted before it merges.
What it is
Vela is a forge control plane that decides whether a code change can be trusted before it is merged, shipped, or handed to an agent. It models repositories, pull requests, human and agent actors, readiness signals, and append only evidence. Git stores what changed; Vela records why a change was trusted, blocked, or queued.
The problem it solves
Engineers give coding agents write access and walk away, but the industries with real money at stake stay cautious because there is no shared record of why a change was safe to merge. As agent written code grows, “looks fine in review” does not scale, and there is no separation between what a human approved and what an agent did on its own.
How it works
Vela imports repository and pull request metadata from GitHub into a local model (no git remote of its own). Deterministic analyzers score three dimensions (change risk, test evidence, security) from the changed files and synced PR data, and a readiness function turns those into a ship, wait, or block verdict. A merge queue enforces review, branch protection, base freshness, and readiness gates before a change can move forward. Human and agent actors are tracked separately, policy is fail closed, and every decision is appended to a SHA-256 hash chained evidence log.
Where it fits
Vela is the merge time trust gate for code, the same idea Sardis applies to payments applied to pull requests. It is where agent generated diffs earn their way into main, with a record a human or auditor can replay.
Status
Phase 0 works locally: the forge model, GitHub metadata import, readiness analyzers, merge queue gates, fail closed policy, and the evidence ledger are functional. Real git commits, hosted CI callbacks, and actual merge execution are not wired yet.