Solutions

A solution record defines the mechanism used to address one or more problems — how the workflow or the decision changes. It is not a feature list, a benefit, or a pitch.

Its central job is to separate what the product actually delivers from what it delivers conditionally, through integration, on a roadmap, or not at all.

No vertical scope

A solution declares no vertical_ids. It is reached through the chain, never declared into scope:

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 belongs in a capability condition or in limitations — never in a scope list.

Proof is the one record in the chain that stays vertical-scoped, because a result was observed somewhere specific.

The problem owns the reference

The problem's ordered solutionsIds array holds the link. A solution never carries a reverse pointer back to its problem. Resolve the relationship by traversing the owning array.

Capability classification

Every capability carries a capability_classification. An unclassified capability fails validation and blocks generation.

Value	Means
native	Shipped and delivered by the product as it stands
configured	Delivered, but requires setup whose effort may not be knowable in advance
integrated	Delivered through a connection to another system
roadmap	Not available. Never describe it in language implying it is
unavailable	Not delivered. Disclose it if asked

Two rules that cause most rejected records:

• A commercial term is not a capability. Pricing, licence cost, free changes, and guarantees are not capabilities entries.
• limitations and prohibited_claims are required work. A solution listing no limitation has not been thought through.

Naming

One solution per file, named for its immutable ID: S_00001.md.

Current records

ID	Mechanism	Addresses	Proof	Status
S_00001	Editable rule set in place of hand-written code	P_00001	none	draft
S_00003	Quoting bound to the production schedule	P_00003	none	draft
S_00002	One operating record with the ledger synchronized	P_00002	none	draft
S_00004	One project identity across channel quotes	P_00004	none	draft
S_00005	Generated work-center allocation and schedule reflow	P_00006	none	draft
S_00006	Request text converted into a reviewed quote draft	P_00007	none	draft
S_00007	Targeted schedule edits with explicit reflow	P_00008	none	draft
S_00008	Reviewed document takeoff into structured opportunities	P_00009	none	draft
S_00009	Management views over the live operating record	P_00010	none	draft
S_00010	Cycle-count reconciliation through posted inventory adjustments	P_00011	none	draft
S_00011	Reconciled trial migration before cutover	P_00012	none	draft

None is generation-ready. All eleven carry proofIds: []. The first three rest on seller statements recorded in inbox/, while S_00004 through S_00011 rest on deployment-specific MCP observations and inferences that have not yet been promoted into canonical product evidence through W9.

Authoring

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

A solution needs a resolving problem ID before anything else happens. A problem name, a description, or an audience file is never a substitute.