Requirement by requirement
The reviewer checks each requirement in the request against the delivery and states, for each one, whether it is met and what the proof is.
Deliverable: list of requirements with the proof for eachOcto for testing and review · reviewer arm
The delivery is checked by someone who didn't write it.
The NIST SSDF calls for code review, tool-based analysis and testing of the executable, as the organization defines. Octo's reviewer arm works at this step: it checks the delivery requirement by requirement against the request, tests through the real path with least privilege and delivers evidence, with the command and output or the screen. It runs without edit permissions. Approving the PR and merging belong to the tech lead.
ArmReviewerworks at this step, read-only
NIST SSDF 1.1PW.7 and PW.8review and testing
Sources5listed at the end of the page
01
What Octo does in review.
Four possible deliverables. Which findings to fix and when to approve are the tech lead's decisions.
Testing through the real path
Tests the way the user uses it, through the request or the screen, with the least-privileged role, and checks the content, not just the status code.
Deliverable: command and output, or screen, for each testIndependent reviewer
The reviewer runs in its own context, without having seen the conversation that produced the code, and with read-only tools.
Deliverable: a review not swayed by the author's reasoningWeighted findings
Separates what blocks the delivery from what is an improvement, so the team doesn't fix everything and fill the code with useless abstractions and tests.
Deliverable: findings sorted by severity
02
Eight arms, one verified delivery.
The same Octo cycle, applied to this step. Each arm has a narrow role; your company's tech lead is in charge and approves.
-
Discovery
Recalls the system
The platform map shows which way the real path goes.
-
Data
Checks the data
After the test, queries the database to see whether it saved what it should.
-
Security
Tests access
Least-privileged role, routes without checks, someone else's object.
-
Architecture
Provides the criterion
The requirements and the definition of done from the approved plan.
-
Development
Delivers the branch
The development arm doesn't review its own work.
-
Review
Reviews and tests
Requirement by requirement, through the real path, with evidence for each one.
-
Release
Waits for the review
Push and release only after the review is finished and whoever is in charge gives the OK.
-
Documentation
Records the findings
What was found, what was fixed and what was left for later.
Octo reviews and shows the proof; approving the PR, merging, deciding which findings to fix and giving final sign-off on the delivery belong to the tech lead.
03
Who does what in review.
What the reviewer delivers and what remains your team's decision.
| Step | Octo arm | Stays with the tech lead |
|---|---|---|
| Code review | Reviewer, read-only | Decide whether review is human, tool-based or both |
| Testing the executable | Reviewer | Decide what needs testing beyond review |
| Findings | Reviewer | Decide what to fix |
| PR approval | No arm | Approve and merge |
04
From request to routine.
Three steps. Each one only makes sense once the previous one has shown results on your team.
A proposal, not a promise
Review with evidence
Every delivery goes through the reviewer before the PR.
- Requirement by requirement
- Command and output, or screen
Least-privilege testing
The real path is now tested with the most restricted role.
- Least-privileged role
- Someone else's object
Rule in the repository
The protected branch now requires review and checks before merge.
- Required approval
- Required automated checks
05
Confirmed by source.
Each point below has a source published by the organization responsible for the standard, the specification or the tool, or in Brazilian federal law. The sources are in the next section.
8
points with a published source, each with its reference alongside.
- ConfirmedReview and analysis
- NIST SSDF practice PW.7 calls for determining whether code review, where a person looks at the code, and/or code analysis, by a tool, will be used, as the organization defines.Source: NIST, SP 800-218 (SSDF 1.1), PW.7
- ConfirmedTesting the executable
- Practice PW.8 calls for determining whether executable code should be tested to find vulnerabilities not found by earlier reviews, analysis or testing.Source: NIST, SP 800-218 (SSDF 1.1), PW.8
- ConfirmedLocal review that only reports
- Claude Code's local code review runs in a subagent with its own context; without the fix option, the instructions ask only for the report.Source: Claude Code, local code review
- ConfirmedIndependent reviewer
- A subagent that never saw the conversation reviews the diff without being swayed by the reasoning that produced the code.Source: Claude Code, best practices
- ConfirmedAsk for evidence
- "All tests pass", on its own, says very little.Source: Claude Code, best practices
- ConfirmedRead-only, enforced
- A reviewer limited to read-only tools has that limit enforced by the tool, not just requested in the prompt.Source: Claude Code, best practices
- ConfirmedNot every finding
- A reviewer asked to find problems will always find some; fixing everything produces useless abstractions and tests.Source: Claude Code, best practices
- ConfirmedApprovals before merge
- A protected branch on GitHub can require every pull request to receive a minimum number of approvals before merging.Source: GitHub, protected branches
06
What Octo does and what stays with you.
Octo prepares everything, but does not sign. The document of record stays with whoever is accountable for it.
Octo prepares
Maps, plans, codes on the task branch, reviews with evidence and prepares the release: plans, code, reviews, security reports and the system dossier.
Deliverable: material ready for reviewYour team reviews
Whoever is in charge is the company's tech lead or senior developer: they approve the plan, review the PR and merge it. Nothing goes to production without their approval.
Step: approval by whoever is in chargeWho signs and is accountable
Octo does not sign and is not accountable for the system. The tech lead accepts the risk and is accountable for the system in production; a security report or opinion is signed by a professional at the company.
Accountable: the company's tech lead
07
Sources.
NIST, Claude Code documentation and GitHub documentation. Accessed October 31, 2026.
- NIST: SP 800-218, SSDF 1.1 (February 2022)PW.7 and PW.8
- Claude Code: local code reviewSubagent with its own context; report without fixes
- Claude Code: best practicesIndependent reviewer, evidence and read-only
- GitHub: protected branchesApprovals and checks required before merge
- Pro Git: branching workflowsTopic branches make review easier
Every delivery with the proof attached.
The assessment starts with your team's next delivery, without changing anything. You get the review with evidence and decide with it in hand.