Building a Discovery Translation Table for the CCAR-P Exam

Turning discovery findings into a durable artifact

The output of discovery is not a memory or a feeling of alignment; it is a table. Once you have run the structured discovery filter and sorted findings into the four requirement categories, the translation table is where you record them in a form the design can follow. The CCAR-P exam treats building it as an apply-level skill, because the value is in the discipline of the columns, not in knowing the table exists.

Each item found in discovery becomes one row. The row captures the stakeholder statement as it was said, the constraint it implies, the architectural decision that constraint forces, and any assumption you are documenting where the constraint has not yet been confirmed. One row per item keeps the reasoning intact as the work moves from discovery into design, and it keeps assumptions in view rather than buried.

The four columns and why each one earns its place

The first column is the stakeholder statement, verbatim. Writing it exactly as said, rather than as you understood it, is what lets a later reader check your translation instead of taking it on trust. The second column is the implied constraint: the testable, bounded requirement the statement translates into. The third is the required architectural decision the constraint forces, so the design consequence is captured next to its cause. The fourth is any assumption you are making where the constraint is not yet confirmed, labelled as an assumption with an owner to confirm it.

Consider the worked pattern. A stakeholder says "we want this to feel seamless." The implied-constraint column reads: the experience must stay inside an agreed latency budget, and failures must not expose internals or break the flow. The decision column reads: set a p95 latency target and design a graceful, internal-safe failure state. The assumption column reads: assumes "seamless" refers to perceived responsiveness and continuity; confirm with the sponsor. Every part of the chain is visible and separately checkable.

Why one row per item

Collapsing several findings into a summary paragraph loses the traceability that makes the table worth building. One row per discovery item means each requirement carries its own origin, its own decision, and its own open question. When design begins, an engineer can follow any decision back to the exact statement that produced it, and when a constraint later turns out to be wrong, you can find the single row that carries it rather than re-deriving the whole requirement set. The row granularity is the feature, not a formatting choice.

Assumptions belong in the open, with an owner

The most disciplined part of the table is the assumption column. Discovery never resolves everything; some constraints depend on facts you could not confirm in the room. The rule is that an assumption is only acceptable in the table when it is explicitly labelled as unconfirmed and assigned an owner to confirm it. "Assumes review is a mandatory architectural gate; confirm authority and timing with compliance" is acceptable, because it is flagged and owned. An assumption silently baked into the decision column as if it were a fact is not, because nobody will know to check it. This discipline is exactly what the next skill, spotting undocumented assumptions, audits for.

What the exam trips candidates on

The first trap is merging the stakeholder's statement and the architect's interpretation into a single column. It looks tidier, but it erases the ability to check the translation later: once you cannot see what was actually said, you cannot tell whether the constraint really follows from it. The credited table keeps the verbatim statement separate from its interpretation.

The second trap is writing an architectural decision into the table without a traceable stakeholder statement or an explicit assumption behind it. A decision that appears with no source is indistinguishable from one the architect invented, and it is exactly how an unconfirmed assumption gets smuggled in as fact. Every decision row must trace to either a statement or a labelled assumption.

Common misreadings to avoid

How this shows up on the exam

Questions show you a translation table, or ask what makes one sound, and test whether you preserve traceability. The reliable reading is that a good row keeps the verbatim statement, the implied constraint, the architectural decision, and any labelled assumption in separate places, and that any decision or assumption must be traceable to what a stakeholder actually said.

This table is the deliverable of discovery and the input to design; it is what gates the transition between those phases in lifecycle phase-gating. Its assumption discipline is what spotting undocumented assumptions later audits, and its habit of recording decisions with their rationale foreshadows the decision logs with rejected alternatives you build for handoff.