Early pilot

Every code change.
Every decision checked.

Your engineering decisions live across specs, ADRs, tickets, API contracts, database schemas, docs, rules, and other repositories. HoldUp checks every pull request against the decisions that govern it before the code merges.

No new spec framework. No workflow migration. Evidence for every finding.
payments-service / pull / 1842
3 files changed
! Decision violation
Blocking
src/checkout.ts
async function applyCoupon(order) {
-  validateCoupon(order.coupon)
-  authorizePayment(order.total)
+  authorizePayment(order.total)
+  validateCoupon(order.coupon)
}
! Violates PAY-017
Decision: coupon eligibility must be validated before payment authorization.
Evidence: Product Spec §4.3 · Checkout Architecture §Payments
Affected: checkout-api · payments-service · mobile-client

Know whether a change is allowed before it merges.

HoldUp resolves the decisions that apply, cites where they came from, and shows why the changed code conflicts.

Decisions checked17
Contracts checked3
Conflicts1
ConfidenceHigh
The gap

The code can pass every check and still violate what your company decided.

Current reviewers can read more context. The harder problem is deciding which source governs the change when rules are scattered, stale, or contradictory.

Traditional CI

Does the code work?

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

HoldUp

Is this change consistent with what we decided?

Resolve the effective decisions, compare them with the PR, and make contradictions explicit.

Three findings

No style comments. No generic AI noise.

HoldUp stays focused on the decisions a pull request can break, contradict, or introduce.

Decision violation

Existing decision contradicted

The PR changes behavior that an approved product, architecture, data, API, or security decision requires.

PAY-017: validate → authorize
PR: authorize → validate
Decision conflict

Sources of truth disagree

A ticket, ADR, repo rule, or contract gives the team incompatible instructions. HoldUp asks for a resolution.

ADR-042: use PaymentService
Ticket: call Stripe directly
Undocumented decision

New system behavior introduced

The PR creates a meaningful dependency or policy with no recorded owner, constraint, or approval.

new: persistent user cache
missing: TTL · owner · PII rule
Decision graph

One versioned decision plane across the tools you already use.

HoldUp connects company knowledge to the code it governs, resolves authority and conflicts, then checks each PR against a baseline it cannot rewrite.

Diagram showing company knowledge and pull requests feeding the HoldUp Decision Graph, which identifies violations, conflicts, and undocumented decisions.
AGENTS.mdCLAUDE.mdADRsOpenSpecDriveJira / LinearOpenAPIDB schemasOther reposGraphify
Dependency awareness

See which systems and decisions a change puts at risk.

Every finding includes the source, conflicting code, and likely blast radius so the reviewer can verify it instead of trusting a black-box opinion.

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 effective decision and its authority.

Point to the exact source, owner, approval state, effective date, and superseded decisions instead of leaving reviewers with an unexplained model opinion.

Give us one PR and the decisions it should have followed.

We will map the governing context and show where HoldUp would flag a violation, conflict, or undocumented decision.

Run HoldUp on a PR