Early pilot

Hold up.
Your code passed CI.
Did it follow the spec?

AI coding agents can write code that works while quietly changing what your team actually agreed to build. HoldUp checks pull requests against your specs, requirements, API contracts, and engineering decisions before merge.

No new spec framework. No workflow migration. HoldUp sits on top of the context and CI you already use.
payments-service / pull / 1842
3 files changed
! HoldUp found spec drift
Needs review
src/checkout.ts
async function applyCoupon(order) {
-  validateCoupon(order.coupon)
-  authorizePayment(order.total)
+  authorizePayment(order.total)
+  validateCoupon(order.coupon)
}
! Conflicts with checkout-spec.md
Spec: coupon eligibility must be validated before payment authorization.
PR: payment is authorized first. Tests may still pass, but the agreed behavior has changed.

Review the intent, not just the output.

HoldUp gives reviewers a clear reason, source, and possible downstream impact instead of another generic AI comment.

SourceSpec + ADR
SignalPR diff
ResultAligned / drift
WorkflowGitHub + CI
The gap

Tests tell you whether the code works. HoldUp checks whether it is what you meant to ship.

The decisions behind a change are spread across specs, ADRs, tickets, contracts, and docs. AI agents move through implementation faster than reviewers can reconstruct all of that context.

Traditional CI

Does the code work?

Compile, lint, test, scan, deploy. These checks validate the implementation itself.

HoldUp

Did we build what we agreed on?

Compare the PR against requirements, contracts, and engineering decisions that were supposed to guide it.

Examples

Spec drift is bigger than one bad line of code.

Scroll through examples of the kinds of mismatches HoldUp is designed to surface.

Payments

Validate before charging

The spec requires validation before authorization. The implementation reverses the order.

SPEC: validate → authorize
PR: authorize → validate
API

Required becomes optional

A downstream team assumes a field is always present, but a PR quietly makes it nullable.

OpenAPI: customer_id required
PR: customer_id?: string
Security

Auth moves layers

An ADR says authorization stays in the gateway. A service starts enforcing it itself.

ADR-014: auth in gateway
PR: authorize() in orders-service
Data

Retention rule changes

The code works, but data now lives longer than a documented retention decision allows.

Policy: delete after 30d
PR: ttl = 90d
Events

Message contract drifts

An event producer renames a field without updating the contract used by consumers.

contract: order_total
PR: amount_total
Retries

Side effect becomes unsafe

A retryable handler adds a non-idempotent call despite an architecture note requiring idempotency.

ADR: retries must be idempotent
PR: chargeCard() on every retry
How it fits

A check inside the workflow you already have.

HoldUp is not another place to write specs. It connects the context you already maintain to the code that is about to merge.

Diagram showing specs, ADRs, API contracts, tickets and docs feeding HoldUp, which returns either aligned or possible drift.
MarkdownADRsOpenAPIGraphQLOpenSpecSpec KitGitHubCI/CD
Dependency awareness

See what a conflicting change could touch before it ships.

A drift finding matters more when reviewers can see the downstream systems and decisions that depend on it.

Dependency graph showing a coupon service linked to checkout, payment, promotions, ledger and orders.
What reviewers get

Enough context to make a decision.

Show the decision HoldUp is checking.

Point back to the spec, ADR, contract, or requirement instead of leaving reviewers with an unexplained model opinion.

Using coding agents heavily? We want to hear where this breaks.

HoldUp is early. We are talking with engineering teams to understand where spec drift actually shows up and what a useful PR check should look like.

Join the pilot