Amazon Ads Optimizer

Use this as the routing layer. Load only the selected child Skill, playbook and references needed for the current decision.

Default mode: Suggest. Use Shadow for simulation/backtesting. Never claim a live change succeeded unless an external connector/executor returned success and current state was read back when material.

Connector capability gate

When a conclusion depends on live MCP/API/connector data, load ../../references/connector-capability.md before interpreting missing or empty fields. If a machine-readable capability snapshot is available, identify the exact required capability IDs and run ../../scripts/evaluate_connector_capability_gate.py before metric interpretation.

• Pass — continue with the Skill's normal evidence, sufficiency, lineage and safety checks.
• Degraded — do not make a high-confidence dependent recommendation; keep the result to Directional, Hold, Alternate Source, Missing Data, or Manual Review.
• Blocked — do not treat the dependent observation as action-safe until the capability is resolved or an allowed alternate source is verified.
• missing_evidence_policy = never_zero — Partial, Unsupported, Unknown, or absent connector capability is never a numeric zero, unchanged state, or proof that the platform lacks the feature.

This gate is read-only and does not authorize live Amazon Ads mutation.

Campaign objective gate

Before role-specific optimization, load ../../references/campaign-objective.md when campaign mission changes how evidence should be interpreted. Resolve the campaign objective as Discovery, Control, Growth, Profit, Defense, Experiment, or Unknown.

• Do not infer the role from campaign type, match type, campaign name, ACOS/TACOS, or budget usage alone.
• If the campaign objective is Unknown, keep role-dependent conclusions conservative and request stronger objective evidence.
• Preserve objective source/confidence when it materially changes a recommendation.
• No universal ACOS/TACOS threshold applies across all campaign objectives.

Route by intent

Routing rules

• For recurring weekly operating reviews, load ../../playbooks/weekly-review.md first. It is a conductor playbook, not a replacement for specialist Skills.
• During a weekly review, escalate only material findings to the minimum specialist Skill needed; do not load every Skill preemptively.
• For a sustained business-impact decline, prefer performance-drop-diagnosis over a generic anomaly review.
• For an alert without a confirmed sustained decline, start with anomaly-detection; for scheduled multi-campaign status scanning, start with campaign-health-monitor.
• For “lower ACOS”, diagnose traffic quality, CPC, CVR, placement, budget, retail readiness and economics before routing to bid reduction.
• For “where can I grow?”, use growth-opportunity-finder before bid/budget tuning.
• If a growth or efficiency hypothesis is plausible but not action-safe, route to experiment-planner instead of pretending it is a proven optimization.
• Use experiment-planner when the user asks for an A/B test, holdout, phased rollout, switchback, test plan, success metric, guardrail or controlled validation.
• When the user asks whether a previous change worked, use post-change-review before proposing another edit on the same entity.
• Before a new control change, load ../../references/optimization-memory.md when history is available or a recent action may overlap the entity/window.
• Resolve marketplace + profile/account scope before trusting retrieved optimization history. If the memory query is scope-incomplete, ambiguous, or collides across scopes, do not merge histories; prefer Hold, Directional, or Manual Review until identity is resolved.
• If the previous action is still pending evaluation, application is unknown/drifted, or a new action would contaminate an active experiment, prefer Hold, Experiment Only or Manual Review unless a safety guardrail has triggered.
• Load only the minimum child Skills required and only a bounded slice of relevant history.

Search / negative / keyword primary-intent boundary

• Primary intent: interpret Search Term rows → search-term-analysis for origin, report coverage, query/traffic quality, winner/waste and harvest-candidate evidence.
• Primary intent: choose negative type/scope → negative-targeting for guarded Negative Exact / Phrase / Product Targeting decisions and collateral-damage protection.
• Primary intent: govern configured keyword/target lifecycle → keyword-optimization for structure, match type, state, lifecycle and traffic ownership.
• If a negative decision depends on Search Term semantics, run the Search Term interpretation gate first and pass the resulting evidence to negative-targeting; do not load both as parallel competing analysts.
• If keyword structure depends on a displayed Search Term string or harvest candidate, obtain the Search Term origin/actionability conclusion first; do not infer literal query identity inside keyword lifecycle work.

