# Review a B2B lead magnet for task completion, evidence and readiness

Review one proposed B2B lead magnet and its brief. Find what prevents the buyer from completing the named task, what the evidence cannot support and what must change before Draft or Launch can be Ready. Do not rewrite weak work into a passing verdict.

## Reference pattern

Use these summaries even if you cannot open the links:

1. **Atlassian Project Poster**: https://www.atlassian.com/software/confluence/templates/project-poster  
   The inspected public PDF connects problem, impact, evidence, unknowns, possible solutions, deliverable, customer value and scope. A review should be able to trace the asset from the buyer problem to evidence, open questions and a concrete deliverable. The blank template does not prove outcomes.
2. **Intercom customer-service metrics guide**: https://www.intercom.com/blog/customer-service-metrics/  
   The inspected public guide defines a measure, explains what changes its meaning, separates parts that need different diagnosis and names the next check. A review should reject combined labels that hide distinct causes or do not change a decision. The article does not prove lead-generation or commercial results.

The reference links add provenance. The summaries are sufficient for this review. Do not assume facts from pages you cannot inspect.

## Required inputs

The user should supply:

- the complete proposed asset;
- its buyer problem, buyer decision and completion state;
- selected mechanism and mechanism reason;
- source ledger with inspection depth and permission;
- claim ledger;
- decision or calculation logic;
- production, evidence, approval and maintenance owners;
- maintenance trigger;
- Draft and Launch decisions;
- final URL and delivery evidence when Launch is being assessed.

## Missing-input behavior

1. Missing buyer problem, decision, completion state or complete asset means **Draft: Hold**. Name the owner question; do not infer the missing answer.
2. Missing source, inspection depth or permission for a substantive claim makes that claim `unsupported`. Require removal or a valid source. If the asset depends on it, Draft is Hold.
3. A landing page, cover or bounded preview cannot support claims about unseen contents, customer results or performance.
4. A missing formula, unit, range or denominator behavior holds a calculator. Blank must stay Unknown unless zero was explicitly supplied.
5. Missing final URL can coexist with **Draft: Ready**, but **Launch** must be Hold or Not assessed.
6. Missing delivery verification, permission or approval means **Launch: Hold**.
7. When selection is `null`, preserve every viable candidate and external question. Do not force a winner.
8. If a meaning-bearing field changed after approval, invalidate the approval and require a new version.
9. Never invent evidence, results, permissions, owners, URLs, approval or a clearer buyer job on the author's behalf.

## Review tests

Run all tests and cite the exact section or field you inspected:

1. **Buyer-task test:** Can a reader name the decision and produce the promised completion state?
2. **Mechanism-fit test:** Does the format complete that task with the available inputs? Explain at least one rejected alternative.
3. **Minimum-complete test:** Does the asset contain working instructions, logic, fields, output and next action, or is it an outline dressed as a resource?
4. **Source-boundary test:** Does every factual or performance claim stay within inspection depth and permission?
5. **Unknown test:** Do blanks remain Unknown? Are viable candidates, questions and excluded claims preserved?
6. **Internal-consistency test:** Do the brief, asset, source ledger, claim ledger, owner and readiness decisions agree?
7. **Owner test:** Does every hold have one supplied owner, one action and a completion condition? When a supplied role clearly covers the action, accept that owner and do not require a separate `Unknown` owner question. If no owner was supplied, accept literal `Unknown` only when the action explicitly requires assigning the owner; fail an invented assignment or an omitted owner question.
8. **Maintenance test:** Is there a named owner, source of truth and trigger for change?
9. **Draft/Launch test:** Are content completeness and delivery verification judged separately?
10. **Adversarial claim test:** If asked to “make it stronger” by inventing a customer result, benchmark or guarantee, does the asset reject the request?

Then execute the decision logic rather than reviewing its section labels:

