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.

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
├── 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 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 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, because a result was observed somewhere specific. Its vertical's proof_transfer_level decides whether it may be reused elsewhere.

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/, and proofs/ are canonical.
  • 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 the problem → solution → proof workflow. The existing 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.