Core concepts

How Riven works

Riven runs a deterministic merge-governance pipeline on every change. There is no hidden reviewer intuition and no runtime guesswork standing in for graph evidence.

The pipeline

For each merge request, Riven runs this flow:

1. Index. Orbit Local indexes the checked-out repository and discovers graph tables such as gl_definition and gl_edge.
2. Map. Riven parses the diff, extracts changed line ranges, and maps them to the definitions those lines touch.
3. Traverse. For each changed definition, it walks inbound static CALLS edges to find direct and transitive callers.
4. Score. Risk is computed from deterministic factors: signature changes, caller count, caller depth, verification coverage, owner coverage, and architecture findings.
5. Gate. Riven emits risk-contract.yaml and returns the gate result through process exit code so GitLab CI can enforce it.
6. Remediate. Optional AI flows can draft proposals and candidate diffs, but only inside patch-plan validation and sandbox verification boundaries.

Why the graph matters

A file-level review can say "looks fine" while a changed function signature silently breaks callers in other files or directories. Riven finds those callers through Orbit edges and records them as concrete contract evidence.

The deterministic boundary

The parts that matter for merge control are computed by code, not by model prose:

• impacted definitions
• risk score inputs
• gate conditions
• recommended verification jobs
• owner hints
• architecture findings

Then it becomes infrastructure

The same workflow can be triggered through:

• the CLI
• GitLab MR pipelines
• the MCP server
• the published AI Catalog agent

Next: The risk contract.