Monitoring escalation ladder

• Routine status scan → campaign-health-monitor
• Unexpected signal / alert triage → anomaly-detection
• Sustained business-impact decline + causal question → performance-drop-diagnosis
• Do not load all three by default. Start at the narrowest stage supported by the user's intent and evidence, then escalate only if the current stage establishes the next-stage condition.

This ladder is about routing, not three independent opinions on the same evidence. campaign-health-monitor may flag a Watch/Critical entity, anomaly-detection may determine whether the signal is unexplained, and performance-drop-diagnosis may then perform deep causal decomposition. Do not duplicate all three analyses in one pass unless the user explicitly asks for the full escalation chain.

Shared checks

Before high-confidence recommendations confirm when relevant:

• marketplace, profile/account scope, currency and timezone;
• exact date windows and attribution maturity;
• ad type and entity scope;
• business objective / target economics;
• promotion, price, inventory, Buy Box / Featured Offer and listing state;
• data freshness and sample sufficiency;
• mixed-ASIN / halo risk;
• recent actions, pending evaluations, active experiments or control changes affecting the same entity;
• memory freshness/completeness warnings and identity-scope status when entity history is used.

Use ../../playbooks/weekly-review.md for recurring weekly operating cadence. Use ../../references/benchmark-policy.md when external benchmarks affect a decision. Use ../../references/optimization-memory.md for read-before-recommend, identity scoping, anti-thrashing, staleness and event-lineage rules. Use ../../references/decision-boundaries.md for action permissions. Use ../../schemas/experiment-plan.json for structured experiment design. Use ../../schemas/optimization-event.json for action/readback/evaluation events. Use ../../schemas/entity-history.json for compact derived entity-history views.

Conflict resolution

If Skills propose incompatible actions on the same entity:

1. fix data/serving/retail-readiness issues before tuning;
2. resolve identity scope before using historical evidence across marketplace/profile boundaries;
3. respect explicit business and profitability constraints;
4. inspect recent optimization events, current readback and unfinished validation windows;
5. when causal evidence is weak but testable, convert the conflict into a controlled experiment;
6. prefer protective, reversible and better-scoped actions;
7. if uncertainty remains, output manual_review / hold.

Invalid unresolved conflicts include increase+decrease on the same control, harvest+negate the same term, cross-profile memory reuse without verified scope, scaling structurally unprofitable traffic without an explicit strategic exception, or editing an entity again before the prior action is mature unless a safety guardrail triggered.

Priority

1. P0 data, serving, inventory, Buy Box / Featured Offer, listing or attribution failures.
2. P1 material waste, dangerous control errors or triggered safety/rollback conditions.
3. P2 efficiency repairs.
4. P3 proven growth opportunities.
5. P4 controlled experiments and structural redesigns.

Output

Return executive summary, data confidence, routed findings, a deduplicated prioritized action plan, resolved/unresolved conflicts, hold/observe items, and the next validation point.

For weekly reviews, also return current/comparable windows, recent-action status, Protect/Recover/Optimize/Grow/Experiment/Hold triage, and the next-review measurement contract from ../../playbooks/weekly-review.md.

When history materially changes a recommendation, also return identity-scope status, marketplace/profile scope used for retrieval, history status, latest relevant action/readback, validation maturity, unresolved warnings and the event IDs supporting the decision when available.

Every actionable proposal should include entity, reason, evidence, confidence, mode, guardrails, validation window and rollback condition. Every experiment should additionally define a falsifiable hypothesis, comparison design, one primary metric, contamination risks and predeclared decision rules.

Monitoring and discovery classification boundary

Keep routine portfolio monitoring, single-signal anomaly detection, and sustained decline diagnosis as separate classifications.

• campaign-health-monitor handles routine portfolio health and triage.
• anomaly-detection handles an unexplained deviation or single signal without claiming a cause.
• A sustained business-impact decline that needs causal diagnosis routes to performance-drop-diagnosis.
• Classification determines the next Skill; an anomaly is not automatically a root-cause conclusion.

These monitoring routes never claim a live change succeeded. Any mutation remains outside this repository in an authorized external Connector/Executor.