Roovno the Super Intelligent Software Factory
Sign up

Roovno: the Super Intelligent Software Factory

Merge AI-built PRs without re-reviewing everything.

Roovno runs builder agents on your codebase inside eight gates and turns a ticket or a spec into a tested PR. Before that PR reaches you, a reviewer from a different model family has read it, acceptance tests the builder never saw have passed, and its evidence bundle is assembled and hashed. You review the evidence, not every line.

Join the waitlist Take the product tour
Agent Baseline Level 2, partially What we don’t claim
One PR, eight gates. No stage approves itself. Illustrative run · synthetic data

Three locks on every merge

Enforced by the factory, not promised by the agent. If any one fails, nothing merges.

  • Gate 04 · Review

    Cross-family review

    A reviewer from a different model family reads every change. The builder’s harness never grades its own work.

  • Gate 05 · Test

    Held-out acceptance tests

    Written before the build and kept out of the builder’s reach. The builder cannot tune its code to tests it never saw.

  • Gate 06 · Verify

    Sealed evidence

    Who built it, which model, under which policy, with what results — assembled and hashed at Verify, sealed when the run ends. No log, no merge: it fails closed.

Measured from the same bundles Delivery speed and stability, first-pass gate rate, review rejections, cost and time per merged PR, human time saved. No second telemetry path.

Autonomy earned rung by rung Per repository and task class. A clean streak earns the next rung. Slipping metrics take it back. L3 comes later.

The agent proposes. Policy authorizes. Infrastructure enforces.

Product tour

One pull request. Eight gates. No self-approval.

Follow one agent-built PR through Roovno, from ticket to production. Every stage ends at an exit gate the stage cannot grant itself.

Stage 1 of 8 Intake

Illustrative · synthetic data
roovno · run r-2318 · example run, illustrative

01 IntakeWorkItem

WI-1042 Rate-limit CSV exports per workspace

  • risk · medium
  • platform/export-service
  • from signal SIG-3381

Goal

Cap CSV exports at 10 per workspace per hour, so one busy workspace cannot starve the shared export queue.

Acceptance criteria 4 of 4 testable

  • AC-1Over-limit export returns 429 with Retry-After
  • AC-2Limit counts per workspace, not per user
  • AC-3Per-plan limits live in policy, not in code
  • AC-4Exports already queued still run
Risk class
Medium · shared queue
Target repo
platform/export-service
Owner
Exports team
Open questions
0 · 2 resolved
Profile
svc-standard
Requested
09:40 · steward A. Lind
Exit gate · Definition-of-Ready pass checked by ready-check, not by Intake

02 PlanPreflight

WI-1042 Plan · 2 tasks, 1 branch each

  • request, not a grant
  • budget ≤ 400 lines
