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
        -> 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, and proof authoring. Store each problem, solution, and proof 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. A problem or solution is stored once and declares no vertical scope; audience bindings decide applicability through immutable references. 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_<vertical>_<nnn>	PF_M1_V2_001
Q&A	QA_<vertical>_<nnn>	QA_M1_V2_001
Evidence	EV_<scope>_<nnn>	EV_M1_V2_001
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. IDs identify records; display names remain editable.

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: draft

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	draft

kind: icp_catalog
schema_version: 1
icps:
  - id: M1_V1_ICP1
    vertical_id: M1_V1
    name: '<ICP name>'
    priority: 1
    status: draft
    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: draft
    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.

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;
• 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: 2
id: M1_V1-P1-A02
status: draft
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: []
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, and problem_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.
• 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 or problem 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: draft

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	draft

kind: problem_catalog
schema_version: 1
problems:
  - id: P_00001
    solutionsIds:
      - S_00001
    priority: 0-100
    name: '<short problem name>'
    status: draft
    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	draft

kind: solution_catalog
schema_version: 1
solutions:
  - id: S_00001
    proofIds:
      - PF_M1_V1_001
    priority: 0-100
    name: '<buyer-facing solution name>'
    status: draft
    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 case study or proof from another vertical is usable only when the vertical's proof-transfer rule permits it.

Proof ID	Name	Transfer level	Status
PF_M1_V1_001	<proof name>	conditional	draft

kind: proof_catalog
schema_version: 1
proofs:
  - id: PF_M1_V1_001
    vertical_id: M1_V1
    name: '<bounded proof name>'
    status: draft
    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: []
      conditions:
        - '<condition under which related proof is relevant>'
    evidence_ids:
      - EV_PRODUCT_001

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	draft

kind: qa_catalog
schema_version: 1
qa:
  - id: QA_M1_V1_001
    vertical_id: M1_V1
    persona_ids:
      - P1
    type: opening_question
    status: draft
    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: draft
    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, and confidence. A link by itself is insufficient; record what it supports and when it was reviewed.

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>'

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
  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 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.'
    - '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 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
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.>

## 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 2 and has a non-empty, unique, catalog-ordered systems_of_record list; unknown appears only by itself.
• 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 has an acceptance criterion.
• Every problem-to-solution and solution-to-proof reference resolves.
• Proof-transfer rules 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-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.