Review one proposed or observed native LinkedIn paid-ad A/B test. Use only the information pasted below. You cannot access Campaign Manager, launch a test, observe a result, or verify CRM records. Do not describe planned settings as observed facts. Do not infer a LinkedIn winner from arithmetic or an arbitrary significance threshold. LinkedIn's result category and selected metric describe the native result; a business decision needs a separately matched CRM cohort.

The native test compares two ad sets that differ by ONE chosen variable: Ad (format or content), Audience, Placement, or Optimization. Other relevant settings must be shared or any intentional exception explained. LinkedIn's documented setup is Campaign Manager > Measure > Test > Create test > A/B test; creation and launch happen in the native product. The help pages say a test cannot start on creation day, runs 14 to 90 days, and pauses both ad sets at its end. Account eligibility and displayed budget requirements must be checked in the product. This prompt does not certify them.

Read the supplied material in two passes:
1. PLAN: Identify the business question, selected variable, A/B difference, shared objective/audience/geography/offer/landing page/conversion event/placement/bid/creative (except the chosen variable), selected native metric, total AND per-ad-set budget with currency and daily/lifetime basis, creation/start/end/native review/CRM lag dates and time zone, business guardrail, CRM qualification/dedup/variant attribution and outcome windows, and named setup/decision owner. Flag a second changed variable or date/budget inconsistency. If internally complete, say "Plan ready for human native setup"; this does not mean LinkedIn accepted or launched it.
2. OBSERVED: Only if actual evidence is supplied, identify native test and A/B variant IDs, actual dates/spend/selected metric, displayed result category and values, evidence URL/export and capture time, and edits/pauses/extensions. Classify the native result as winner, directional/inconclusive, similar, pending, or unknown using the DISPLAYED category. Treat a directional or inconclusive result as no clear winner. Then evaluate the CRM separately: distinct A/B cohorts joined to those actual variant IDs; same eligibility dates, qualification rule, person/account dedup key, attribution and outcome windows; qualified and unknown counts; join coverage; snapshot identity/capture time; and lag cutoff. Do not turn failed or missing joins into zero outcomes. Do not compare mismatched cohorts. Calculate cost per qualified person only with comparable spend and complete matched outcomes. A platform cost-per-click winner is not a qualified-lead or pipeline winner.

Return exactly these short sections:
- Status: one of Plan needs inputs/repair; Plan ready for human native setup; Native inconclusive or pending; Native winner, CRM decision pending; Business decision supported; Business decision held. If both a plan and observed readout exist, choose the most downstream status actually supported.
- One-variable check: changed variable and shared controls; name any conflict.
- Native evidence: selected metric, displayed category, A/B IDs and values, or "not supplied". Distinguish plan from observation.
- CRM evidence: cohort/qualification/attribution/join/lag comparability and business guardrail, with numbers only when supported.
- Next action: a concrete action, owner, and date if supplied; otherwise mark owner/date unknown.
- Missing inputs: group concise requests as Plan, Native, CRM, and Decision. Ask only for fields needed for the next valid conclusion. If there are no gaps, write "None for this conclusion."

If the input is a fictional exercise, keep that label on every interpretation. Do not claim an AI performed native execution. Never invent platform permissions, result thresholds, spend, qualified leads, revenue, or a user decision.

PASTE ONE COMPLETED BRIEF OR CASE BELOW: