I start an architecture review by separating a referenced claim from an assumption. The following examples are fictional and illustrate that method; they are not drawn from customer documents.
Somewhere around the middle, there's a sentence like this:
"Authentication and access control are handled by the platform."
That sentence is doing an enormous amount of work, and nobody is checking whether it can lift the weight.
Two sentences that look identical
Compare these:
"Access control is inherited from Platform X, as described in document Y, section 4.2."
"The platform handles access control."
They read like the same claim at different levels of politeness. They are not the same claim. They are opposites.
The first one is inheritance. There's a name, a reference, a section number. You can go get document Y, read section 4.2, and check three things: that the control exists, that it does what this dossier thinks it does, and that it actually covers this system and not just the platform's own components. Someone can be wrong here — the reference might be stale, the control might not extend to this use case — and that's exactly what makes it reviewable. A claim you can falsify is a claim you can audit.
The second one is an assumption dressed as inheritance. There's no reference to follow, no control to verify, no document where the claim lives. Nobody owns it. The application team believes the platform team handles it; the platform team has never heard of this application. On paper, nothing is wrong — which is precisely the problem, because nothing is checkable either.
I've started calling the second kind a gap wearing inheritance's clothes. It has the shape of a control. It has the vocabulary of a control. What it doesn't have is anyone on the other end.
Where these gaps go to wait
Assumed controls don't blow up during review. That's what makes them dangerous — review is the one moment everyone is looking, and an assumption reads fine when you're skimming.
A possible consequence is a later review in which nobody can establish who owned the check:
"We thought that was covered."
Not "we decided to accept that risk." Not "we checked and were wrong." We thought. The gap was never anyone's decision — it was a handoff both sides believed the other had caught.
The question, and why it needs no product knowledge
So this is the first thing I ask of any architecture document, before I care what the system does or what it runs on:
For every security claim: is this named, or assumed? And what does it sit on?
That's it. You don't need to know the platform. You don't need to have administered the product. You're not evaluating whether the control is good — you're evaluating whether the control exists as a claim someone can be held to. A junior reviewer can apply this on day one, and it will embarrass documents written by twenty-year veterans.
In practice it turns into a short checklist:
- Does the document name the platform, service, or team providing each inherited control?
- Does it reference where that control is described — a document, not a vibe?
- Does the referenced control actually cover this system, or just the provider's own perimeter?
- Is there any claim resting on "handled by," "managed by," or "provided by" — with no noun behind it?
Anything that fails the last check goes on a list, and that list is usually the review.
The AI clause
I said this works on any architecture document. Right now there's one place it earns its keep more than anywhere else: AI vendor documentation.
"The model provider handles data security" is the 2026 version of "the platform handles authentication." It shows up in integration designs, procurement memos, DPIAs — carrying an entire compliance story on its back, mostly unexamined. Handles it where? Under which agreement — the consumer terms or the enterprise DPA? Does "no training on your data" cover the logs? The subprocessors? The retention window? I pulled that particular thread apart in what OpenAI's DPA actually says.
The same question applies to installed tools: can you see what the application touches? I describe one incident on my own laptop, not a finding about every installation.
Named, or assumed?
If the document can answer with a reference, you have an architecture. If it answers with confidence, you have a hope.
And hope, in a dossier, is easy to spot once you know its uniform: it's the sentence with no name in it.
A named reference makes the claim checkable. It still needs verification.
Questions people ask about architecture review
What is the difference between an inherited control and an assumed one? An inherited control names the provider, references where it is described, and points at a section you can go and read. An assumed one says "handled by the platform" with no noun behind it — the same shape, with nobody on the other end.
Why do assumed controls survive review? Because they read perfectly well when you are skimming. A later review may find that nobody established who owned the check. That is different from an explicitly assessed and accepted risk.
Can a reviewer apply this without knowing the platform? Yes, and that is the point. You are not judging whether the control is good, only whether it exists as a claim someone can be held to. Four checks: is the provider named, is the description referenced, does it cover this system, and is anything resting on "handled by" with no noun.
How does this apply to AI vendors? "The model provider handles data security" is the current version of the same sentence. Ask under which agreement, whether the no-training commitment covers logs and subprocessors, and what the retention window really is.