Sales asset format

This format defines the canonical source for market playbooks and the call sheets generated from them. Markdown provides context for people. Fenced YAML blocks contain most records that software may read. Audience bindings are the exception: each binding is a standalone YAML file with a generated Markdown profile beside it.

The source hierarchy is:

Persona definitions
  -> Markets
    -> Market verticals
      -> ICPs
      -> Market-persona bindings
      -> Audience bindings
        -> Competitors
        -> Problems
          -> Solutions
            -> Proof
        -> Q&A
          -> Generated call sheets

An account or contact may specialize a generated call sheet, but it must not create a market problem, persona responsibility, capability, or proof claim.

Storage model

Use the sales content structure and authoring workflows for incremental problem, solution, proof, and evidence authoring. Store each problem, solution, proof, and evidence record as one canonical record per file in its corresponding content directory. Store audience-specific selection, priority, impact framing, and call language in one standalone audience-binding YAML file. Generate its human-readable Markdown profile with the audience-enrichment workflow. The profile is a projection and never becomes a second source of truth.

Keep shared enums, personas, markets, and the vertical index in their existing catalogs. Keep canonical competitor profiles in competitors/. A competitor, problem, or solution is stored once; audience bindings decide applicability through immutable references. Problems and solutions declare no vertical scope. Multiple audience bindings may refer to the same record.

Unreviewed call analyses and seller contributions enter through content/inbox/. They do not become canonical until manual review creates or updates an owning record.

Generated call sheets live under content/generated/. They record their source IDs and source version but do not become sources for a market playbook.

Format rules

• YAML blocks are authoritative when prose and structured data disagree.
• A standalone audience YAML file is authoritative over its enriched Markdown profile. To change an audience, edit the YAML and rerun enrichment; never recover configuration from the profile.
• Every YAML block declares a kind and schema_version. Parsers use kind to distinguish catalogs, specifications, and generated artifacts.
• One record owns each fact. Other records refer to it by ID.
• IDs are immutable after publication. Retire a record instead of reusing its ID for a different meaning.
• Dates use YYYY-MM-DD.
• Required prose values must be complete sentences. Do not leave generation instructions such as "write an opener" in an approved record.
• A YAML null means unknown. An empty list means reviewed and none found.
• Every hypothesis is labeled as a hypothesis and rendered as a question.
• Every external or customer-derived claim includes an evidence reference.
• Lists are ordered intentionally. A generator preserves their order unless a generation rule says otherwise.
• Tables are human-readable indexes. They must contain the same IDs and status as their corresponding YAML records.

ID conventions

Record	Pattern	Example
Persona	P<number>	P1
Market	M<number>	M1
Vertical	<market>_V<number>	M1_V2
ICP	<vertical>_ICP<number>	M1_V2_ICP1
Problem	P_<nnnnn>	P_00001
Solution	S_<nnnnn>	S_00001
Proof	PF_<scope>_<nnn>	PF_MULTI_001
Q&A	QA_<vertical>_<nnn>	QA_M1_V2_001
Evidence	EV_<scope>_<nnn>	EV_M1_V2_001
Competitor	C_<nnnnn>_<NAME>	C_00001_GLOBAL_SHOP
Generated call card	CC_<vertical>_<persona>	CC_M1_V2_P1

Use uppercase IDs and underscores. Problem and solution IDs use a zero-padded, five-digit sequence and are not scoped to a vertical. Competitor IDs use the same five-digit sequence followed by a stable uppercase name slug. IDs identify records; display names remain editable.

For proof IDs, <scope> is the sole vertical ID when vertical_ids contains one value and MULTI when it contains more than one. The ID is only an immutable locator; the complete, authoritative scope always comes from the proof's vertical_ids array.

Controlled values

