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.
Working output: A reuse map linking existing capabilities to the need, with overlaps and remaining gaps.
Start with this question
Is the missing piece a capability, a route to it, or permission to use it?
If an existing target genuinely lacks an internal responsibility, continue to bounded capability expansion. CBE and CBE-IX operate after target identity and coverage have been established.
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.
Working output: a responsibility invariant, classified candidates, boundary and handoff contracts, and an iteration ledger when repeated expansion is justified.
Start with this question
What is still missing for this target to perform its own responsibility? Use CBE for a bounded analysis; choose CBE-IX when accepted changes expose further internal gaps. They are alternatives within a method family, not two mandatory sequential steps. Execute here means constructing the analysis model, boundaries and handoffs; implementation requires separate authorization.
Example: an ingestion pipeline keeps format detection, delegates embeddings and splits determining retention policy from attaching the returned classification. Try the classification lab and iteration lab.
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.
Discover, complete and activate bounded capabilities
Find and reuse existing realizations, examine a selected capability for internal gaps, and activate it within explicit authority. Keep discovery, design decisions and authorization distinct.
After discovery, CBE and CBE-IX examine a defined target for internal gaps while preserving its boundaries. This design role does not confer activation authority.
Scale shifts
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.
Capability boundary
A defined service or agent
CBE separates owned gaps from peer operations. CBE-IX adds a ledger when new accepted responsibilities reveal further gaps. Example: an ingestion agent attaches a returned retention classification while a policy service keeps ownership of the policy decision.
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.