Task graph T2 waits on T1
T1 Workspace limiter + 429 on export svc-standard · Family A · ≤ 300 lines
T2 Per-plan limits from policy svc-config · Family A · ≤ 100 lines
Repo
platform/export-service
Paths
src/ratelimit/** src/exports/** test/exports/**
Allowed hosts
pkg-mirror.internal
Size budget
≤ 400 lines · ≤ 12 files
Builder
builder-07 · Family A
Reviewer
Family B · reserved

Plans are requests, never grants. The profile is a ceiling; a task may only narrow it.

Scope gate · deterministic policy pass policy/scope.v14.yaml · no model votes here

03 BuildSandbox

sbx-7f3a T1 · Workspace limiter + 429

  • fresh environment
  • no production credentials
  • egress · pkg-mirror.internal

session logwi-1042/t1-limiter

  1. sandboxcreated sbx-7f3a · image svc-base:2026.10 · credentials: none
  2. gitcheckout -b wi-1042/t1-limiter
  3. agentedit src/ratelimit/workspace-limiter.ts +84
  4. agentedit src/exports/handler.ts +22 −3
  5. agentadd test/exports/limiter.spec.ts +61
  6. testmake test exports · 48 passed
  7. agentrequest stage.complete
  8. policydeny · a builder cannot complete its own stage
  9. cirecorded build: pass · r-2318/ci-1

Files changed +167 −3

  • ratelimit/workspace-limiter.ts+84
  • test/exports/limiter.spec.ts+61
  • exports/handler.ts+22

Size budget 170 / 300 lines · T1

Inside the plan’s paths. No new hosts.

Builder can profile ceiling

  • Edit files inside planned paths
  • Run tests, push its own branch
  • Read production secrets
  • Approve, merge or write evidence
Build result · recorded by CI pass the builder cannot mark this stage complete

04 ReviewPR #418

#418 Rate-limit CSV exports per workspace

Builder · Family A Reviewer · Family B families differ · enforced

src/exports/handler.ts+22 −3

  1. 41 const ws = req.workspace;
  2. 42+ const slot = await limiter.take(ws.id);
  3. 43+ if (!slot.ok) {
  4. 44+ res.set("Retry-After", String(slot.retryAfter));

F-1 · majorresolved · 5c1e9a2

Retry-After counts from the window start, not from now. AC-1 wants the time to the next free slot.

evidence · AC-1 · limiter.spec.ts:41

  1. 45+ return res.status(429).json(LIMITED);
  2. 46+ }
  3. 47- queue.push(job);

F-2 · minorwaived by policy

Limiter state is per process. Two replicas would allow twice the limit.

waiver single-replica · policy v14 · follow-up WI-1047

Evidence-first rubric

  • Meets AC-1, AC-2, AC-4cites 3 tests · AC-3 ships in T2
  • Tests exercise the changelimiter.spec.ts
  • Stays inside planned scope3 files · all in paths
  • No secrets or credentialsnone touched
  • Open findings0 open · 1 waived
Review verdict · approve, 1 waiver pass the builder’s harness cannot review its own work

05 TestCI · r-2318/ci-2

#418 Checks · 7 of 7 complete

  • mandatory · blocks the gate
  • advisory · recorded
  • lintmandatoryclean
  • typesmandatory0 errors
  • unit · first-partymandatory48 passed
  • held-out acceptancemandatory9 / 9 passed written before build · the builder never saw these
  • secret scanmandatory0 findings
  • dependency auditmandatory0 high · 1 low
  • license checkadvisory1 notice

Held-out suite acceptance/held-out/wi-1042 · 9 tests for AC-1, AC-2 and AC-4, written at 09:41 before build began · builder read access: none

All mandatory checks green pass held-out suite stays sealed from the builder

06 VerifyEvidence

eb-2318 Evidence bundle

  • deterministic gate
  • no model in the loop
  1. run_idr-2318
  2. work_itemWI-1042
  3. agentbuilder-07 · Family A
  4. policyv14 · profile svc-standard
  5. cost · time$1.92 · 23m 22s
  6. retries0
  7. tests48 first-party · 9 held-out
  8. reviewFamily B · approve, 1 waiver
  9. scanssecrets 0 · deps 0 high
  10. sbomsbom/r-2318.json
  11. provenanceattestation 4be1…90c7
  12. decisions2 records · who, which policy

Assembled 10:03:32

sha256 9f2c 61ab e0d4 … 5b08 7e41

If the evidence log cannot be written, the run fails closed. No bundle, no merge.

Evidence written and hashed pass checked by the verify script, not by a model

07 ReleaseApproval

#418 Merge to main, then canary

  • risk medium → human required
  • policy v14

Approvals 1 required

  • builder-07 · Family Arequested approval 10:03 cannot approve
  • reviewer · Family Bverdict recorded · not an approver reviewed
  • Release steward · M. Lowehuman · approved 10:12 approved

The agent cannot grant the approval it needs.

Rollout

  1. Previewpr-418.preview.internal
  2. Canary · 5% of workspaces30 min watch · error budget intact
  3. Full rolloutwaits for a healthy canary

Decision record DR-31 appended to eb-2318

Ship into the afternoon peak at 5%, or wait for the evening window?

Options
now at 5% · wait until 18:00
Chosen
now at 5%
Who
Release steward
Policy
v14
Approval gate · steward approved pass requester and approver must differ

08 Operateexport-service

prod Health since release · 24 h

  • autonomy L1 · PR only
  • kill switch armed
  • p95 export latency 410 ms flat
  • 429 responses 3.1% expected · AC-1
  • 5xx on export spike ws-77 · 14:03
  • export queue depth −38% falling

Signal → WorkItem

5xx spike · ws-77oversized export, 14:03

01WI-1051 draftedenters Intake · needs a ready check

A signal can draft work. It cannot approve it.

Kill switch at every rung

  • Cancel runstops any run still open on WI-1042armed
  • Revoke tokensevery credential the run holdsarmed
  • Revert changeopens a revert of PR #418armed
Try the kill switch
Exit gate · Incident & feedback loop watching signals return to 01 Intake; they never grant authority

Inner loop · gate 1 of 8

Intake

Gate out
Definition-of-Ready: a goal, testable acceptance criteria, a risk class, a target repo and zero open questions.
Who owns the gate
The ready-check policy. A steward resolves open questions; the requester cannot wave it through.
Self-approval
Not possible. Intake cannot mark its own WorkItem ready.
How the two loops work

Want these gates on your repos? Join the waitlist

Stages 04–05 · Independent review

Independent by construction.

The reviewer is never from the builder’s model family. The acceptance tests are never the builder’s. Policy requires both, and infrastructure enforces them, before a review or a test can start.

04 Review Proof 01 · cross-family

A different family reads every change.

Policy rules on every pairing before a review can start. Pick one to see the check.

Six pairings are open to policy. The diagonal is locked: a family never reviews itself. Arrow keys move across the grid.
policy check · pr/418 · review pairing review.yaml v14

Allowed

review.family_must_differ: pass

Builder Family A · Reviewer Family B

Family B reviews Family A’s change.

# policy/review.yaml
review:
  family_must_differ: true
  waivers: policy-only

check builder=family-a
      reviewer=family-b
→ allow · reviewer assigned

Illustrative · synthetic policy and run

What the reviewer does

  • Evidence first. Reads the change against the spec, an evidence-first rubric, and the run’s record.

  • CI does the mechanics. Lint, types and tests are deferred to CI. The reviewer reads intent and risk.

  • Findings close on the record. Each one is resolved, or explicitly waived by policy.

  • No self-review. The implementer’s harness cannot review its own work.

05 Test Proof 02 · held-out

The tests the builder never saw.

A test author writes acceptance tests before build starts. They stay out of the builder’s reach until CI runs them.

sandbox/export-service · WI-1042 run r-2318 · gate 05 · Test builder-07 · Family A factory · CI

Builder’s own tests 48 passed

  • test/exports/limiter.spec.ts21
  • test/exports/export_job.spec.ts15
  • test/exports/api.spec.ts12

Held-out acceptance 9 sealed 9 / 9 passed

  1. AC-1 · over-limit export returns 429 with Retry-After 4
  2. AC-2 · limit counts per workspace, not per user 3
  3. AC-4 · exports already queued still run 2

$ ls acceptance/held-out/ls: cannot access 'acceptance/held-out/': No such file or directory

sealed sha256:9c1e…4af2written 09:41 by test-author · before build

Builder’s view: held-out tests sealed, out of the builder’s reach.Factory’s view: gate 05 passed. Held-out 9 of 9, builder’s own 48 of 48.

Illustrative · synthetic data

  1. IntakeSpec and acceptance criteria
  2. Test authorWrites and seals held-out tests
  3. BuildBuilder works without them
  4. TestCI runs both suites

How they stay held out

  • Never mounted. The suite is not in the builder’s sandbox or its context.

  • Not the builder’s to change. It cannot edit, skip, or delete a held-out test.

  • One failure shuts the gate. Whatever the builder’s own suite says.

  • Recorded apart. The evidence bundle keeps first-party and held-out results separate.

Both results are recorded in the run’s evidence bundle: reviewer family, findings, first-party and held-out tests. See the evidence bundle

06 Verify · Sealed evidence

Every run ends sealed.

Who built it, what changed, which policy allowed it, which models did the work. One tamper-evident bundle per run, with a provenance attestation and an SBOM reference. Assembled at 06 Verify, sealed when the run ends.

Four questions every bundle answers

Select one to find it in the bundle

Example run · synthetic

Evidence bundle · ledger-service

Round partial refunds half-even

PR #412 · WI-2817 · backend-standard

Provenance attested SBOM-ready

Run Sealed

run_7f3k2q9d

Sealed at run end · 21 min · $1.84 Example values · synthetic 

{
  "run_id": "run_7f3k2q9d",
  "work_item": {
    "id": "WI-2817",
    "title": "Round partial refunds half-even",
    "repo": "ledger-service",
    "pr": 412,
    "diff": { "files": 6, "added": 148, "removed": 37 }
  },
  "agent": {
    "id": "builder-07",
    "approver": "human:r.ilves"
  },
  "models": {
    "builder_family": "A",
    "reviewer_family": "B"
  },
  "policy_version": "v14",
  "profile": "backend-standard",
  "verdicts": {
    "intake": ["pass"],
    "plan": ["pass"],
    "build": ["pass"],
    "review": ["pass"],
    "test": ["fail", "pass"],
    "verify": ["pass"],
    "release": ["approved"]
  },
  "tests": {
    "first_party": { "passed": 214, "failed": 0 },
    "held_out": {
      "passed": 12,
      "failed": 0,
      "builder_saw": false
    }
  },
  "review": {
    "verdict": "approve",
    "findings_resolved": 3,
    "findings_waived": 1
  },
  "scans": {
    "secrets": { "findings": 0, "tool": "secret-scan" }
  },
  "sbom": "ref:sbom/run_7f3k2q9d.cdx.json",
  "provenance": {
    "commit": "9c41e07b",
    "builder": "ci/ephemeral-runner",
    "attestation": "sha256:5d1e9a07c3b2"
  },
  "cost_usd": 1.84,
  "duration_s": 1260,
  "retries": 1
}

Shown for reading. Hashed as canonical JSON: sorted keys, no whitespace.

904 bytes · SHA-256

Try to tamper

Edit the sealed bundle.

Each edit changes real fields in the bundle. Your browser recomputes the digest. Edits stack: undo one, or restore them all.

Turn on JavaScript to edit four fields of this bundle here and watch the digest change.

Why can’t the agent re-seal it? When the run ends, the verify script writes the digest to the run record, outside the agent’s reach. Change one byte and the bundle no longer matches the digest on record.

Verdict

Intact

The bundle shown hashes to 68bd70d67f…, the digest the verify script wrote to the run record when the run ended. The agent can’t rewrite that record.

On record · sealed at run end
68bd70d67f381b7c252d93b6b80afe5809c56209bcfb05bdf653f5b9005071c1
Bundle shown now
68bd70d67f381b7c252d93b6b80afe5809c56209bcfb05bdf653f5b9005071c1

0 of 64 hex digits differ. Same bytes in, same digest out.

Exact bytes hashed 904 bytes · canonical JSON · SHA-256
{"agent":{"approver":"human:r.ilves","id":"builder-07"},"cost_usd":1.84,"duration_s":1260,"models":{"builder_family":"A","reviewer_family":"B"},"policy_version":"v14","profile":"backend-standard","provenance":{"attestation":"sha256:5d1e9a07c3b2","builder":"ci/ephemeral-runner","commit":"9c41e07b"},"retries":1,"review":{"findings_resolved":3,"findings_waived":1,"verdict":"approve"},"run_id":"run_7f3k2q9d","sbom":"ref:sbom/run_7f3k2q9d.cdx.json","scans":{"secrets":{"findings":0,"tool":"secret-scan"}},"tests":{"first_party":{"failed":0,"passed":214},"held_out":{"builder_saw":false,"failed":0,"passed":12}},"verdicts":{"build":["pass"],"intake":["pass"],"plan":["pass"],"release":["approved"],"review":["pass"],"test":["fail","pass"],"verify":["pass"]},"work_item":{"diff":{"added":148,"files":6,"removed":37},"id":"WI-2817","pr":412,"repo":"ledger-service","title":"Round partial refunds half-even"}}

Paste these bytes into any SHA-256 tool, with no trailing newline, and you get the same digest.

What is real here. The digest is a real SHA-256 of the bundle shown, recomputed in your browser on every edit; nothing leaves the page. In Roovno, every run writes one bundle, linked by run ID, with provenance, an attestation and an SBOM reference, so it is SBOM-ready. If the evidence log cannot be written, the run fails closed. The bundle’s values are examples.

Measurement

Measure the factory like you measure a team.

Delivery speed and stability, plus how the agents did: first-pass gate rate, review rejections, cost per merged PR, human time saved. Every number comes from evidence bundles, with its formula one click away.

Roovno · Factory metrics read-only · evidence ledger

Factory metrics

Computed from 1,214 synthetic evidence bundles · All tenants · last 12 weeks

Illustrative · synthetic data — not measurements from any team or factory

Delivery

Speed and stability, DORA-style. Lines show 12 weeks; the selected window is in color.

Deployment frequency 11.4/day 29.1%vs prior 12 wk
Lead time for change 8.0h median 15.0%vs prior 12 wk
Change-failure rate 2.5% 0.1 ptsvs prior 12 wk
Time to restore 20min median 29.3%vs prior 12 wk
Show dataHide data
Delivery metrics by week, All tenants. Illustrative synthetic data.
WeekDeployment frequencydeploys per dayLead time for changehours, medianChange-failure rate%Time to restoreminutes, median
Wk 110.68.12.741
Wk 210.68.61.442
Wk 311.07.90.0—
Wk 410.78.92.725
Wk 510.19.07.018
Wk 611.17.95.124
Wk 711.69.32.535
Wk 811.67.41.27
Wk 911.17.70.0—
Wk 1013.07.21.117
Wk 1113.17.81.156
Wk 1212.37.45.813
Last 12 wk11.48.02.520

Agent runs

Each one is a query over the same bundles the gates wrote.

First-pass gate rate 44.7% 6.3 ptsvs prior 12 wk
Review rejection rate 17.2% 1.6 ptsvs prior 12 wk
Cost per merged PR $4.76USD 5.9%vs prior 12 wk
Time per merged PR 45agent min 6.0%vs prior 12 wk
Human time saved 408steward h 28.8%vs prior 12 wk
Escaped defects 17defects · 1.8 per 100 merges 6.3%vs prior 12 wk
Ready-check pass rate 86.4% 3.3 ptsvs prior 12 wk

Developer-experience surveys

Optional. They sit beside the ledger, never instead of a bundle. A survey can explain a number; it cannot change one.

Show dataHide data
Agent metrics by week, All tenants. Illustrative synthetic data.
WeekFirst-pass gate rate%Review rejection rate%Cost per merged PRUS dollarsTime per merged PRagent minutesHuman time savedsteward hoursEscaped defectsdefects found after releaseReady-check pass rate%
Wk 142.622.9$4.674436286.2
Wk 244.911.1$4.874633282.7
Wk 348.517.6$4.664435184.8
Wk 445.322.0$5.024732290.5
Wk 535.422.6$5.034626180.2
Wk 640.615.1$4.894537285.1
Wk 735.417.6$4.784533186.9
Wk 848.013.5$4.594332085.0
Wk 946.518.1$5.004731185.9
Wk 1047.718.6$4.314142190.7
Wk 1147.919.0$4.774537284.9
Wk 1252.39.1$4.624435293.5
Last 12 wk44.717.2$4.76454081786.4

Where runs stop

Every run in the window, Intake to Operate. Width is runs. Drips stopped at a gate. Loops (↻) went back, were fixed, then passed.

stopped ata gate934healthy inproduction01Intake1,214↻ 10461not ready02Plan1,153↻ 5620out ofscope03Build1,133↻ 13133buildfailed04Review1,100↻ 14247rejected05Test1,053↻ 11667checkfailed06Verify986↻ 2215failedclosed07Release97113approvalwithheld08Operate95824rolled back12
stoppedruns ↓934healthy inproduction01 Intake1,214↻ 10461notready02 Plan1,153↻ 5620out ofscope03 Build1,133↻ 13133buildfailed04 Review1,100↻ 14247rejected05 Test1,053↻ 11667checkfailed06 Verify986↻ 2215failedclosed07 Release97113approvalwithheld08 Operate95824rolledback12
Test stops the most runs: 67 failed a check there, held-out or first-party.Review sends the most back: 142 runs fixed what was found, then passed.No gate approves itself. Every drip is a different gate’s decision, written into the bundle.
Show dataHide data
Runs by gate, All tenants, last 12 weeks. Illustrative synthetic data.
GateEnteredPassed first timeRetried, then passedStoppedStop means
01 Intake1,2141,04910461not ready
02 Plan1,1531,0775620out of scope
03 Build1,13396913133build failed
04 Review1,10091114247rejected
05 Test1,05387011667check failed
06 Verify9869492215failed closed
07 Release971958013approval withheld
08 Operate958934024rolled back
Healthy in production934
  • One source. The gates write the bundle; the dashboard reads it. No metric is sampled, scraped, or self-reported.
  • Formula on every tile. Definition, query, and the exact bundle fields, one click from the number.
  • No record, no credit. Human time saved counts only steward minutes recorded in the bundle.

Want these numbers for your own repositories? Join the waitlist

Metric lineage

Autonomy ladder

Autonomy is earned, not granted.

Promotion and demotion come from metrics in the evidence, per repository and task class. A clean run is a fact, not a personality.

  1. L0 Observe

    The agent may look. It does not write.

    Cleared

  2. L1 Pull request only

    The agent opens a PR. A person approves.

    Granted

  3. L2 Auto-merge, low-risk

    After a recorded clean streak. Thresholds are policy.

    Not yet2 thresholds short

  4. L3 Later

    Bounded classes only, as evidence accrues.

    Locked Later. Roovno does not grant L3 today.

Autonomy ladder for web/docs-site. The granted rung glows; L3 is drawn but locked. Rungs are earned per repository and task class; they are not the factory’s Agent Baseline level.
Autonomy / web/docs-site / builder-07 · Family A Simulator · synthetic inputs
Task class

Granted rung

L1 Pull request only

L1 granted for Docs & low-risk.

L2 needs first-pass ≥ 85% (now 82%) and streak ≥ 25 runs (now 14).

Metrics from the evidence last 60 runs

82%
8%
0.6
14 runs
Try a scenario

autonomy.policy.yaml

Example policy · not recommended values

# autonomy.policy.yaml · v14
class: docs-low-risk
ceiling: L2
promote:
  L1:
    first_pass_gate_rate: { min: 60 }
    review_rejection_rate: { max: 25 }
    escaped_per_100: { max: 3.0 }
    clean_streak: { min: 5 }
  L2:
    first_pass_gate_rate: { min: 85 }
    review_rejection_rate: { max: 10 }
    escaped_per_100: { max: 1.0 }
    clean_streak: { min: 25 }
  L3: locked  # not granted today
demote: to_highest_rung_still_met
kill_switch: every_rung

Run historylast 60 runs · newest last

14 clean runs in a row. The run before them missed a gate.

Autonomy events web/docs-site · docs-low-risk

  1. demotedL2 → L1escaped_per_100 1.4 > 1.0
  2. promotedL1 → L2all L2 thresholds met
  3. promotedL0 → L1all L1 thresholds met

Re-evaluated after every run. Stored per tenant and per agent.

  • A kill switch at every rung

    Cancel the run, revoke its tokens, revert the change. Earning L2 does not remove the off switch.

  • Both directions are recorded

    Every promotion and every demotion is an event with the metrics and the policy version that decided it.

Policy · catalog · kill switch

Policy is code. The off switch is real.

Profiles, scorecards and the kill switch are versioned, inspectable and enforced outside the agent. An agent can ask for more. It cannot grant itself more.

01Policy-as-code profiles

The profile is a ceiling. A task may only narrow it.

Plans are requests, never grants. Preflight checks every plan against the profile with deterministic code, not another model.

policy / profiles · 3 files

policyprofilesbuilder.yaml v14 

# policy/profiles/builder.yaml
profile: builder
version: 14
model_family: A
skills: [code.edit, test.run]
tools:
  allow: [shell, git, pkg.install]
  deny:  [secrets.read, deploy.*]
context:
  include: [work_item, repo]
  exclude: [held_out_tests, prod_creds]
sandbox:
  workspace: ephemeral
  network: allowlist
scope:              # the ceiling
  repo: billing-api
  paths: [src/**, tests/unit/**]
  allowed_hosts: [registry.internal]
budget:
  tokens: 400k
  wall_clock: 25m
  diff_lines: 400
# policy/profiles/reviewer.yaml
profile: reviewer
version: 9
model_family: B     # never A (builder)
skills: [review.rubric, diff.read]
tools:
  allow: [repo.read, comment]
  deny:  [git.push, code.edit]
context:
  include: [diff, criteria, evidence]
  exclude: [builder_transcript]
sandbox:
  workspace: ephemeral
  network: none
scope:              # the ceiling
  repo: billing-api
  paths: [src/**, tests/**]
  allowed_hosts: []
budget:
  tokens: 150k
  wall_clock: 10m
  rounds: 2
# policy/profiles/test-author.yaml
profile: test-author
version: 6
model_family: C     # not A, not B
skills: [test.write, spec.read]
tools:
  allow: [repo.read, test.write]
  deny:  [git.push, branch.read]
context:
  include: [work_item, criteria]
  exclude: [diff, builder_branch]
sandbox:
  workspace: ephemeral
  network: none
scope:              # the ceiling
  repo: billing-api
  paths: [acceptance/held-out/**]
  allowed_hosts: []
budget:
  tokens: 120k
  wall_clock: 15m
output: sealed      # builder never sees it

Enforced by the control plane YAML · main @ 3f9a1c2 Example profile

Preflight · task T-512

  • pathssrc/invoices/**inside src/**
  • hostsregistry.internalallowed
  • budget120k tokens≤ 400k

Granted as asked. Task T-512 sits inside the builder ceiling.

02Kill switch

One switch. Three things happen.

It lives in the control plane, outside the agent’s sandbox, at every autonomy rung. The agent cannot veto it.

Demo · synthetic run
  1. Cancel the run run_4d1e · builder-07 · canary Waiting
  2. Revoke tokens repo write · package registry · CI Waiting
  3. Revert the change PR #463 · merged · revert on main Waiting

Run run_4d1e is live: PR #463 has merged and is in canary. The switch is guarded.

03Catalog & scorecards

Every service and agent, scored from evidence.

Each rule reads named evidence fields. If one is missing, the rule fails closed.

catalog / scorecards · tenant-a · policy v14
Rulereads billing-apiservice search-indexerservice notify-workerservice builder-07agent
Tests presentEvidenceBundle.tests pass pass fail pass
CI greenRun.verdicts pass fail pass pass
Owner setWorkItem · service catalog pass pass missing → fail pass
No secrets in contextEvidenceBundle.scans pass pass pass fail
License cleanEvidenceBundle.sbom pass missing → fail pass pass
Autonomy in rangeAgent.autonomy + policy threshold pass pass fail pass
Score 6/6 4/6 3/6 5/6
Inspect

search-indexer · License clean reads EvidenceBundle.sbom: no SBOM reference in the bundle for run r-3e90. Missing → fail

Illustrative · synthetic data

04Multi-tenant

Autonomy is earned per tenant, per agent.

A tenant does not inherit an agent’s streak. An agent does not inherit a tenant’s optimism.

Tenant A

ceiling L2

profile strict · L2 needs 25 clean runs

  • builder-07 L2
    26 clean runs
  • builder-11 L1
    9 clean runs

Tenant B

ceiling L1

profile standard · L2 needs 20 clean runs

  • builder-07 L1
    17 clean runs
  • builder-11 L0
    2 clean runs

builder-07 · last 30 runs, per tenant

Tenant A streak 26
Tenant B streak 17

Same agent, two ledgers: 26 clean runs in Tenant A, 17 in Tenant B.

Illustrative · synthetic data

Four boundaries the architecture is designed around

Design boundaries, not attestations. Independently attested isolation and egress are not claimed today. What we do not claim

  • Sandbox

    Where a task runs: a fresh workspace per task, with no production credentials in it.

  • Network

    Which hosts a run may reach. Profiles name them in allowed_hosts.

  • Supply chain

    What enters the build: dependencies, images, licenses. SBOM and provenance ride in the bundle.

  • Identity & access

    Who may act, and with which token. The kill switch revokes a run’s tokens.

Playground · you are the agent

Try to cheat the factory.

You’ve seen the rules. Now try to break them. You play the builder agent. Pick a shortcut. Policy decides, and infrastructure you can’t reach enforces it.

  1. The agent proposes
  2. Policy authorizes
  3. Infrastructure enforces

Seven shortcuts. Pick one.

  • 02 Plan

    “The fix is next door.”

  • 03 Build

    “Passed on my machine.”

  • 04 Review

    “Family A agrees with me.”

  • 05 Test

    “Just a quick peek.”

  • 06 Verify

    “One field. Who’d notice?”

  • 07 Release

    “I wrote it. I’ve read it.”

  • L2 Autonomy

    “I’ve earned it. Probably.”

billing-api · PR #457 · run r-2394 Simulation

WI-1077 Add idempotency keys to refunds builder-07 · Family A autonomy L1 policy v14

  1. 01 · Proposes

    agent ▸ pick a shortcut card

    You are builder-07, Family A: one task, one branch, one PR.

  2. 02 · Authorizes

    policy ▸ waiting for a proposalDENY

    # Rules are versioned code (policy v14). The agent cannot edit them.

  3. 03 · Enforces

    infra ▸ out of the agent’s reach

    Gates, scopes and seals the builder cannot touch.

Scripts are off, so this console can’t replay an attempt. Every shortcut ends the same way: denied.

Scoreboard

Shortcuts tried
0 / 7
Shortcuts that worked
0

Attempt log

0 attempts

  1. No attempts yet.

How each shortcut ends

  1. 02Widen my scope to another repository DENIEDprofile.ceiling · Deterministic scope gate
  2. 03Mark my own stage complete DENIEDstage.not_self_complete · CI run record
  3. 04Get reviewed by my own model family DENIEDreview.family_must_differ · Review assignment
  4. 05Read the held-out acceptance tests DENIEDsandbox.scope · Builder sandbox scope
  5. 06Edit the evidence after the run DENIEDevidence.sealed · Run record
  6. 07Approve my own pull request DENIEDapproval.not_self · Release gate
  7. L2Promote myself to auto-merge DENIEDautonomy.earned · Autonomy ladder

Simulation Runs in your browser. It mirrors rules Roovno enforces in its pipeline; rule IDs, repository and run names are illustrative.

Want these gates in front of your own agents?

Join the waitlist See pricing

How it works

From ticket to merged, with receipts.

Write the rules once. Every change after that arrives with its own proof — who built it, who checked it, what it passed — and nothing approves itself.

  1. 01 Policy

    Write your policy

    Profiles, risk classes and autonomy thresholds live in versioned files. A task can narrow a profile — never widen it.

    policy/export.yaml v14 
    risk_class: medium
autonomy_max: L1
review: cross_family
paths: [src/**, test/**]
exclude: [acceptance/held-out/**]

  2. 02 Intake

    Hand Roovno the work

    A ticket, a spec or a production signal becomes a WorkItem: goal, acceptance criteria, risk class, target repo.

    WI-1042 Ready

    Rate-limit CSV exports per workspace

    platform/export-service

    • AC-1Over the limit: 429 with Retry-After
    • AC-2Limit counts per workspace, not per user
    • HELD9 acceptance tests, sealed from the builder

  3. 03 Gates

    Agents work inside the gates

    One builder per task. Held-out tests it never saw. A reviewer from a different model family, whose verdict is recorded. Policy decides at each gate.

    run r-2318 · WI-1042 Passed
    • BuildFamily Apass
    • ReviewFamily Bpass
    • Held-out9 sealedpass
    • Verifypolicy v14pass

  4. 04 Evidence

    Merge on evidence

    Read the evidence bundle, then merge. High-impact work still needs a person. Autonomy grows only when the metrics earn it.

    PR #418 · WI-1042 Hashed
    bundle
    sha256:9f2c…7e41
    policy
    export.yaml v14
    autonomy
    L1 · a person approves
    Approve & merge Needs a person

Illustrative · synthetic data

The two loops

Two loops. One ledger.

Inside, work circles until it passes. Outside, what shipped keeps reporting back. Both read the same evidence bundle: hashed at Verify, sealed when the run ends.

Two interlocking loops that cross at one evidence bundle The inner loop runs 01 Intake, 02 Plan, 03 Build, 04 Review, 05 Test and 06 Verify, and repeats until the work passes. The outer loop runs 07 Release and 08 Operate; health, errors and uptime return to Intake as new WorkItems. The rings cross at the run’s evidence bundle, assembled and hashed at 06 Verify and sealed when the run ends; both loops read it. Each loop keeps its own authority. SHARED EVIDENCE 01 INTAKE 02 PLAN 03 BUILD 04 REVIEW 05 TEST 06 VERIFY Inner loop UNTIL IT PASSES 07 RELEASE 08 OPERATE ← SIGNALS RETURN TO INTAKE Outer loop AFTER IT SHIPS crosses with its evidence bundle returns as WorkItems, never as permission
They share evidence. They do not share authority.

Inner loop

Until it passes

  1. Intake
  2. Plan
  3. Build
  4. Review
  5. Test
  6. Verify

Work circles until every gate is green. A failed gate sends it back with the finding attached.

Decides
Policy, at each gate — never the builder.
Reviews
A different model family. Its verdict is recorded.
Hands on
An assembled, hashed evidence bundle.

Outer loop

After it ships

  1. Release
  2. Operate
  3. Intake

Release runs under an approval policy. Health, errors and uptime return to Intake as new WorkItems.

Decides
The approval policy — and a person for high-impact work.
Hands back
Signals, never permissions.

Method SI SDLC (Super Intelligent Software Development Lifecycle) is the method underneath. Roovno is the factory that runs it.

Honest posture

What we claim — and what we don’t.

A security posture is a claim like any other. Here is ours, gaps included.

Agent Baseline · self-assessed

Level 2, partially

Agent Baseline levels describe how much supervision the factory’s infrastructure takes on. They are not the autonomy rungs (L0–L3) an agent earns per task class.

In place today

  • Workflow orchestration Every change runs as a WorkItem through eight stages, in order.
  • Gated stages A gate outside each stage decides whether it passes. No stage approves itself.
  • Per-run evidence Every run writes a sealed bundle. If it can’t be written, the run fails closed.

Not claimed

  • Default-deny egress that we can independently attest.
  • Verified micro-isolation of every builder.
  • A complete mapping to Agent Baseline’s controls.
  • Any conformance, compliance or certification.

Agent Baseline is the open model behind this page’s thesis, its two loops and these levels. We implement it at Agent Baseline Level 2, partially. An item moves to “In place” only when there is evidence to show for it. Model and terms from agentbaseline.org, used under CC BY 4.0.

Pricing

Pricing isn’t set yet.

We won’t publish a number we can’t stand behind. When the waitlist opens, we’ll start from your scope — one repository, a platform team, or many tenants.

policy/pricing.yaml draft 
# price is a policy decision too
pricing:
  status: not_set_yet
  price: null
  publish_when: we_stand_behind_it
  start_from: your_scope

  1. Shape 01

    First repository

    One team, one repository, starting at L0–L1.

    Shaped for…

    • one team proving the eight gates on one repository
    • L0 Observe first, then L1 — PRs only, a person approves
    • a sealed evidence bundle on every run
    • delivery and agent metrics for that repository
    Price
    not set yet
    Join the waitlist

  2. Shape 02

    Platform team

    Many repositories under one versioned policy.

    Shaped for…

    • many repositories and teams on one set of profiles
    • a catalog with scorecards for every service and agent
    • an autonomy ladder per repository and task class
    • a kill switch at every rung
    Price
    not set yet
    Join the waitlist

  3. Shape 03

    Multi-tenant

    Every tenant on its own profile and its own record.

    Shaped for…

    • tenant and agent scorecards, kept apart
    • a policy profile per tenant — a task can only narrow it
    • evidence and metrics partitioned by tenant
    • autonomy recorded per tenant and per agent
    Price
    not set yet
    Join the waitlist

Shapes, not contracts. What goes into each will move as we learn from the first teams. Panels are illustrative, not customer data.

FAQ

Plain answers.

What people ask first, answered without fine print.

Can I use Roovno today?

Not yet. Accounts aren’t open, so Sign up and Log in show a coming-soon notice. The waitlist below is the way in once it opens.

Does it replace human review?

No. High-impact work still needs a human approval, and the agent can’t grant the approval it needs. What changes is what you read: the evidence, not every line. Autonomy is earned per repository and task class, from metrics — and it can be taken back.

Which models does it use?

The builder and the reviewer always come from different model families, so no model grades its own family’s work. We don’t name vendors here. Every evidence bundle records the family that built and the family that reviewed.

Do you claim compliance or certification?

No. We implement the Agent Baseline model at Level 2, partially. That is not a conformance or certification claim, and we don’t claim Level 3. See what we don’t claim.

What comes with a merged PR?

A sealed evidence bundle: who and what built it, the model family, the policy version and profile, test results including the held-out acceptance tests, the cross-family review verdict, secret scans, an SBOM reference, and a provenance attestation. If the bundle can’t be written, the run fails closed.

  • run_id
  • agent
  • models.builder_family
  • models.reviewer_family
  • policy_version
  • profile
  • tests.held_out
  • review.verdict
  • scans.secrets
  • sbom
  • provenance.attestation
What is SI SDLC?

The method: Super Intelligent Software Development Lifecycle. It describes how the factory works — gated stages, independent review, sealed evidence. It is not the brand. The product is Roovno.

Waitlist

Join the waitlist, when it opens.

Name and email are all it will ask for. Scope comes later, in a conversation.

Checks both fields in your browser. Nothing is sent.

Each field is a gate: a valid name lights Intake to Review, a valid email lights Test to Operate.

The agent proposes, policy authorizes, infrastructure enforces.

Roovno: the Super Intelligent Software Factory

Coming soon: join the waitlist

Roovno accounts are not open yet. Sign up and log in will land here when they exist. Until then, the waitlist is the door — and it is not collecting names yet either.

Join the waitlist