kind: enum_catalog
schema_version: 1
enums:
  document_status:
    - draft
    - review
    - approved
    - deprecated
    - archived
  operating_status:
    - planned
    - testing
    - parallel
    - active
    - paused
    - retired
  confidence:
    - low
    - medium
    - high
  statement_type:
    - market_fact
    - product_fact
    - market_hypothesis
    - persona_hypothesis
    - account_fact
    - founder_instinct
    - ai_inferred
    - expert_fact
    - buyer_confirmed_fact
    - unknown
  capability_classification:
    - native
    - configured
    - integrated
    - roadmap
    - unavailable
  evidence_type:
    - primary_source
    - public_source
    - customer_artifact
    - buyer_interview
    - call_learning
    - internal_validation
  transaction_roles:
    - stakeholder
    - champion
    - economic_buyer
    - decision_maker
    - technical_evaluator
    - user
    - adviser
    - investor
  proof_transfer_level:
    - direct
    - conditional
    - prohibited
  naologic_product:
    - SKU1
    - SKU2
    - CUSTOM
    - BUILDER

Persona definitions

Define reusable business functions here. This is the master list, not the list of personas for every market. A vertical opts into a persona explicitly in its market-persona bindings.

Persona ID	Name	Description
P1	<persona name>	<role-independent description>

kind: persona_catalog
schema_version: 1
personas:
  - id: P1
    name: '<canonical persona name rooted in job function name. Eg: CEO, CFO, Comptroller>'
    function: '<stable business function>'
    common_titles:
      - '<representative title>'
    description: '<what this function is generally accountable for>'
    status: approved

common_titles supports contact matching; a title alone does not prove authority, motivation, ownership, or transaction role. Define expected transaction roles in the vertical's market-persona binding. Record the confirmed role for a specific opportunity in its account or contact data.

Markets

A market is a top-level go-to-market motion. Priority belongs to the market. Industry or process specificity belongs to a vertical.

Market ID	Name	Operating status
M1	<market name>	planned

kind: market_catalog
schema_version: 1
markets:
  - id: M1
    name: '<market name>'
    operating_status: planned
    priority: 1
    description: '<the motion and the boundary around it>'
    product_narrative: '<what the buyer purchases and why>'
    owner: sales
    confidence: low
    naologic_product:
      - <naologic_products, one or more>

Market verticals

A vertical is the smallest reusable market unit expected to share operating physics, ICP criteria, problems, persona jobs, proof, and call language.

Vertical ID	Market ID	Name	Operating status	Personas	NAICS codes	Proof-transfer rules
M1_V1	M1	<vertical name>	planned	P1	<code>	conditional

kind: vertical_catalog
schema_version: 1
verticals:
  - id: M1_V1
    market_id: M1
    name: '<vertical name>'
    operating_status: planned
    priority: 1
    persona_ids:
      - P1
    naics:
      version: 2022
      codes:
        - code: '<2-6 digit NAICS code>'
          label: '<official NAICS label>'
          scope_note: '<included operating subset or null>'
    proof_transfer_rules:
      - from_vertical_id: M1_V2
        level: conditional
        reusable:
          - '<proof element that transfers>'
        non_transferable:
          - '<vertical-specific behavior that does not transfer>'
        required_validation:
          - '<test required before the proof may be used>'
        rationale: '<why this boundary exists>'
    owner: sales
    confidence: low
    evidence_ids: []

persona_ids is a membership constraint, not permission to combine every persona with every problem. Those combinations are defined in the market-persona bindings below.

Vertical name — M1_V1

Write a short narrative that lets a reader recognize the vertical and understand why it has its own playbook.

Definition

kind: vertical_profile
schema_version: 1
vertical_profile:
  vertical_id: M1_V1
  description: '<what establishments in this vertical do>'
  inclusion_boundary: '<what must be true to be included>'
  exclusion_boundary: '<lookalikes that are out of scope>'
  products_they_make:
    - '<what they make>'
  customers_they_sell_to:
    - '<who they sell to>'
  sales_motion:
    - '<how they sell>'
  commercial_mos:
    - '<SKUs, custom projects, combination>'
  manufacturing_modes:
    - '<MTO, MTS, ETO, CTO, DS>'
  operating_physics:
    - id: OP1
      statement: '<sourced characteristic that shapes the work>'
      statement_type: market_fact
      evidence_ids:
        - EV_M1_V1_001
  systems_context:
    incumbent_categories:
      - '<ERP, CRM, spreadsheets, point solution, or other category>'
    change_triggers:
      - '<observable event that may create a reason to evaluate>'

