SAFE
Definition: The PR has minimal risk factors. Changes are well-isolated, don’t introduce hidden assumptions, and have adequate validation.What This Means
- The code changes don’t depend on uncertain assumptions
- Potential failure modes are either handled or highly unlikely
- Test coverage is adequate for the changes
- No obvious gaps in validation or error handling
How to Respond
- Read the analysis to understand Factor’s reasoning
- Verify you agree with the assessment
- Merge with confidence
What It Does NOT Mean
- The code is perfect
- There are no bugs in the PR
- Code review isn’t needed
- All edge cases are handled
When You See SAFE
This verdict is common for:- Simple, isolated changes (e.g., adding a utility function)
- Refactoring with no behavior change
- Display-only changes
- Well-tested feature additions
REVIEW_REQUIRED
Definition: The PR introduces risk factors that require human judgment. These might be assumptions, missing tests, failure modes, or business logic that depends on your context.What This Means
- Factor has identified something that deserves attention
- The risk might or might not be acceptable (context-dependent)
- A human needs to make a judgment call
- Additional validation, testing, or coordination might be needed
How to Respond
- Read Factor’s findings: Understand exactly what it identified
- Answer the questions: Address any merge blockers Factor raised
- Verify scenarios: Confirm failure scenarios are handled or acceptable
- Add tests if needed: For critical paths, add the tests Factor suggested
- Coordinate: Talk to dependent teams if there are hidden impacts
- Make a decision: Decide if the risk is acceptable
What It Does NOT Mean
- The PR is unsafe
- You can’t merge it
- Factor is telling you to reject it
When You See REVIEW_REQUIRED
This verdict is common for:- New business logic (financial calculations, authorization)
- External integrations (APIs, services)
- Async operations (background jobs)
- Database changes
- Complex state mutations