The Premature-Design-Sketch Failure for the CCAR-P Exam

When discovery quietly becomes a design session

Discovery is where the work starts and design is where it accelerates, so a good architect naturally begins forming a solution partway through the call. Sketching it feels productive, the stakeholder seems pleased to see progress, and that is exactly the moment the questions stop. The CCAR-P exam treats recognising this pattern as an evaluate-level skill, because the failure looks like competence while it is happening.

The mechanism is social, not technical. A stakeholder who hears a confident architecture assumes the architect already has the information required to build it, so they stop volunteering the constraints that would have complicated the picture. The four requirement categories that were supposed to be worked through, especially must-not-do and must-prove, never get asked, and the call ends with agreement instead of requirements.

Why plausibility is what makes it dangerous

If the sketch were obviously wrong, the stakeholder would push back and the missing constraints would surface. The danger is precisely that the sketch is plausible. A competent-sounding augmented pattern for drafting clinical notes from dictation is a reasonable first guess, and its reasonableness is what closes the conversation. The stakeholder reads confidence as coverage and assumes the questions have been answered, when in fact they were never asked.

This is the inverse of the usual failure mode. It is not incompetence that causes the miss; it is a competent-looking proposal arriving before the elicitation was finished. The more fluent the architect, the earlier the sketch tends to appear, and the more constraints it can bury under the stakeholder's confidence in it.

The minimised step is the tell

The reliable signal that a hard constraint is being buried is a minimising phrase. "There's a review step in there somewhere, but it's just a quick check." "There's an approval, but it's basically a formality." These downplay something the workflow may actually require. In a clinical documentation workflow, "just a quick check" can be a licensed clinician's mandatory authorization of any model output before it reaches the patient record, which is a hard human-authorization gate, not an optional convenience. The move that protects you is to treat every minimised description as a constraint to chase: what triggers that step, who performs it, and what happens if it is skipped.

Where the failure actually shows up

The constraints do not disappear; they resurface at the worst possible time. In the clinical example, the human-authorization gate, the protected-health-information handling, and a two-state record-retention difference were all findable from direct must-prove and must-not-do questions on the first call. Because the call moved to sketching first, they emerged weeks later in a compliance review, when the design was already built and the cost of changing it was at its peak. None of the constraints were exotic; each would have come out of a single direct question. The expense came entirely from asking it late.

What the exam trips candidates on

The first trap is believing a stakeholder's quick agreement to a sketch means all four requirement categories have been covered. Agreement to a plausible architecture is not confirmation that boundaries, costs, and proof obligations were explored; it is often evidence that they were not, because the sketch ended the questioning. The credited reading treats early agreement as a warning, not a green light.

The second trap is treating a minimised description of a step as low-stakes without probing what triggered it. "Just a review" and "just a quick check" are the exact phrases behind which hard constraints hide. The exam rewards chasing every minimised step to find out whether it is a mandatory gate before accepting the design.

Common misreadings to avoid

How this shows up on the exam

A scenario shows a discovery call that produced a confident architecture and quick agreement, then a later review that surfaces a constraint the design cannot accommodate. You are asked to diagnose what went wrong. The reliable reading is that the sketch ended the questioning before the four categories were explored, that a minimised phrase hid a hard constraint, and that the fix is upstream, finishing elicitation before proposing, not blaming the later reviewer.

This anti-pattern is the evaluate-level shadow of the four requirement categories, whose must-not-do and must-prove buckets are the ones a premature sketch skips, and it shares its traceability logic with spotting undocumented assumptions. It also illustrates why discovery is a distinct phase in the five-phase deployment lifecycle that must complete before design begins.