Ideal customer profiles

An ICP defines account-level structural fit. It does not claim that a matching account has a particular problem.

Use ISO 3166-1 alpha-3 values for country and ISO 3166-2 values for subdivisions. For example, Texas is represented as country: USA with subdivisions: [US-TX].

ICP ID	Name	Priority	Status
M1_V1_ICP1	<ICP name>	1	approved

kind: icp_catalog
schema_version: 1
icps:
  - id: M1_V1_ICP1
    vertical_id: M1_V1
    name: '<ICP name>'
    priority: 1
    status: approved
    fit:
      geography:
        include:
          - country: USA
            subdivisions:
              - US-TX
        exclude: []
      company:
        employee_range:
          min: null
          max: null
        facility_count:
          min: null
          max: null
      required_characteristics:
        - id: FIT1
          criterion: '<observable or verifiable structural characteristic>'
          verification: '<how sourcing or discovery verifies it>'
      preferred_characteristics:
        - id: PREF1
          criterion: '<characteristic that increases priority>'
          verification: '<how it is verified>'
      disqualifiers:
        - id: DQ1
          criterion: '<condition that makes the account ineligible>'
          verification: '<how it is verified>'
      triggers:
        - id: TR1
          event: '<change event>'
          implication_hypothesis: '<why it may make evaluation timely>'
          verification: '<how the event is verified>'
    qualification:
      outreach_ready_when:
        - '<minimum verified condition>'
      opportunity_ready_when:
        - '<buyer-confirmed condition>'
      next_action: '<what the seller does when criteria are met>'

Market-persona bindings

Bind only the personas relevant to this vertical. A binding establishes that a persona is admissible in this vertical, under what role labels, and with what primary job. A generator must not infer missing bindings from the global persona list.

A market-persona binding selects no problems. It is catalog membership, not targeting. Problem selection, order, priority, impact framing, and call language belong to the audience binding, which is the only record that states what to raise with whom. Two audiences over the same vertical and persona routinely select different problems; one shared list on the persona binding cannot express that.

Order	Persona ID	Expected transaction roles	Primary job
1	P1	stakeholder	<job>

kind: market_persona_catalog
schema_version: 1
market_personas:
  - vertical_id: M1_V1
    persona_id: P1
    order: 1
    status: approved
    expected_transaction_roles:
      - stakeholder
    role_labels:
      - '<title used in this vertical>'
    responsibility_hypothesis: '<what this function may own here>'
    primary_job:
      situation: '<when this persona needs to make progress>'
      motivation: '<what they need to accomplish>'
      desired_outcome: '<why that progress matters>'
    secondary_jobs: []

order is the suggested contact sequence within the vertical. It does not select or rank problems.

Render the primary job in the form:

When situation, I need to motivation, so I can desired outcome.

Competitors

A competitor profile is one canonical, evidence-backed competitive reference. Store it as competitors/<competitor-id>.md. The filename stem must equal its immutable id.

---
id: C_00001_GLOBAL_SHOP
kind: competitor_profile
schema_version: 1
title: '<human-readable competitor or product name>'
description: '<bounded purpose of this competitive reference>'
owner: sales
status: approved
last_reviewed: 2026-08-02
review_by: 2026-09-02
---

The profile owns the competitor's sourced strengths, limitations, discovery guidance, supported claims, and prohibited claims. Every external or customer-derived claim still requires canonical evidence. An audience selects relevant profiles through competitor_ids; the competitor profile never stores reverse audience references.

Audience selection establishes reusable relevance only. It does not establish that a named account uses the competitor or is evaluating it. Generated assets may activate competitor-specific language only when matching account or buyer-confirmed evidence is supplied.

Audience bindings

An audience binding is the canonical, editable configuration for one pre-call target segment. Store it as content/audiences/<vertical-id>-<persona-id>-A<nn>.yaml. Its adjacent Markdown file has the same stem and is an enriched, generated profile.

The YAML owns:

• the immutable audience ID and lifecycle status;
• the market, vertical, persona, and controlled definition values;
• the ordered pre-call signal predicate and rejected-signal decisions;
• the ordered problem_ids selection;
• the ordered competitor_ids selection;
• audience-specific overrides, such as framing or discovery guidance, when a person deliberately supplies them.

