Evidence on every pull request:the spec we ship against.
Verify AI-written code without taking our word for it.
AI agents write the code on Steer by Pento, the platform we deliver every project on. This spec lists what every Steer pull request carries before it merges, who or what checks each part and where you read it.
What every pull request carries
- E1Acceptance-criteria traceTraced back to each criterion written with you
- E2Independent AI code reviewA different model from the one that wrote it
- E3Tests and logsThe test output itself, not a summary
- E4Visual evidenceAnything on screen, shown on screen
- E5CI, judgedA skipped job never counts as a pass
- E6Merge policy and risk classWho approves is set before work starts
- E7Audit trailEvery decision and every action recorded
What is an evidence report?
An evidence report is the record attached to every pull request Steer opens. It shows what was checked before the change could merge: each acceptance criterion marked confirmed or to fix by a review model that did not write the code, the review's verdict and findings, the tests that ran with their logs, screenshots of anything on screen, the judged CI result, and the merge policy that decided whether a person approves. A forward deployed engineer reads it, your team can open it from the same workspace, and it stays with the pull request after merge.
01Criteria
02Build
03Review
04Merge
05After merge
You
Agree the criteria before the goal is Ready
Approve what your merge policy gates
Read the audit trail from your Viewer seat
Forward deployed engineers
Write each goal's acceptance criteria with you
Steer the session while it runs
Read the verdict, the findings and the evidence
Steer + AI agents
A coding session writes it, runs tests, takes screenshots
Keeps every decision and approval on record
Review + checks
CI runs on the change, judged by a model
A different model checks each criterion
Policy decides: merge on evidence or ask a person
Verified once CI is green on the default branch
- 01Criteria
- YouAgree the criteria before the goal is Ready
- Forward deployed engineersWrite each goal's acceptance criteria with you
- 02Build
- Forward deployed engineersSteer the session while it runs
- Steer + AI agentsA coding session writes it, runs tests, takes screenshots
- Review + checksCI runs on the change, judged by a model
- 03Review
- Forward deployed engineersRead the verdict, the findings and the evidence
- Review + checksA different model checks each criterion
- 04Merge
- YouApprove what your merge policy gates
- Review + checksPolicy decides: merge on evidence or ask a person
- 05After merge
- YouRead the audit trail from your Viewer seat
- Steer + AI agentsKeeps every decision and approval on record
- Review + checksVerified once CI is green on the default branch
Findings go back to a coding session, and the change is reviewed again.
Evidence Spec v1 · October 2026
Seven clauses on every pull request.
Each clause names what is checked, who or what checks it, and what you read on the pull request, so you can verify AI-written code without taking our word for it. Clauses E4 and E5 apply only where they can: a change with nothing on screen has no screenshots, and a repository without CI has no CI run to judge.
Evidence SpecVersion 1October 2026Clauses E1–E7Every Steer project
- E1
Acceptance-criteria trace
Every goal carries acceptance criteria, written with you before the goal is Ready. The pull request is traced back to each one.
- What's checked
- Each acceptance criterion on the goal, one at a time, against the change set.
- Checked by
- The review model, then a Pento forward deployed engineer.
- On the pull request
- Each criterion marked confirmed or to fix, with the review it came from: review 11:05 · 2 of 3 confirmed.
- E2
Independent AI code review
The change set is reviewed by a different model from the one that wrote it, so the coder never grades its own work.
- What's checked
- Spec conformance, coding standards, security, tests and UX.
- Checked by
- A review session on a different model than the coding session, then a Pento forward deployed engineer.
- On the pull request
- A verdict (approve, approve_with_findings or request_changes) and every finding with its kind, severity (low, medium or high), file:line and the criterion it touches.
- E3
Tests and logs
The evidence includes the test output itself, with no summary standing in for it.
- What's checked
- Which tests ran in the session's sandbox, which failed, and on which lines.
- Checked by
- The coding session runs them; the review reads the log.
- On the pull request
- tests.log with its failing-line count (4 failing lines of 478). The session's brief.md and transcript.jsonl sit beside it in the workspace.
- E4
Visual evidence
If a change puts something on screen, the evidence shows it on screen.
- What's checked
- Each screen and state the change touches, against the acceptance criteria.
- Checked by
- The coding session captures them; the review model files ux findings and a forward deployed engineer looks.
- On the pull request
- Screenshots of each screen the change touches.
- Applies to
- Changes that render anything on screen.
- E5
CI, judged
A model reads every CI run and judges it, so a skipped job never counts as a pass.
- What's checked
- Each CI run on the change, and the run on the default branch after merge.
- Checked by
- A model judges each run: passed (proves the commit builds), failed (broken, or could not prove it is not) or ignore (replaced or skipped).
- On the pull request
- The judged result. A merged goal becomes Verified only when CI is green on the default branch.
- Applies to
- Repositories with CI.
- E6
Merge policy and risk class
Who approves a merge is set by policy before work starts, not by the agent that wrote the code.
- What's checked
- The change's risk class (Low, Data or External), the project's autonomy level, and how safe the review model rates the change to merge unattended.
- Checked by
- Steer's merge policy, set by the project's Owner. A change rated under 0.80 safe asks a person at every level.
- On the pull request
- A strip with all three: Risk class: External · sends through Postmark / Safe to merge unattended: 0.62 · below the 0.80 threshold / Autonomy: Autonomous · external risk asks.
- E7
Audit trail
Every decision Steer makes and every action a person takes is recorded.
- What's checked
- Each orchestrator decision: the project state it read, the question, the action, its probability, the model, the latency and the cost. Each person's approvals, answers and steering messages.
- Checked by
- Recorded automatically on every orchestrator turn and every person action.
- On the pull request
- The Audit view in the workspace, which your Viewer seat can read, with Export JSON.
E6 · Merge policy
Who approves a merge is decided before the code exists.
Every project has an autonomy level and every change has a risk class. Together they decide whether a change merges on its evidence, asks a person, or is only reported. Pick a level to see the same five changes land differently.
Risk class follows what the change touches
Low covers UI and logic inside the repository. Data covers migrations and stored data. External covers outside APIs, secrets, billing and deployment, such as sending email through Postmark.
The 0.80 rule holds at every level
The review model rates how safe each change is to merge unattended. A change it rates under 0.80 asks a person, even under Autonomous.
A policy merge still needs its evidence
A change merges by policy only on an approving review and, where your repository has CI, a passing run. The policy decides who signs off, not whether the checks run.
SteerMerge policy · acme / checkout-v2Illustrative
Changes waitingSafe to merge · min 0.80
- web #41Fix plan picker labelMergeRisk class Low · safe 0.96because low risk
- web #45Cart totals in EURMergeRisk class Low · safe 0.91because low risk
- api #18Index invoices by customerAsk a personRisk class Data · safe 0.88because data risk
- api #19Backfill invoice totalsAsk a personRisk class Data · safe 0.62because data risk
- web #44Receipt emails via PostmarkAsk a personRisk class External · safe 0.93because external risk
Gated: 2 merge3 ask a person0 report
Decisions
Models make the judgment calls; below 0.70, a person does.
After every event, Steer's orchestrator reads the project's state and decides the next action with an evaluation model. Each decision carries a probability. Under 0.70, Steer doesn't act: it asks a named person in their Needs you inbox instead.
- 01
Events in, decisions out
A Slack message, a finished session, a review verdict or a CI run wakes the orchestrator, and it answers one question: what happens next.
- 02
Low confidence goes to a person
Under 0.70 the decision becomes a question for someone specific, such as a merge for Dana Kim to approve, with the context she needs to decide.
- 03
Questions don't stall the project
Each question carries a default and a deadline, 48 hours unless you set another. If nobody answers, the default applies, and anyone can reopen it.
E7 · Audit trail
Every decision is on the record.
Each orchestrator decision is stored with the state it read, the question, the action, its probability, the model, the latency and the cost. Each person's action sits beside it. Your team reads the same record through the Viewer role and can export it as JSON.
A seat in the workspace from day one
The Viewer role shows progress, spend, speed and the record: Home, Goals, Changes, Numbers and Audit. You read the work itself.
People are on the record too
Approvals, answers to questions and steering messages are logged with who acted and when, next to the decisions they changed.
It exports
The trail exports as JSON, so your auditors or your own tools can read it.
Limits
What evidence proves, and what it doesn't.
An evidence report shows what was checked. It doesn't promise that nothing can break, and we don't claim it does.
Evidence shows
- Which acceptance criteria the review confirmed, and which it sent back to fix.
- Which tests ran, and the exact lines that failed.
- What the change looks like on screen.
- Whether CI proved the commit builds, and later that the default branch is green.
- Who approved the merge, or which policy did.
Evidence doesn't show
- That a test exists for a case nobody wrote down.
- That the acceptance criteria were the right ones to write.
- How the change behaves against production data or traffic it never saw.
- That nothing can break after merge.
The rules around the evidence
- Before work startsReady
Acceptance criteria are written with you before a goal is Ready.
- Data and outside systemsGated
Changes that touch data or outside systems still go to a person under Gated.
- Low confidence0.70
Any decision under 0.70 becomes a question instead of an action.
- After mergeVerified
A merged goal only counts as Verified once CI is green on the default branch.
FAQ
How to trust AI-generated code: the questions we get
Not covered here? Bring the question to a discovery call. An engineer reads every request.
Book a discovery callWe don't take it on trust. Every goal starts with acceptance criteria written with you, and every pull request comes back with an evidence report: each criterion marked confirmed or to fix by an independent review model, the tests that ran with their logs, screenshots of anything on screen, and the judged CI result. A forward deployed engineer reads that evidence, and the merge policy decides whether a person must also approve before it merges.
Two reviewers, in order. First a review session running on a different model from the one that wrote the code checks the change against the spec, coding standards, security, tests and UX, and posts a verdict with findings. Then a Pento forward deployed engineer reviews that evidence. Changes your merge policy gates also wait for a person with the Reviewer role, who can be someone on your team.
No. The review always runs on a different model from the coding session, so the model that wrote a change never grades it. When the review finds problems, a coding session fixes them and the change is reviewed again before it can move on.
Yes. Your team gets a seat in the same Steer workspace from day one. The Viewer role shows progress, spend, the goals, every change with its evidence report, the numbers and the audit trail. The code lives in your GitHub, so every pull request is also in your own repository.
Whatever your merge policy says. Under Gated, low-risk changes merge on their evidence and changes that touch data or reach external systems ask a person. At every autonomy level, a change the review model rates under 0.80 safe to merge asks a person, and any orchestrator decision under 0.70 becomes a question for a named person instead of an action.
A model judges every CI run as passed, failed or ignore. Passed means the run proves the commit builds. Failed means it is broken or could not prove it is not, so an unexplained red run counts as failed rather than as noise. A merged goal is only marked Verified once CI is green on the default branch.
No. Evidence shows what was checked: the criteria, the tests, the screens, the CI run and who approved. It can't cover a case nobody wrote down, which is why acceptance criteria are written with you and why changes that touch data or outside systems go to a person under Gated.
No. Your code, documents and content are used to build and run your software, never to train models. Each run happens in a fresh, isolated sandbox that is thrown away afterwards, with a short-lived git token that reaches only your project's repositories.
Contact us
Read the evidence on your next project
Bring a project you've been putting off. We scope it in a free audit and quote it in writing, as a monthly team or at a fixed price. Every pull request then ships with the evidence on this page. An engineer reads every request.