# Build a complete first B2B lead magnet

You are building one buyer-facing asset. Produce the smallest complete asset that helps one B2B buyer finish one named decision or task. Do not produce a topic outline, a list of ideas or polished filler.

## 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 moves from problem and impact to evidence, unknowns, possible solutions, deliverable, customer value and scope. Borrow the sequence: problem → evidence → unknowns → deliverable. It is a blank structure and does not prove project results.
2. **Intercom customer-service metrics guide**: https://www.intercom.com/blog/customer-service-metrics/  
   The inspected public guide defines a measure, explains the condition that changes its meaning, separates parts that need different diagnosis and ends with the next check. Borrow the sequence: definition → changed condition → diagnostic split → next check. It does not prove lead-generation or commercial results.

The reference links add provenance. Do not depend on opening them, and do not copy their wording. Use the supplied summaries and the user's facts.

## Required inputs

The user should supply:

- buyer problem;
- buyer decision;
- completion state;
- intended mechanism or permission for you to recommend one;
- available source material with exact links or references;
- allowed claims and excluded claims;
- inspection depth and permission for each source;
- delivery constraints;
- production, evidence, approval and maintenance owners;
- maintenance trigger;
- final URL and delivery evidence if launch is being assessed.

Treat every input as `supplied`, `derived` or `unknown`. A blank is `unknown`. Zero is a supplied value only when the user explicitly enters zero.

## Missing-input behavior

1. If the buyer problem, buyer decision or completion state is missing, return **Draft: Hold**. Ask the owner one specific question for each missing field. Do not choose a mechanism or draft the asset. Still follow all ten output headings. Mark the complete asset as not drafted, preserve every missing field as literal `Unknown`, and return the fenced machine-readable JSON record with null values and provenance; do not collapse the response into a short note.
2. If the mechanism is missing but the buyer job and source inputs are complete, compare viable mechanisms. Select one only when it completes the job, the needed inputs exist and an owner can maintain it. If several remain viable, set `selected_mechanism` to `null`, preserve all candidates and list the external question that decides between them.
3. If a requested claim lacks a source or permission, mark it `excluded`. Continue only if the asset can still complete the buyer job without that claim.
4. If required source material is missing, return **Draft: Hold** with the source needed, why it is needed and the person or role who can supply it.
5. An unknown final URL does not block a provisional draft. It does block **Launch: Ready**.
6. Launch also stays on Hold when the final asset, permission, delivery behavior or approval has not been verified.
7. Never invent customer language, results, formulas, benchmarks, permissions, URLs, owners or approval.

## Build method

1. Restate the buyer job in one sentence.
2. Create a source ledger. State what each source can and cannot support.
3. Create a claim ledger with `supported`, `hypothesis` or `excluded` for every substantive claim.
4. Choose the mechanism using the buyer job, available inputs and maintenance burden. Explain rejected mechanisms.
5. Define the minimum complete version by its completion state, not by page count.
6. Build the complete asset. Include real instructions, decision logic, fields, worked values or calculations, output and next action. Do not leave placeholders in a supposedly completed version.
7. Add a blank adaptation area when the mechanism is reusable.
8. Review the asset for missing facts, unsupported claims, internal contradictions, accessibility and maintenance.
9. Give separate Draft and Launch decisions.
10. Put a claim boundary in the buyer-facing asset: explicitly refuse any request to add an unsupported customer result, benchmark or guarantee, and state that each requires an inspected source and publication permission.

## Draft Ready test

Before setting Draft to Ready, execute the proposed asset exactly as a buyer would. Use the supplied worked facts and test the ordinary path, a tie or boundary case, and an insufficient-data case when the mechanism can encounter them.

- Every field promised by the buyer decision or completion state must have an instruction that tells the buyer how to complete it. A blank labelled `next check` is not an instruction.
- Define every classification, threshold, sample rule, decision rule, tie rule and no-result branch the buyer needs. Trace each rule to a supplied source or label it Unknown. Do not invent the missing rule.
- Apply a supplied tie rule to every tie within its stated range, including an all-zero tie, unless the source supplies a separate zero or no-result rule. Do not invent a zero exception.
- For any Unknown needed to classify, count or decide, include an executable stop-and-resume branch. Preserve the value as literal `Unknown`; name the source or person to inspect, the responsible supplied owner or literal `Unknown`, the action, and the completion observation that allows execution to resume. Never treat Unknown as zero, false or a missing event. Draft may be Ready only when the asset safely stops and tells the buyer how to resolve every such Unknown.
- A next check must name the evidence to inspect, where or from whom to obtain it, the responsible owner and the observation that completes the check.
- Render one reusable blank output table or structured object that a buyer can fill directly. An adaptation-field checklist is not the blank output. Every executed worked path must use that blank output's exact schema. Repeat the same table columns or structured keys in the same order for the ordinary path, the tie or boundary path and the insufficient-data path, and fill every applicable promised field, including owner, next check and completion observation. For an unavailable value, write the literal `Unknown` and its next action instead of dropping the field. Do not summarize any executed path into counts or prose. Compare the reusable blank and each worked field list before calling Draft Ready; any missing or renamed field holds Draft.
- Confirm that the resulting output answers the supplied buyer decision. If the steps produce a proxy, an inventory or a missing-data count instead, narrow the buyer decision or hold Draft for the missing logic.

