A piece of work is rarely one agent doing one thing. A specialist reviewer fires because the change itself is risky, not because someone remembered to ask for it. A project lead sits over the work and pulls the right specialist in when the shape of the change calls for one. Here is that composition, on a single worked example rather than an abstract list of roles.
Say the work is a marketing banner inside an app heading for the App Store. On its face it is a feature: some copy, a link, a bit of layout. But a promotional surface inside a shipping app is exactly the kind of thing App Review scrutinises, so the change carries a risk that has nothing to do with whether the code is correct. Watch how the review composes with the build.
The banner is built like any other feature: the copy, the link, the layout. Nothing about the build step announces that this is a submission-sensitive change. That is the point: the risk lives in what the change touches, not in how it is written.
The surface being touched, a promotional banner in a shipping app, is one the App Store reviewer watches for. So it fires. Not because a checklist step said to run it, and not at the end as a gate, but alongside the feature work, the moment the risky surface is in play.
The reviewer reads the change against the specific App Review guideline it engages and returns one of three verdicts, citing the rule rather than a vague worry:
The change is within the guideline. Ship it.
A specific point needs adjusting before it is safe. Named, with the rule it engages.
As written, this would be rejected. Do not ship until it is resolved.
An aligned banner ships. An attention or blocker verdict feeds straight back into the feature work: the copy is reworded, the claim is dropped, the layout is changed, and the reviewer runs again on the revision. The submission risk is caught while the change is still cheap to alter, not at the store's front door.
The important word above is trigger. A specialist is not a manual step someone has to remember at the right moment, which is the surest thing to forget under time pressure. It is keyed to a kind of change. Touch a submission-sensitive surface and the App Store reviewer fires. Add code that collects user data and the licensing and privacy reviewer fires. Write user-facing copy that should exist in Welsh and the Welsh reviewer fires. The work does not have to know which reviewers exist; the change summons them.
Each specialist owns one lane and stays in it. It cites the specific rule or framework it is judging against, returns a verdict, and suggests the fix, but it does not edit the work itself. That separation is deliberate: a reviewer that also rewrote the code would be marking its own homework.
Fires on submission-sensitive surfaces: promotional copy, entitlements, purchase flows, third-party SDKs. Cites the App Review guideline in play.
Fires on new data collection, a new dependency that touches user data, or privacy-facing configuration. Cites the framework, and names the point that would need counsel if any.
Fires when code needs policing against the house engineering rules. Returns each finding tagged as a mechanical fix or a judgment call, so the fix can be routed cleanly.
Fires on user-facing copy that should exist in Welsh alongside English. Flags missing counterparts, wooden translations, and register mismatches.
Above the specialists sits a project lead: a read-only gate that judges whether a change fits the product before it is filed, merged, or shipped. The lead is not another specialist. It owns the judgments no single reviewer makes, whether the change serves the project's scope, whether the release is actually ready, and crucially, whether the right specialists were even consulted.
The lead does not re-run the App Store reviewer's analysis or re-judge the Welsh. It confirms those reviewers ran and reads their verdicts as inputs to its own. An aligned verdict from every specialist that should have fired is part of what release-ready means; a missing one is a gap the lead is there to catch.
The lead's sharper move is proactive. Partway through the banner work it notices the change also adds a new analytics SDK, and it pulls in the licensing and privacy reviewer that the feature work never thought to summon. The lead does not do that review; it routes to the specialist who does. It names who should look, and hands off.
So a single change flows through layers that each know their job: the feature work builds, the triggered specialists judge their lanes and return verdicts, and the lead composes those verdicts and pulls in any specialist the change quietly needs. No one holds the whole picture in their head, because the composition holds it for them.