Audiences

An audience YAML binding is a selection rule over canonical content. It names a segment precisely enough to work, then states which canonical problems apply to it and in what order. The adjacent Markdown file is an enriched sales guide generated from that configuration and the records it references.

audience = vertical + persona + size_band(1+) + location_footprint
           + systems_of_record(1+) + signal_predicate(0-4, qualifying|gating)

systems_of_record is a required multi-select. Store unique values in the order declared by variables.yaml.system_of_record. The combination is a set for duplicate identity, so different input order does not create another audience. [unknown] means no known system identity is established as a pre-call fact and cannot be combined with a known system. It does not mean the company has no systems.

Why this folder comes first

Problems and solutions declare no vertical scope. An audience binding's problem_ids is the only statement of where a problem applies, which makes this folder the targeting layer for the whole library. Everything downstream — which card gets generated, what a rep may say — is decided here.

Nothing upstream will reject a bad selection. W10 is the check: test every included problem against its own situation and the audience definition tuple. The YAML stores the resulting desired state; Git history and workflow reports retain change context.

What a binding owns

YAML configuration owns	Enriched profile does not own
problem_ids — selection and order	Problem, solution, or proof content
Audience-specific priority	Canonical priority
framing.lead_with, outcome_bar	The mechanism or the proof
do_not_assert for this audience	A record's own prohibited_claims
The signal predicate and what each gate changes	Signal interpretation, which lives in signals.yaml
Deliberate market_persona overrides	Persona definition, which lives in persona_list.md

A market-persona binding in the vertical catalog establishes that a persona is admissible. It selects no problems. Targeting is always the audience's job.

Naming

Each audience uses an ID-matched pair:

M1_V1-P1-A01.yaml  canonical configuration
M1_V1-P1-A01.md    enriched profile

The A<nn> suffix is required: one vertical and persona pair supports several audiences, distinguished by size band, location footprint, systems of record, and signal predicate. Two audiences over the same vertical and persona routinely select different problems.

Current records

Profile	Configuration	Segment	Persona	problem_ids	Status
Not enriched	M1_V1-P1-A03.yaml	Plastic extrusion, 20–50 employees, single site, systems unknown	P1 CEO	P_00002	approved
Not enriched	M1_V1-P1-A04.yaml	Plastic extrusion, 50–100 employees, single site, systems unknown	P1 CEO	[] — no problem selected	approved
M1_V1-P1-A05	M1_V1-P1-A05.yaml	Plastic extrusion, 100–500 employees, single site, systems unknown	P1 CEO	8 selected; P_00002 conflicts with single_site	approved
Not enriched	M1_V2-P1-A01.yaml	Plastic injection molding, 20–50 and 50–100 employees, single site, spreadsheets and QuickBooks	P1 CEO	[] — no problem selected	draft

M1_V1-P1-A03, M1_V1-P1-A04, and M1_V2-P1-A01 have not been enriched. M1_V1-P1-A05 is enriched for review and visibly reports the scope conflict between P_00002 and its single_site definition.

Authoring

Use W10 or the create-audience rule to create and update YAML. Use W10E or the enrich-audience rule to refresh the Markdown guide. An audience is never approved by an agent.

Learning follows this loop:

tested observation or sales conversation
  → evidence and canonical review
  → add, remove, or reorder IDs in audience YAML
  → enrich-audience
  → refreshed guide for sales

Removing a reference from an audience never deletes the canonical signal or problem.