Every long-lived HLD accumulates internal contradictions: the diagram shows a queue the text never mentions, section 3 promises multi-AZ while section 7 assumes a single writer. Long-context consistency checking is a genuine LLM strength — the model finds the contradictions; the human decides which side of each one is true.
Tier: Core · Hands-on time: ~25 minutes
High-level designs are assembled documents — ADRs, diagrams, requirement registers, and prose written by different hands in different weeks — and assembly is where contradictions breed. A reviewer reading page 40 does not remember the claim on page 6; a long-context model holds both simultaneously, which makes cross-referencing every claim against every other claim tractable for the first time. The signature that stays human: the model reports that the document disagrees with itself, never which side is correct — resolving each contradiction requires knowing the design's intent, and only its authors have that.
Skip AI when the document is short enough that you genuinely have read every page against every other page this week — rare for real HLDs.
Assemble one context, deliberately. Concatenate the HLD, diagram sources, and key ADRs with clear source markers (=== HLD §3: Data Architecture ===). Include the requirements register if the HLD claims traceability to it. The markers matter: findings must cite locations you can open.
Run the contradiction sweep.
You are consistency-checking the Meridian Retail HLD before ARB
submission. The full document set follows, with === source markers.
Find INTERNAL CONTRADICTIONS only — places where the document set
disagrees with itself. Do not evaluate whether the design is good.
Check specifically:
1. Diagram vs text: components/edges in diagram sources that the
prose never mentions, and vice versa.
2. Claim vs claim: availability, consistency, scaling, security or
residency assertions in one section contradicted in another.
3. ADR vs HLD: decisions recorded in the ADRs that the HLD text or
diagrams violate or silently reverse.
4. Terminology drift: the same component under different names, or
one name used for two different things.
5. Requirement vs design: register entries the HLD claims to satisfy
but never addresses.
For each finding: FINDING-n, the two (or more) conflicting locations
with verbatim quotes, one sentence on why they cannot both be true,
and severity guess (blocking / significant / cosmetic) marked GUESS.
If two statements could be reconciled by a reasonable reading, list
under POSSIBLE TENSIONS, not contradictions.
###
[paste document set]
Confirm each contradiction is real. Open both cited locations and read them in context. Expect three classes: true contradictions (the valuable ones), resolved-by-context pairs (the model missed a qualifier — "multi-AZ for the database tier" vs "single instance" for a dev environment), and quote errors (rare with markers, fatal to trust — recheck the batch if found). Only the first class proceeds.
Resolve with the section owners — pick a side, then fix both. For each true contradiction, someone who owns the design decides which statement reflects intent, and the losing text is corrected everywhere it appears, including the diagram source. The tempting shortcut — softening one side until they no longer technically conflict — converts a visible contradiction into an ambiguity, which is strictly worse: build teams resolve ambiguities themselves, in whichever direction is convenient.
Fix terminology drift globally. Naming findings get a project glossary line and a find-and-replace, not a case-by-case debate. Two names for one component in an HLD becomes two components in the build team's understanding; Rajesh's Meridian draft called the same service "order-status agent" and "OSA bot" in different sections, and the client's reviewers had been reading them as two systems.
Re-run after the fixes. Corrections introduce contradictions too. A clean (or accepted-residual) second pass is the exit criterion, and its report files with the HLD as review evidence — the ARB pre-read can say "consistency-checked, n findings resolved," which is a sentence reviewers reward.
A complete HLD set is concentrated client-confidential material — often more sensitive than any single artifact in it. Run the sweep inside the approved boundary: client-tenancy endpoint (Bedrock/Azure OpenAI in their subscription) for engagement documents, enterprise tenancy for internal ones. Redaction is workable but costly here — consistency checking needs the real cross-references, and aggressive placeholder substitution can mask exactly the terminology drift you are hunting — so prefer moving the model inside the boundary over thinning the document. A local long-context model via Ollama handles medium HLDs; for very large sets, chunk into overlapping pairs of sections and accept the reduced cross-document coverage, or fall back to a human two-reader protocol with the model checking only within sections.
The model finds where the document disagrees with itself; the authors decide which side is the design. Resolve by picking truth, never by softening language — an ambiguity shipped is a contradiction delegated to the build team.