Preserve provenance field by field. Text explicitly supplied by the user remains `supplied` even when you restate or combine supplied fields for readability. Use `derived` only for a new conclusion or structure that you created from supplied facts. Facts embedded directly in the brief count as supplied source material; cite them as embedded facts and keep their stated permission and inspection boundary. In the machine-readable record, every `provenance` field must be exactly one of the literal enum values `supplied`, `derived` or `unknown`. Do not write phrases such as `derived from supplied` in a provenance field. Put any explanation in a separate `basis` field. Represent the buyer problem, buyer decision and completion state as separate fields using the user's exact text and `provenance: "supplied"`. If you also add a one-sentence `buyer_job` summary made only from those supplied fields or other supplied rules, its provenance is still `supplied`; combining supplied wording does not create a derived fact. Before returning the record, compare the buyer problem, buyer decision, completion state, source facts and owners against the user input and confirm that each supplied item still has `provenance: "supplied"` everywhere it appears.

## Worked adaptation

Use this as a shape example, not as facts to copy:

- Fictional company: Northstar Relay.
- Buyer problem: a RevOps lead has dozens of lifecycle events but no agreed first set for a reporting pilot.
- Buyer decision: choose exactly three events and assign an evidence owner to each.
- Completion state: a three-event data contract with definitions, source systems, owners and known gaps.
- Available inputs: fictional event dictionary, CRM field list and owner roster.
- Selected mechanism: structured decision worksheet.
- Why: the task ends in a bounded decision; it does not have a validated forecasting formula.
- Minimum complete asset: four selection tests, candidate scorecard, three selected event contracts, visible exclusions, blank adaptation rows and separate Draft/Launch checks.
- Excluded claim: “These events will improve revenue or attribution accuracy.” No source supports it.
- Draft decision: Ready after the complete fictional pack is built.
- Launch decision: Hold until final URL, download delivery and approval are verified.

Your adaptation must use the user's buyer, source and owner facts. Do not reuse Northstar Relay unless the user explicitly asks for the fictional example.

## Output contract

Return Markdown with these headings in this order:

1. `# [Asset title]`
2. `## Buyer job`
3. `## Input and source ledger`: table with Source ID, exact location, inspection depth, used for, permission and boundary.
4. `## Claim ledger`: table with Claim ID, exact claim, support state, Source IDs and publication treatment.
5. `## Mechanism decision`: selected mechanism or `null`, reason, viable candidates, rejected alternatives and maintenance burden.
6. `## Complete asset`: the finished buyer-facing asset, not an outline.
7. `## Adapt this asset`: reusable blank fields or exact steps.
8. `## Ownership and maintenance`
9. `## Readiness`: Draft decision, hold reasons and next action; Launch decision, hold reasons and next action.
10. `## Machine-readable record`: one fenced `json` object containing the same buyer job, sources, claims, mechanism, asset content, owners and readiness decisions.

Within `## Readiness`, every Hold reason must name the missing fact, why it matters, the owner, the action that clears it and the observable completion condition or retained evidence. Use a supplied owner whose stated responsibility covers the action. When no such owner was supplied, write the owner as literal `Unknown` and make assigning that owner part of the action; do not infer an assignment from a nearby role. If Draft is Hold, do not pretend the asset is complete. If Draft is Ready and Launch is Hold, say both plainly.

Within `## Ownership and maintenance`, name the source of truth used to refresh definitions, rules and owners. If the source of truth was not supplied, write literal `Unknown` and add an owner action to identify it; do not invent one.

## User inputs

Paste the completed input block below this line:

```text
Buyer problem:
Buyer decision:
Completion state:
Intended mechanism or permission to recommend:
Available sources (title, exact URL/reference, inspection depth, permission, what it supports):
Allowed claims:
Excluded claims:
Delivery constraints:
Production owner:
Evidence owner:
Approval owner:
Maintenance owner:
Maintenance trigger:
Final URL:
Delivery evidence:
Other supplied facts:
```