The YAML is human-editable desired-state configuration. It does not store request history, change logs, duplicate-check results, ID-allocation logs, catalog conflicts, validation output, or other workflow metadata. Use Git history and workflow reports for those concerns.

The enrichment workflow resolves referenced records and renders their names, meaning, hypotheses, compatibility decisions, and approval blockers. It must not create a missing canonical fact. Generated wording that is not a sourced fact remains labeled as a hypothesis.

kind: audience_binding
schema_version: 3
id: M1_V1-P1-A02
status: approved
owner: sales
market_id: M1
vertical_id: M1_V1
persona_id: P1
definition:
  size_band:
    - '100_500'
    - '500_1000'
  size_band_basis: null
  location_footprint: multi_site_2_20
  systems_of_record:
    - spreadsheets
    - sage
  systems_of_record_basis: null
  signal_predicate:
    - signal_id: SG_001
      required_state: present
      on_unknown: include
      on_unknown_basis: default
  rejected_signals: []
market_persona: null
problem_ids: []
competitor_ids: []
discovery_plan: null
framing: null

Required fields are kind, schema_version, id, status, owner, market_id, vertical_id, persona_id, definition.size_band, definition.location_footprint, definition.systems_of_record, definition.signal_predicate, definition.rejected_signals, problem_ids, and competitor_ids.

Apply these rules:

• The filename stem equals id.
• The vertical belongs to market_id, and the persona resolves in the persona catalog. A missing market-persona binding is an approval blocker, not a reason to invent binding content.
• Every size, location, and system value resolves in variables.yaml.
• systems_of_record is a non-empty list. Normalize it to the order declared by variables.yaml.system_of_record before duplicate comparison or writing; user-supplied order does not create a distinct audience.
• unknown is mutually exclusive with every known system. Use [unknown] only when no system identity has been established as a pre-call fact; never combine it with a known value.
• signal_predicate may contain zero to four pre-call signals. Every included signal resolves, is collectable before outreach, uses qualifying or gating polarity, and declares required_state and on_unknown.
• problem_ids is intentionally ordered and may be empty in a draft. Each included problem must be compatible with the definition tuple.
• competitor_ids is intentionally ordered and may be empty. Each included ID resolves to one canonical competitor profile. Selection means the competitor is relevant context for the audience; it does not establish that a specific account uses or is evaluating that competitor.
• null means unknown. An empty list means reviewed and none selected, except systems_of_record, which is required and may be neither null nor empty.
• Removing a signal, problem, or competitor from an audience changes only the audience binding. It does not delete or deprecate the referenced canonical record.
• A sales conversation or test does not directly create a canonical claim. Route the observation through evidence and authoring review first, then add or remove the resulting immutable ID. Git history records the configuration change.

The enriched profile uses this front-matter contract:

kind: audience_profile
schema_version: 1
generated: true
audience_id: M1_V1-P1-A02
source_config: ./M1_V1-P1-A02.yaml
source_status: approved

The profile owns no independent lifecycle status or canonical relationship. It may be generated from a draft so reviewers can inspect it, but a generated profile does not make its configuration approved or call-sheet-ready. If the documentation front matter also contains status, it mirrors source_status.

Problems

Problems describe a testable mismatch, not a diagnosis of a named account. Each problem owns the ordered solutionsIds array that links it to applicable solutions.

A problem declares no vertical scope. It is written to be vertical-agnostic, and the audience bindings that reference it decide where it applies. This keeps one problem record reusable across sub-verticals that share the mismatch, instead of forcing a membership list that has to be edited every time a sub-vertical is added. The gate that replaces vertical_ids is the record's own situation and observable_signals: W10 verifies each candidate against them before selection.

Problem ID	Name	Solution IDs	Statement type	Status
P_00001	<problem name>	S_00001	market_hypothesis	approved

