Problems

A problem record describes one testable operational mismatch: something the business does that has stopped matching how the business runs. It is not a complaint, a feature gap, a persona, or a market.

The test of a problem is whether it can be wrong. A record with no disconfirming_signals is a belief, not a problem, and must not be created.

No vertical scope

A problem declares no vertical_ids, no market, and no persona. It is written to be vertical-agnostic so one record stays reusable across sub-verticals that share the mismatch, instead of carrying a membership list that has to be edited every time a sub-vertical is added.

Two consequences follow, and both matter:

1. situation is the gate. It is the only thing an audience tests a selection against. A precondition — "runs more than one plant", "the ledger sits in a separate package" — must be stated there explicitly or the problem will be mis-selected. P_00002 is the worked example: its situation requires more than one plant, which is why every single_site audience rejects it.
2. Applicability lives downstream. An audience binding's problem_ids says where the problem applies. Nothing on this record does.

What a problem owns

Field	What it is for
situation	The operating conditions the mismatch needs. The selection gate
operational_mismatch	What has stopped staying aligned
possible_consequences	Testable operational or commercial consequences
observable_signals	What a seller may listen for, never as proof
disconfirming_signals	What would show the problem is absent
evidence_requirement	What would confirm it for a specific account
prohibited_claims	What a seller or generator must never say
solutionsIds	Ordered references to the solutions that address it
priority	Canonical ordering only. Audience priority lives in the binding

Audience-specific impact, framing, and call language never appear here.

Naming

One problem per file, named for its immutable ID: P_00001.md.

A persona ID and a problem ID both start with P. The underscore distinguishes them: P2 is a persona, P_00002 is a problem. They are never interchangeable.

Current records

ID	Mismatch	Priority	Solutions	Status
P_00001	Operating process lives in software only its author can change	40	S_00001	draft
P_00003	Price and delivery date committed without confirming the producing asset	55	S_00003	draft
P_00002	Margin cannot be stated per site or per unit	70	S_00002	draft
P_00004	Channel quotes are not reconciled to the underlying project	—	none	draft
P_00005	Project outcomes stop at the channel partner	—	none	draft
P_00006	Committed orders are sequenced through manual asset-by-asset judgment	—	S_00005	draft
P_00007	Quote requests require manual translation before processing	—	S_00006	draft
P_00008	Schedule entry stalls the operating application	—	S_00007	draft
P_00009	Relevant bid quantity is buried in unstructured project documents	—	S_00008	draft
P_00010	Management questions require spreadsheet reconstruction outside the operating system	50	S_00009	draft
P_00011	Recorded inventory cannot be reconciled to physical stock	—	S_00010	draft
P_00012	Replacement planning lacks a verified export of linked operating records	—	S_00011	draft
P_00013	Production quantity cannot be selected from total economic cost	50	none	draft

All thirteen carry evidence_ids: []. Their supporting observations sit in inbox/, which is never a generator input, so nothing here may be asserted as fact yet. P_00004 through P_00009, P_00011, and P_00012 also have unset canonical priorities. P_00004, P_00006 through P_00011 now have draft solution references; P_00013 has approved canonical priority 50 and no solution reference yet.

Authoring

W5 in the authoring workflows, or the create-problems rule in .agents/rules/ for the interactive path from raw content.

The most common failure is two problems for one mismatch. If the mismatch is the same and only the wording differs, that difference belongs in an audience binding.