How HoldUp fits into engineering review.
A simple model for connecting your existing decisions to every pull request without adopting a new spec framework.
1. Keep your current sources of truth
HoldUp is designed around the documents teams already maintain: Markdown specs, ADRs, OpenAPI or GraphQL contracts, tickets, and engineering notes.
2. Map context to code
Each decision or contract should be connected to the repositories, services, or paths it governs. That relationship is what lets a review check stay narrow instead of comparing every PR against every document.
3. Check the pull request
When a PR opens or updates, HoldUp reads the diff plus relevant context and looks for contradictions, changed assumptions, removed constraints, and behavior that no longer matches the written intent.
4. Return evidence
A useful finding needs four parts: the source, the conflicting code, the reason, and the likely impact. The reviewer should be able to decide whether the code is wrong or the documentation is stale.
5. Make drift explicit
If the implementation is intentionally changing a decision, update the decision. If it is accidental, fix the code. Either way, the PR should not quietly become the new source of truth.
What HoldUp should not do
- Replace unit tests, static analysis, security scans, or code review.
- Invent architecture rules that were never recorded.
- Block every ambiguous change by default.
- Force teams into a proprietary spec format.