Problem -> capability composition -> solution pattern
Build the stack around the problem.
A capability is a reusable building block. A solution pattern is a bounded composition selected from the current catalog according to problem shape, lifecycle position and operating scale. The goal is not to force every method into every task, but to make the smallest useful stack visible and inspectable.
Reusable compositions for recurring classes of work
These patterns are intentionally broader than individual methods. They show how the same capability can contribute to different outcomes depending on context. The listed stacks are typical starting points, not fixed recipes.
Explore the solution space
What is getting in the way?
Combine a problem, a stage of work and an operating scale to find relevant patterns. Each match shows a possible working output and the capabilities behind it.
Matches are curated starting points, not ranked recommendations. Start small; add capabilities only when the problem calls for them.
No listed pattern matches this combination. Broaden one filter or clear the filters to explore the full map. This is a limit of the map, not a claim that the problem cannot be addressed.
Compare capability combinations
Read across a pattern to see its building blocks, or down a capability to see where it contributes. Filled dots mean included in this pattern, not a score. The rows follow your filters.
Problem: relevant context is distributed across documents, repositories, histories or representations and the system cannot reliably tell what is the same subject.
Outcome: bounded context with explicit identity, relationships, provenance, authority and next routes.
Problem: a rich request or problem space contains several plausible intents, interpretations or paths and an early answer would erase useful structure.
Outcome: preserve the semantic field first, compare alternatives explicitly, then narrow only when the decision surface is strong enough.
Problem: projects, repositories, copies, public projections and capability representations have become hard to navigate without false identity collapse.
Outcome: a typed map of what exists, how surfaces relate, where authority lives and which capability is actually discoverable.
Problem: a new method may appear effective because every attempt has already been shaped by the method being evaluated.
Outcome: preserve independent first-pass evidence, compare guided and unguided reasoning, and make differences in claim quality and interpretation inspectable.
The current catalog can be read as a set of complementary roles. A real problem may use one role, several roles or a cross-cutting subset. The sequence below is a composition aid, not a mandatory pipeline.
The same problem changes when the operating scale changes
Scale does not automatically require more methods. It changes which responsibilities become load-bearing. These examples show how a stack can expand only when the problem demands it.
Claim / conversation
Preserve meaning before commitment
PISD, DIAL-4P and DIAL-4 may be enough when the central risk is premature narrowing inside one discussion.
Task / workflow
Add execution boundaries
Dialogue lifecycle, 5PP and AICS enter when decisions become instructions, actions and verifiable outcomes.
Project / repository
Add identity and source routing
ORBIT, SORR, SRCB and CARD & POINTER become important when state and authority are distributed across surfaces.
Ecosystem / portfolio
Add discovery and reuse
Capability-Gap, CSR and GDSA enter when the question is no longer only what a system knows, but what capability already exists and can be surfaced responsibly.
Selection discipline
Choose the smallest sufficient stack
The map is useful only if it prevents unnecessary ceremony as well as unnecessary reinvention.
Start from the observed problem, not from a preferred method name.
Add orientation capabilities when identity, provenance, scope or authority is uncertain.
Add independent-baseline or claim-grading capabilities when the evaluation itself can be biased.
Add execution-control capabilities only when decisions can become actions or authoritative artifacts.
Add capability-discovery and activation capabilities when the problem concerns reuse, visibility or bounded invocation.
Verify the property that matters. Command success, documentation presence and public visibility are not substitutes for the claimed outcome.
Boundary: this is a design and orientation map. It does not claim that a pattern is deployed in a particular product, installed in a runtime, authorized for an action class or proven by a public showcase. Those claims require separate evidence.
This layer intentionally stops before product and deployment claims. Continue to the capability inventory for individual profiles, or to the proof packages for separately verified implementation evidence. Use the patterns to frame a concrete problem, then inspect the linked methods and evidence for the responsibilities that matter.