The standard intake question across most engagements is some variant of: here is how we want to show up — can you make the AI describe us this way? The brief is usually well-written. It is also the wrong starting point.
This note explains why, and what we ask for instead.
The brief is downstream of three earlier choices
A visibility brief is the surface artifact of three decisions that already happened, often without being written down:
- Who the offer is for. The brief assumes a customer profile. The profile is rarely tested against the customers the operator actually closes. The two often diverge.
- What the offer is. The brief assumes a clean, single description of the service. Most operators, on inspection, have two or three offers running concurrently and a brief that selects one of them as the “real” one.
- What the proof is. The brief asserts authority. The proof for that assertion lives elsewhere — case studies, methodology pages, third-party references. The brief and the proof are not always aligned.
When we work the brief directly, we are working downstream of three unverified assumptions. Whatever ships propagates those assumptions into AI surfaces, and the operator now has the same misalignment as before, but indexed at higher quality.
What we ask for instead
We ask for two things before the brief becomes operational:
- A short customer-truth check. Three to five recent customers — not testimonials, just descriptions of who they were and what they bought. This usually surfaces the gap between the brief’s assumed customer and the actual one within an afternoon.
- A canonical-statement test. One paragraph describing the offer, run against an AI assistant, audited for what the model adds, drops, or misreads. This surfaces the gap between the brief’s offer description and what is actually parseable.
Both are cheap. Both reliably catch a problem the brief alone cannot expose. The architecture review then operates on a corrected starting point.
When the brief is right
There are operators whose brief is already aligned with the underlying decisions — usually because they have already done the work, in another form, for another reason. In those cases the architecture review is faster and the deliverables are closer to implementation. That is fine.
The point is that we cannot tell whether the brief is right by reading the brief. We have to test the layer underneath first.