# Lead magnet production brief: worked fictional example

This brief produces the fictional **Three-Event Reporting Pilot Decision Pack**. It contains no customer result, forecast or live destination.

## Identity and version

- **Asset ID:** northstar-relay-three-event-pilot
- **Version:** 1.0
- **Working title:** Three-Event Reporting Pilot Decision Pack
- **Fictional:** true
- **Supersedes asset/version:** None
- **Approval ID:** Unknown

Any change to the buyer job, completion state, source boundary, allowed claims or mechanism requires a new version and approval ID.

## Buyer job and mechanism

- **Buyer problem:** A RevOps lead has dozens of lifecycle events but no agreed first set for a reporting pilot.
- **Buyer decision:** Choose exactly three lifecycle events for the first reporting model and assign an evidence owner to each.
- **Completion state:** A three-event data contract with inclusion reasons, definitions, owners and known gaps.
- **Selected mechanism:** structured decision worksheet
- **Mechanism reason:** The task ends in a bounded team decision. The source inputs are definitions and ownership records, not a validated forecasting model.
- **Minimum complete version:** A four-test selection rule, completed fictional scorecard, three-event contract, blank adaptation table and readiness checklist.
- **Constraints:** Works as plain Markdown; no proprietary software; all tables must remain understandable in linear reading order.

## Source ledger

| Source ID | Title | URL or private reference | Inspection depth | Used for | Permission | Notes |
| --- | --- | --- | --- | --- | --- | --- |
| S1 | Atlassian Project Poster | https://www.atlassian.com/software/confluence/templates/project-poster | full_interior | Problem → evidence → unknowns → deliverable sequence | public | Structure only; no outcome claim |
| S2 | Intercom customer-service metrics guide | https://www.intercom.com/blog/customer-service-metrics/ | full_interior | Separating combined measures into diagnosable parts and next checks | public | Editorial guidance; no lead-performance claim |
| S3 | Northstar Relay fixture | Embedded fictional record in this packet | full_interior | Event names, definitions, owners and gaps | approved | Fictional example only; replace before real use |

## Claim ledger

| Claim ID | Claim | Support state | Source IDs | Publication treatment |
| --- | --- | --- | --- | --- |
| C1 | The pack helps a team record a three-event decision, definitions, owners and gaps. | supported | S3 | Publish as observable asset function |
| C2 | The pack follows a problem, evidence, unknowns and deliverable sequence. | supported | S1, S3 | Publish with attribution to the reference pattern |
| C3 | The selected events will improve revenue or attribution accuracy. | excluded | None | Do not publish |
| C4 | Northstar Relay is a real customer. | excluded | None | State that it is fictional |

## Section contract

| Section ID | Reader question | Required input | Output or decision | Source/claim IDs | Acceptance check |
| --- | --- | --- | --- | --- | --- |
| A1 | Which events can enter the pilot? | Candidate events, definitions, source systems and owners | Pass, Hold or Exclude for every event | S3, C1 | No candidate disappears and every Hold names a question |
| A2 | Which three events are selected? | Passed events plus four decision tests | Exactly three selected events and exclusion reasons | S3, C1 | Three rows marked selected; rejected rows retain reasons |
| A3 | What does each event mean? | Selected events | Data contract with definition, source, owner and gap | S3, C1 | Every selected event has all four fields or literal Unknown |
| A4 | Can the draft or launch proceed? | Completed pack and delivery evidence | Separate Draft and Launch decisions | S3 | Draft Ready can coexist with Launch Hold |

## Decision or calculation logic

For each candidate event, answer four tests:

1. **Decision link:** Will this event change a named reporting or operating decision?
2. **Stable definition:** Can the team define the event without relying on an unstated interpretation?
3. **Observable source:** Does a named system currently record it?
4. **Evidence owner:** Does a named role own the definition and resolve gaps?

Pass requires `yes` on all four tests. `unknown` produces Hold and a named owner question. `no` produces Exclude with the reason. If more than three events pass, prefer the three that cover distinct stages and have the fewest unresolved dependencies; record the excluded passed events. This is a prioritization rule, not a revenue or attribution-accuracy model.

## Design and delivery requirements

- **Formats:** Markdown and JSON with an exact embedded JSON round trip.
- **Reading order:** Instructions → test → candidate scorecard → selected contract → adaptation table → readiness.
- **Tables or diagrams:** Tables use explicit column headings and preserve meaning when read row by row.
- **Download filename:** minimum-useful-lead-magnet.md and minimum-useful-lead-magnet.json
- **Final URL:** Unknown
- **Delivery test:** Download both files, extract the Markdown `lead-magnet-json` fence and compare its UTF-8 bytes plus trailing newline with the JSON file.

## Ownership and maintenance

- **Production owner:** Content Producer
- **Evidence owner:** Revenue Operations Manager
- **Approval owner:** Head of Revenue Operations
- **Maintenance owner:** Revenue Operations Manager
- **Review cadence:** Quarterly and whenever CRM stages or event instrumentation change
- **Update trigger:** A selected event's definition, source system or owner changes
- **Source of truth:** Approved event dictionary and the versioned asset record

## Review fixtures

| Fixture | Expected result |
| --- | --- |
| Complete supplied inputs | Complete three-event pack; Draft Ready; Launch Hold while URL and delivery proof are Unknown |
| Missing buyer decision | Draft Hold; ask Head of Revenue Operations for the decision the pack must produce |
| Unsupported performance claim | Exclude it; do not add a result or benchmark |
| Source is preview only | Describe only the visible preview; do not claim hidden fields or use results |
| Meaning-bearing field changes after approval | Invalidate approval ID and create version 1.1 or later |
| Final URL Unknown but draft inputs complete | Draft Ready; Launch Hold |

## Readiness

- **Draft decision:** ready
- **Draft hold reasons:** None for the fictional asset.
- **Draft next action:** Content Producer renders both formats and runs the byte-exact round-trip check.
- **Launch decision:** hold
- **Launch hold reasons:** Final URL, delivery verification and approval ID are Unknown.
- **Launch next action:** Publisher assigns the destination, verifies both downloads and records Head of Revenue Operations approval.