kind: problem_catalog
schema_version: 1
problems:
  - id: P_00001
    solutionsIds:
      - S_00001
    priority: 0-100
    name: '<short problem name>'
    status: approved
    statement_type: market_hypothesis
    applies_to_icp_ids:
      - M1_V1_ICP1
    situation: '<operating situation in which the mismatch may occur>'
    operational_mismatch: '<what may fail to remain aligned>'
    possible_consequences:
      - '<testable operational or commercial consequence>'
    observable_signals:
      - '<what a seller may listen for without treating it as proof>'
    disconfirming_signals:
      - '<answer or evidence showing the problem is absent>'
    confirmation_questions:
      - QA_M1_V1_001
    evidence_requirement: '<what would confirm the problem for an account>'
    evidence_ids:
      - EV_M1_V1_001
    prohibited_claims:
      - '<unsupported statement a seller or generator must not make>'

Solutions

A solution defines the mechanism used to address one or more problems. It must separate verified native capability from configured, integrated, roadmap, or unavailable behavior. Each solution owns the ordered proofIds array that links it to applicable proofs.

A solution declares no vertical scope, for the same reason a problem does not. Applicability is reached through the chain, not declared on the record:

audience.problem_ids[] → problem.solutionsIds[] → solution.proofIds[] → proof

An audience decides which problems apply to it; each problem carries the solutions that address it. A solution is therefore in scope for exactly the audiences that reach it. Where a mechanism genuinely depends on one vertical's process physics, that dependency belongs in a capability condition or in limitations, never in a scope list. Proof is the one record that stays vertical-scoped, because a result was observed somewhere specific.

Solution ID	Name	Proof IDs	Classification	Status
S_00001	<solution name>	PF_M1_V1_001	configured	approved

kind: solution_catalog
schema_version: 1
solutions:
  - id: S_00001
    proofIds:
      - PF_M1_V1_001
    priority: 0-100
    name: '<buyer-facing solution name>'
    status: approved
    mechanism: '<how the solution changes the workflow or decision>'
    capabilities:
      - name: '<specific capability>'
        classification: configured
        conditions:
          - '<customer rule, data, integration, or review dependency>'
        evidence_ids:
          - EV_PRODUCT_001
    expected_outcome_hypotheses:
      - '<outcome to validate, not a guaranteed result>'
    limitations:
      - '<known boundary or unsupported behavior>'
    prohibited_claims:
      - '<result or capability claim that is not supported>'

The relationship is forward-only:

problem.solutionsIds[] -> solution.proofIds[] -> proof

Do not add reverse problem references to a solution or reverse solution references to a proof. Resolve those relationships by traversing the owning arrays.

Proof

Proof is a bounded test with an artifact and buyer-defined acceptance criterion. A proof may be directly applicable in one or more explicitly listed verticals. Use outside those verticals is allowed only when the destination vertical's proof-transfer rule permits it.

Proof ID	Verticals	Name	Transfer level	Status
PF_MULTI_001	M1_V1, M1_V2	<proof name>	conditional	approved

kind: proof_catalog
schema_version: 2
proofs:
  - id: PF_MULTI_001
    vertical_ids:
      - M1_V1
      - M1_V2
    name: '<bounded proof name>'
    status: approved
    proof_type: '<workflow test, dataset test, reference, or case study>'
    safe_artifact: '<representative non-sensitive input>'
    procedure:
      - '<step performed during the proof>'
    expected_observation: '<what the buyer will be able to inspect>'
    acceptance_criterion: '<buyer-defined or objectively testable result>'
    owner: '<role accountable for running the proof>'
    capability_boundaries:
      - '<classification or dependency that must be disclosed>'
    transfer:
      level: conditional
      from_vertical_ids:
        - M1_V1
      conditions:
        - 'M1_V3: <required validation for reuse in that destination>'
    evidence_ids:
      - EV_PRODUCT_001

vertical_ids is required, non-empty, unique, and ordered by the canonical vertical catalog. Each listed vertical is a direct scope assertion and must be supported by the proof's evidence; listing several verticals never silently means every current or future vertical. transfer governs only destinations not already present in vertical_ids. Version 2 does not accept the former scalar vertical_id field.

