How a recommendation is made

The four stages

1. 01

   Detection is deterministic

   Threshold breaches and window-over-window degradations are found by rules on normalized metrics. The model has no say in whether an issue exists.

   Issue detection is a deterministic layer: rules evaluate normalized metrics for threshold breaches, anomalies and window-over-window degradations, scoped to the ad account you have selected. Recommendations run downstream of that layer and consume its output. A model is never asked whether an alert exists, and it cannot create one.

2. 02

   Evidence is frozen

   A brief is bound to one alert and one authoritative evidence revision. Without that version the request is rejected rather than answered from unrelated live data.

   A recommendation is generated against one source alert or rule incident and one authoritative evidence revision, frozen at request time. If that frozen version is missing, the request is rejected. The alternative — quietly assembling fresh context from whatever the account looks like right now — would produce a brief whose reasoning no longer matches the evidence it cites.

3. 03

   Output is parsed strictly

   The response must match a canonical schema exactly, with no salvage, padding, aliasing or defaulted fields. Malformed output fails instead of being repaired into something plausible.

   The model's response is parsed against a canonical schema. The parser performs no fallback, padding, salvage, alias coercion or semantic defaulting, and it rejects duplicate keys and non-finite numbers outright. A response that does not conform raises a structured parse failure instead of being coerced into a valid-looking brief. You see an error, not a repaired guess.

4. 04

   Actions stay advisory

   Every item is safety-classified before you see it. A model that marks its own suggestion executable is downgraded to manual review.

   Each item is then classified for execution safety. Items start as insight; unsupported-claim guards catch language implying work was already carried out; audience and placement edits are flagged as sensitive. An item the model labelled an executable candidate is downgraded to manual review. Nothing in a brief changes your ad account on its own — applying a recommendation is a separate, human step.

What the system will not do

• Let the model decide that a problem exists. Detection stays in the deterministic layer.
• Answer from unrelated live context when the frozen evidence revision is missing.
• Repair, pad or salvage a malformed model response into a usable brief.
• Let a model promote its own suggestion to executable.
• Treat free text in a brief as authorization to change anything. Handoffs carry explicit, scoped fields or they are rejected.

Limits worth knowing

• Recommendations are downstream of detection. If no rule fired, there is no brief — this is not a continuous autonomous auditor of everything in the account.
• A brief belongs to the ad account, not to the person who generated it. Everyone authorized on that account sees the same active generation and the same result.
• Only the latest published brief for a source alert is shown. Earlier versions are not surfaced in the product.
• Regeneration is restricted to account owners; only the person who started a generation can cancel it.