Code can be correct and still be wrong.
These are the kinds of mismatches HoldUp is designed to surface before merge.
Order of operations
Requirement says validate before charging. Implementation charges first.
actual: charge → validate
API nullability
A field documented as required becomes optional in code.
code: customer_id?: string
Architecture boundary
An ADR places auth in the gateway, but a service starts authorizing locally.
code: service.authorize()
Retry safety
A retryable job adds a non-idempotent side effect.
code: chargeCard() each attempt
Data retention
A PR increases retention beyond a documented limit.
code: ttl = 90 days
Event contract
A producer renames a field without updating the shared event contract.
code: amount_total
Feature flag behavior
A feature marked internal-only becomes active for all users.
code: defaultEnabled = true
Timeout assumption
A service timeout exceeds a downstream SLA documented in an ADR.
code: timeout = 10_000
Permission model
A role is granted write access where the requirement only allows read.
code: viewer = read|write
HoldUp is not trying to guess whether code is “good.”
It asks a narrower question: does this implementation still match the engineering intent the team already recorded?