For transfer to unlisted destinations, transfer.from_vertical_ids names the listed source verticals whose incoming destination rules are being used. The scalar level is the most restrictive selected rule, and conditions preserves the union of their required validations with destination IDs where needed. If that representation would broaden or lose a destination-specific rule, use prohibited until a separate proof or canonical rule can represent the reuse.

Questions and answers

Q&A records provide grounded call language, discovery prompts, objection responses, and qualification questions. An answer must preserve the statement type of every claim it contains.

Q&A ID	Persona IDs	Type	Problem IDs	Status
QA_M1_V1_001	P1	opening_question	P_00001	approved

kind: qa_catalog
schema_version: 1
qa:
  - id: QA_M1_V1_001
    vertical_id: M1_V1
    persona_ids:
      - P1
    type: opening_question
    status: approved
    problem_ids:
      - P_00001
    seller_question: '<approved opening question>'
    seller_answer: null
    buyer_question: null
    buyer_answer: null
    intent: '<what this exchange helps the buyer and seller establish>'
    follow_up_question_ids:
      - QA_M1_V1_002
    listen_for:
      - '<signal that determines the next branch>'
    response_branches:
      - when: '<buyer says the job is handled well>'
        next_action: '<accept, learn how, or stop>'
      - when: '<buyer confirms a relevant mismatch>'
        next_action: '<understand one example before offering proof>'
      - when: '<this is the wrong persona>'
        next_action: '<ask for a redirect if appropriate>'
    evidence_ids:
      - EV_M1_V1_001
    prohibited_language:
      - '<phrasing that turns a hypothesis into an account claim>'

  - id: QA_M1_V1_002
    vertical_id: M1_V1
    persona_ids:
      - P1
    type: discovery_question
    status: approved
    problem_ids:
      - P_00001
    seller_question: '<one useful follow-up question>'
    seller_answer: null
    buyer_question: null
    buyer_answer: null
    intent: '<fact or decision process this question explores>'
    follow_up_question_ids: []
    listen_for:
      - '<relevant buyer evidence>'
    response_branches: []
    evidence_ids: []
    prohibited_language: []

Allowed type values should be extended deliberately:

kind: qa_type_catalog
schema_version: 1
qa_types:
  - opening_question
  - discovery_question
  - qualification_question
  - objection
  - proof_question
  - redirect

Use the four directional fields consistently:

• seller_question is exact language the seller may ask.
• buyer_answer is an approved, evidence-backed buyer answer pattern when one exists; otherwise it is null.
• buyer_question is a buyer question or objection.
• seller_answer is the approved answer to that buyer question.

Exactly one of seller_question or buyer_question initiates a Q&A record. The corresponding answer may be null when the purpose is to listen and branch rather than prescribe an answer.

Evidence

Evidence records support market facts, product facts, customer observations, and confidence. Store one evidence record per file in content/evidence/<evidence-id>.md.

Evidence may come from structured questions answered by a user during an interactive authoring session. A recording, transcript, screenshot, or other attachment is useful but optional. When the source is user-provided, identify the contributor in publisher_or_owner, describe the interactive session in source, preserve the supplied observation faithfully in supports or notes, and state any unmeasured or second-hand elements in notes. Use buyer_interview for a buyer's direct answers, call_learning for a contributor's report of a buyer conversation, and internal_validation for an expert's product observation. A bare link or unattributed paraphrase remains insufficient.

When available, source names a stable task, thread, transcript, or session reference. When no separate reference exists, preserve the user's relevant answer in notes so the evidence record itself remains inspectable; do not invent a recording or attachment.

kind: evidence_catalog
schema_version: 1
evidence:
  - id: EV_M1_V1_001
    type: primary_source
    title: '<source title>'
    source: '<URL, repository path, or customer artifact reference>'
    publisher_or_owner: '<source owner>'
    published_at: null
    accessed_at: 2026-07-23
    supports:
      - '<specific claim supported by this evidence>'
    scope: '<market, vertical, product, account, or buyer>'
    confidence: medium
    notes: '<limitations, permissions, or interpretation>'

For interactive evidence, the same schema may be populated as follows:

kind: evidence_catalog
schema_version: 1
evidence:
  - id: EV_PRODUCT_001
    type: internal_validation
    title: '<bounded expert observation>'
    source: 'Interactive authoring session on 2026-08-01; response preserved in notes.'
    publisher_or_owner: '<contributing expert or role>'
    published_at: 2026-08-01
    accessed_at: 2026-08-01
    supports:
      - '<specific fact supplied by the user>'
    scope: '<product or explicitly named verticals>'
    confidence: medium
    notes: >-
      User-provided observation: <faithful response>. Distinguish direct
      observation, buyer confirmation, estimates, and anything not measured.

Call-sheet generation

A call sheet is a rendered view, not an independent source of truth. Generate it from one approved audience YAML configuration and its approved referenced chain. Optionally specialize it with account facts and buyer-confirmed facts. The enriched audience Markdown profile is not a generator input.

kind: call_sheet_generation_spec
schema_version: 1
call_sheet_generation:
  input:
    required:
      - audience_id
    optional:
      - account_evidence_ids
      - buyer_confirmed_evidence_ids
      - competitor_id
  eligibility:
    - 'The vertical operating_status is testing or active.'
    - 'The persona has a market_persona binding for the vertical.'
    - 'The audience binding has at least one problem in problem_ids and an opening Q&A, and that problem resolves through a solution to a proof.'
    - 'Every selected problem-chain record and any activated competitor record is approved.'
    - 'Every factual claim has evidence.'
    - 'Every solution capability includes a classification.'
  selection:
    - "Select the binding's lowest-numbered priority problem by default."
    - 'Use one problem in the opener; do not stack problems.'
    - "Use the first eligible solution in the problem's solutionsIds array."
    - "Use the first eligible proof in the solution's proofIds array."
    - 'Preserve Q&A order and response branches.'
    - 'Apply account facts only when their evidence scope matches the account.'
    - "Use competitor-specific language only when competitor_id is listed in the audience binding's competitor_ids and matching account or buyer-confirmed evidence establishes relevance."
    - 'Phrase market and persona hypotheses as questions.'
  fail_when:
    - 'An ID reference is missing.'
    - "The selected problem is not listed in the audience binding's problem_ids."
    - "The selected solution is not listed in the selected problem's solutionsIds."
    - "The selected competitor is not listed in the audience binding's competitor_ids."
    - 'Competitor-specific language lacks matching account or buyer-confirmed evidence.'
    - 'The persona is present only in the global persona list.'
    - 'Proof transfer is prohibited or its required validation is incomplete.'
    - 'A capability is unclassified.'
    - 'An account claim lacks account or buyer-confirmed evidence.'
    - 'A prohibited claim or prohibited phrase would be rendered.'

Generated call-sheet shape

Generated sheets should contain the following YAML front matter and sections. The generator records source IDs so every line can be traced back to the playbook.

---
kind: generated_call_sheet
title: '<vertical name> — <persona name> call sheet'
generated: true
schema_version: 1
generated_at: '<YYYY-MM-DDTHH:MM:SSZ>'
audience_id: M1_V1-P1-A02
audience_source: ../audiences/M1_V1-P1-A02.yaml
vertical_id: M1_V1
icp_id: M1_V1_ICP1
persona_id: P1
problem_id: P_00001
solution_id: S_00001
proof_id: PF_M1_V1_001
qa_ids:
  - QA_M1_V1_001
competitor_id: null
source_version: '<git commit, release, or content version>'
account_id: null
---

# <vertical name> — <persona name>

## Job to be done

<When ..., I need to ..., so I can ...>

## Before dialing

- Verify the account matches: <selected ICP criteria>.
- Do not assume: <problem and prohibited account claims>.

## Permission

This is <caller> from <company>. Is now a bad time to talk?

## Pattern and opening question

<One market fact followed by the bound opening question.>

## Follow the answer

- If handled well: <approved branch>.
- If relevant: <approved branch and one follow-up question>.
- If wrong person: <approved redirect>.

## Listen for

- <Signals from the problem and Q&A records.>

## Competitive context

<When `competitor_id` is active, render only supported guidance from that
audience-selected competitor profile. Omit this section when no competitor is
activated by matching account or buyer-confirmed evidence.>

## Solution mechanism