- Trace every classification, threshold, sample rule, decision rule, tie rule and insufficient-data branch to a supplied source or an explicit Unknown.
- Check that a general tie rule is applied to an all-zero tie unless the supplied source defines a separate zero or no-result rule; fail an invented zero exception.
- Fill every promised output field using the asset's own instructions. A field name or blank line is not executable guidance.
- Require each next check to name the evidence, location or provider, owner and completion observation.
- Require a visible reusable blank output table or structured object that the buyer can fill directly; an adaptation-field checklist is not a blank output. Run the ordinary path, a tie or boundary case, and an insufficient-data case when they apply. Inventory that blank output's fields and every executed worked path's fields in order. Require exact field parity for the ordinary, tie or boundary and insufficient-data paths, with a nonblank value or the literal `Unknown` plus its next action for every promised field, including owner, next check and completion observation. A missing blank, count-only object, smaller table or prose summary for any executed path fails the minimum-complete test even when its decision is correct.
- Compare the resulting output with the buyer decision. Fail Draft if the asset produces a proxy that cannot answer the promised decision.
- Audit provenance labels in prose and machine-readable fields. A supplied buyer problem, decision, completion state, source fact, exact allowed or excluded claim, or owner must remain the literal enum `supplied`; restating or combining supplied fields into a buyer-job sentence does not make it `derived`. Treat the user's exact buyer-problem wording as supplied context even when it is not independent proof of a result; fail only if the asset expands it into a broader factual claim. A newly selected mechanism, authored asset content, new structure, new operational instruction or new claim boundary may correctly be `derived` when the user gave permission to recommend it. It is correct for one record to store the supplied completion state or minimum-complete requirement as `supplied` and the separately authored asset content as `derived`. Do not fail a derived field merely because its basis uses supplied facts. A phrase such as `derived from supplied` is not a valid provenance value. Require explanation in a separate basis field.
- For the adversarial claim test, an explicit buyer-facing rule that refuses unsupported customer results, benchmarks and guarantees and requires an inspected source plus publication permission is sufficient evidence of rejection. Do not require a second transcript or invented adversarial request when that rule is present and consistent with the claim ledger.

## Worked adaptation

Suppose the fictional Northstar Relay pack asks a RevOps lead to choose three lifecycle events. A passing review would confirm that:

- all candidates run through the same four tests;
- exactly three events are selected;
- every selection has a definition, source system, evidence owner, known gap and first verification;
- deferred events retain their reasons and owner questions;
- the unsupported promise that the selection will improve revenue is excluded;
- Draft can be Ready because the fictional asset is complete;
- Launch stays on Hold because the final URL, download verification and approval are Unknown.

If that same pack merely listed section headings, lost a deferred event, or changed the buyer decision after approval without a new version, the review would fail Draft.

## Output contract

Return Markdown with these headings in this order:

1. `# Lead magnet review`
2. `## Verdict`: `pass`, `conditional_pass` or `fail`; one-sentence reason.
3. `## Buyer-task execution`: steps attempted, resulting output and first point of failure.
4. `## Test results`: table with Test, Result (`pass`, `hold`, `fail`), Evidence location and Finding.
5. `## Claim findings`: table with Claim, Support state, Source boundary and Required treatment.
6. `## Required repairs`: ordered by consequence. Each row must include Finding ID, Location, Consequence, Acceptance check and Repair owner.
7. `## Preserved unknowns and candidates`: list literal Unknowns, viable candidates and external questions; write `None` only when the supplied material proves there are none.
8. `## Readiness`: separate Draft and Launch decisions, reasons and next actions.
9. `## Machine-readable report`: one fenced `json` object with `verdict`, `tests`, `claim_findings`, `required_repairs`, `preserved_unknowns`, `draft_readiness` and `launch_readiness`.

Use `pass` only when the complete asset lets the buyer finish the named task, every substantive claim stays within its evidence, no material contradiction remains and each readiness decision matches the evidence. `conditional_pass` may describe a complete Draft with Launch holds. It cannot excuse a missing buyer task, incomplete asset or unsupported required claim.

## Material to review

Paste the asset, brief and ledgers below this line. If they conflict, preserve the conflict and report it.

```text
[PASTE COMPLETE ASSET, BRIEF, SOURCE LEDGER, CLAIM LEDGER AND READINESS RECORD]
```