Skip to main content

Content

This directory is the working library for problem, solution, and proof content. It supports incremental contributions, reuse between audiences, and audience-specific selection without duplicating canonical records. Canonical competitor profiles live in the sibling ../competitors/ directory and are selected by audience competitor_ids.

For contribution and promotion flows, see Authoring workflows. For record schemas and validation rules, see the sales asset format.

Directory map​

Ordered as the menu is: the targeting layer first, then the record chain it selects from, then reference and raw input, then output.

content/
├── index.md          you are here
├── workflows.md      how to change anything below
├── audiences/        canonical YAML targets plus enriched Markdown profiles
├── problems/         one testable operational mismatch per file
├── solutions/        the mechanism that addresses a problem
├── proofs/           a bounded test with an acceptance criterion
├── evidence/         support for external, customer, and product claims
├── cheat-sheets/     condensed pre-call reference
├── inbox/            provisional observations awaiting triage
└── generated/        rendered call cards, disposable

Every directory has its own index.md describing what it owns, how its records are named, and what is currently in it. Those pages are the detail; this one is the map.

Directory definitions​

audiences/​

Canonical audience YAML bindings, and the targeting layer for the whole library. A YAML configuration selects and orders canonical problems in problem_ids, selects relevant competitive profiles in competitor_ids, and owns audience-specific priority, impact framing, and call language. Its ID-matched Markdown file is an enriched sales guide generated from the YAML and referenced canonical records.

Because problems and solutions carry no vertical scope, problem_ids is the only statement of where a problem applies.

Use an ID-matched pair:

<vertical-id>-<persona-id>-A<nn>.yaml  canonical configuration
<vertical-id>-<persona-id>-A<nn>.md    enriched profile

For example, M1_V1-P1-A01.yaml enriches to M1_V1-P1-A01.md. The A<nn> suffix is required because one vertical and persona pair supports several audiences, distinguished by size band, location footprint, systems of record, and signal predicate. Refer to competitors, problems, solutions, and proofs by immutable ID rather than copying their content into the configuration.

Change an audience by editing its YAML and rerunning W10E. Never recover configuration from, or maintain independent facts in, the Markdown profile.

problems/​

Canonical problem records. Store one problem per file and name the file with its immutable ID, for example P_00001.md.

A problem declares no vertical scope. Its situation field carries the preconditions an audience tests a selection against.

solutions/​

Canonical solution records. Store one solution per file and name the file with its immutable ID, for example S_00001.md.

A solution declares no vertical scope either. It is reached through audience.problem_ids[] → problem.solutionsIds[], so it is in scope for exactly the audiences that reach it.

proofs/​

Canonical proof records. Store one proof per file and name the file with its immutable ID, for example PF_M1_V1_001.md.

Proof is the only record in the chain that stays vertical-scoped. Its required vertical_ids list names one or more verticals where the bounded proof is directly applicable. Destination proof-transfer rules decide whether it may be reused in an unlisted vertical.

evidence/​

Canonical evidence records. Store one evidence record per file, named with its immutable ID, for example EV_PRODUCT_001.md or EV_MULTI_001.md. Evidence may preserve a structured user-provided observation from an interactive authoring session; recordings and attachments are optional when the record captures the contributor, date, bounded support, scope, confidence, and limitations.

cheat-sheets/​

Condensed pre-call reference distilled from the communication instructions. Reference material, not canonical: a cheat sheet is never a source for a record and never the place a new claim enters the library.

inbox/​

Unreviewed call analyses, seller observations, and proposed changes. Inbox items are inputs to review, not approved sales claims and not generator inputs.

Use YYYY-MM-DD-<short-description>.md for filenames. Keep the source, contributor, and date in the item so a reviewer can trace the observation.

generated/​

Derived call sheets and other rendered sales assets. Generated files record their source IDs but never become sources for canonical records.

Authority and reuse​

  • Audience YAML, problems/, solutions/, proofs/, and evidence/ are canonical.
  • ../competitors/ is canonical; audience bindings select competitor profiles by immutable ID.
  • Audience Markdown profiles are generated projections even though they sit beside their YAML for documentation navigation.
  • cheat-sheets/ is reference. It restates canonical rules and owns none.
  • inbox/ is provisional.
  • generated/ is derived and replaceable.
  • Every problem, solution, and proof has exactly one owning file.
  • Shared and audience-specific records use the same canonical directories.
  • A record is shared when multiple audience YAML configurations reference it.
  • A record is audience-specific when only the applicable audience YAML references it.
  • Directory placement does not determine applicability. Record fields and audience references determine applicability.
  • Do not create shared/ or audience-specific copies of canonical records.

Scope​

This directory organizes audience selection and the problem → solution → proof workflow. The existing competitor, persona, market, and vertical catalogs remain in docs/sales/. Evidence must still be recorded and referenced according to the sales asset format; this structure does not redefine evidence storage.