<Mechanism with native, configured, integrated, roadmap, or unavailable
classification and conditions.>

## Bounded proof

<Safe artifact, procedure, expected observation, and acceptance criterion.>

## Choice

<Inspect one artifact, compare one workflow, redirect, correct the premise,
or stop.>

## Do not claim

- <Combined prohibited claims from the selected records.>

## Source records

- <All IDs used to generate this sheet.>

Validation checklist

Before approving a playbook or generating a call sheet, verify:

• Every ID is unique and every reference resolves.
• Every audience binding uses schema version 3, has a competitor_ids list, and has a non-empty, unique, catalog-ordered systems_of_record list; unknown appears only by itself.
• Every competitor ID matches C_<nnnnn>_<NAME>, resolves to a canonical competitor profile, and appears at most once in an audience binding.
• Every vertical belongs to an existing market.
• Every vertical persona exists in the master persona list.
• No market-persona binding selects problems. Problem selection lives only in audience bindings.
• Every problem ID matches P_<nnnnn>, has at least one solutionsIds reference, and has a confirmation path.
• No problem or solution declares vertical_ids. Applicability is reached through audience.problem_ids[] → problem.solutionsIds[] → solution.
• Every problem referenced by an audience binding is compatible with that audience's definition tuple, judged against the problem's situation and observable_signals.
• Every solution ID matches S_<nnnnn>, has at least one proofIds reference, and classifies each capability.
• Every solution is reachable from at least one problem's solutionsIds. An unreachable solution is orphaned, not global.
• Every proof referenced by a solution uses proof_catalog schema version 2, has a non-empty, unique, catalog-ordered vertical_ids list, and has an acceptance criterion.
• Every problem-to-solution and solution-to-proof reference resolves.
• Each proof's evidence supports direct applicability in every listed vertical.
• Proof-transfer rules for unlisted destination verticals are explicit even when transfer is prohibited.
• Every opening question preserves hypotheses as questions.
• No generated line turns market evidence into an account fact.
• Retired, deprecated, or draft content is not rendered into an active call sheet.

Change log

• 2026-08-02 — Migrated audience_binding to schema version 3. Added required, ordered competitor_ids; selection establishes reusable audience relevance, while account-specific activation still requires account or buyer-confirmed evidence.
• 2026-08-01 — Migrated proof_catalog to schema version 2. Replaced scalar vertical_id with required vertical_ids, introduced PF_MULTI_<nnn> IDs for multi-vertical proofs, and allowed W9 evidence records to preserve structured user-provided observations without requiring a recording.
• 2026-08-01 — Migrated audience_binding to schema version 2. Replaced scalar definition.system_of_record with normalized, non-empty definition.systems_of_record; unknown is exclusive.
• 2026-07-26 — Removed provenance and workflow logs from human-editable audience-binding YAML. Audience files now contain desired-state configuration only; Git history and workflow reports retain change context.
• 2026-07-26 — Defined standalone audience_binding YAML files as the authoritative audience configuration and adjacent audience_profile Markdown files as enriched projections.
• 2026-07-25 — Removed problem_bindings from market_persona_catalog. A persona binding is catalog membership; problem selection belongs only to the audience binding.
• 2026-07-25 — Removed vertical_ids from solution records. A solution is in scope for exactly the audiences that reach it through audience.problem_ids[] → problem.solutionsIds[]. Proof stays vertical-scoped.
• 2026-07-25 — Removed vertical_ids from problem records. Audience bindings own applicability through problem_ids, so one problem is reusable across sub-verticals that share the mismatch.
• 2026-07-24 — Replaced large problem, solution, and proof registries with atomic canonical files; added inbox, audience-binding, and generated-content directories plus the manual promotion process.
• 2026-07-23 — Changed problem and solution IDs to P_<nnnnn> and S_<nnnnn>; defined forward Problem → Solution → Proof arrays and vertical_ids support, including [all].
• 2026-07-23 — Defined file storage, typed YAML blocks, vertical-scoped transaction roles, directional Q&A fields, and structured ISO geography.
• 2026-07-23 — Defined the initial canonical format for market playbooks and generated persona call sheets.