Solution-space map
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.

Explore the combinations
18 capabilities10 solution patterns3 dimensions
Solution patterns

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.

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.

Solution patterns × capability combinations
Solution patternPISDIPBDIAL-4PSRCBORBITSORRCARD & POINTERDIALECTICDIAL-4DIAL-4+Hermeneutic-didacticRigVedanDialogue lifecycle5PPAICSCapability-GapCSRGDSA
Governed AI deliveryNot includedNot includedNot includedNot includedNot includedNot includedNot includedNot includedNot includedIncludedNot includedNot includedIncludedIncludedIncludedNot includedNot includedNot included
Context integrityNot includedNot includedNot includedIncludedIncludedIncludedIncludedNot includedNot includedNot includedNot includedNot includedNot includedNot includedNot includedNot includedNot includedNot included
Evidence synthesisNot includedIncludedNot includedIncludedNot includedIncludedNot includedIncludedIncludedIncludedNot includedNot includedNot includedNot includedNot includedNot includedNot includedNot included
Decision supportIncludedIncludedIncludedNot includedNot includedNot includedNot includedIncludedIncludedIncludedNot includedNot includedNot includedNot includedNot includedNot includedNot includedNot included
Reuse before createNot includedNot includedNot includedNot includedNot includedIncludedIncludedNot includedNot includedNot includedNot includedNot includedNot includedNot includedNot includedIncludedIncludedIncluded
Portfolio orientationNot includedNot includedNot includedNot includedIncludedIncludedIncludedNot includedNot includedNot includedNot includedNot includedNot includedNot includedNot includedIncludedIncludedIncluded
Knowledge architectureNot includedNot includedNot includedIncludedIncludedNot includedIncludedNot includedNot includedNot includedIncludedIncludedNot includedNot includedNot includedNot includedNot includedNot included
Interpretation boundaryNot includedNot includedNot includedNot includedNot includedNot includedIncludedIncludedNot includedIncludedIncludedIncludedNot includedNot includedNot includedNot includedNot includedNot included
Bounded activationNot includedNot includedNot includedNot includedNot includedNot includedIncludedNot includedNot includedNot includedNot includedNot includedIncludedIncludedIncludedNot includedIncludedIncluded
Comparative evaluationNot includedIncludedNot includedNot includedNot includedIncludedNot includedIncludedIncludedIncludedNot includedNot includedNot includedNot includedNot includedNot includedNot includedNot included
Governed AI delivery

AI-assisted workflow governance

Problem: model output, human decision and executable action are being treated as one undifferentiated step.

Outcome: an explicit path from clarification through decision, bounded execution and property-specific verification.

LifecycleClarify -> Decide -> Execute -> Verify
ScaleTask, workflow, multi-agent work

Working output: A workflow with explicit decision gates, bounded instructions and acceptance checks.

Start with this question

Where can a suggestion currently turn into an action without a recorded decision?

Link to this pattern
Context integrity

Semantic and context reconciliation

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.

LifecycleExplore -> Orient -> Clarify -> Re-enter
ScaleConversation through ecosystem

Working output: An identity and source map recording relationships, conflicts and routes to authoritative evidence.

Start with this question

Which sources disagree, and are they actually describing the same subject?

Link to this pattern
Evidence synthesis

Evidence-backed research synthesis

Problem: many sources or interpretations must be reconciled without letting the emerging explanation silently strengthen weak claims.

Outcome: a bounded understanding that keeps source support, independent baselines, competing interpretations and claim strength visible.

LifecycleObserve -> Explore -> Clarify -> Verify
ScaleClaim, research task, project

Working output: A synthesis with source support, competing explanations and unresolved claims kept visible.

Start with this question

Which conclusion changes if the weakest source is removed?

Link to this pattern
Decision support

Ambiguity-to-decision support

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.

LifecycleExplore -> Clarify -> Decide
ScaleConversation, task, strategy problem

Working output: A decision brief with alternative interpretations, assumptions and criteria for narrowing the options.

Start with this question

What would we lose by committing to the first interpretation?

Link to this pattern
Reuse before create

Capability discovery and reuse

Problem: a new tool, workflow or method is being proposed before the existing capability estate has been understood.

Outcome: identify existing realizations, reconcile overlaps and select the smallest sufficient intervention before adding another surface.

LifecycleExplore -> Orient -> Clarify -> Decide
ScaleProject, repository, ecosystem

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?

Link to this pattern
Portfolio orientation

Multi-surface portfolio orientation

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.

LifecycleOrient -> Clarify -> Re-enter
ScaleRepository estate, portfolio, ecosystem

Working output: A navigable map separating projects, repositories, copies and public representations.

Start with this question

Where does the current authoritative state of each subject live?

Link to this pattern
Knowledge architecture

Compact knowledge representation and transfer

Problem: useful meaning must survive compression, routing and re-entry without turning labels or summaries into source truth.

Outcome: compact typed knowledge units, bounded orientation and explicit routes back to deeper evidence and authority.

LifecycleOrient -> Interpret -> Project -> Re-enter
ScaleKnowledge unit, project, agent context

Working output: Compact knowledge units with explicit relationships and routes back to the supporting sources.

Start with this question

Which meaning must survive compression and a later return to the work?

Link to this pattern
Interpretation boundary

Explainable knowledge transfer

Problem: understanding, explanation, semantic classification and durable admission risk being collapsed into one representation.

Outcome: preserve the difference between iterative interpretation, didactic projection, semantic classification and claim support.

LifecycleInterpret -> Project -> Verify
ScaleClaim, lesson, knowledge surface

Working output: An explanation that separates interpretation, teaching choices and the evidence for each claim.

Start with this question

Can a reader distinguish the explanation from the source it interprets?

Link to this pattern
Bounded activation

Governed capability activation

Problem: a useful capability exists, but discovery, relevance, authorization and actual use are being treated as the same state.

Outcome: move from durable existence to bounded activation while preserving instruction, decision and verification gates.

LifecycleDiscover -> Surface -> Decide -> Execute -> Verify
ScaleAgent, runtime, workflow, ecosystem

Working output: An activation path connecting discovery, relevance, authorization and verification.

Start with this question

What must be true before this capability is allowed to act?

Link to this pattern
Comparative evaluation

Method and reasoning evaluation

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.

LifecycleObserve -> Compare -> Clarify -> Verify
ScaleReasoning run, experiment, method design

Working output: A comparison record preserving independent first-pass evidence and differences in reasoning quality.

Start with this question

Was the baseline recorded before the method influenced the attempt?

Link to this pattern
Composition grammar

Five roles for assembling a solution

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.

FRAME -> ORIENT -> REASON -> GOVERN -> DISCOVER / ACTIVATE -> VERIFY / RE-ENTER
Frame

Preserve the problem before narrowing it

Keep ambiguity, independent baselines and plausible possibilities available long enough to avoid premature collapse.

Orient

Know what the subject is

Acquire bounded context, resolve identity and relationships, and keep representation separate from source authority.

Govern

Bound decisions and execution

Separate lifecycle gates, execution discipline and instruction contracts so model output does not silently become completed action.

Discover / activate

Reuse capability before creating more

Find existing realization surfaces, reconcile what exists where, and separate discoverability from bounded activation.

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.

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.

  1. Start from the observed problem, not from a preferred method name.
  2. Add orientation capabilities when identity, provenance, scope or authority is uncertain.
  3. Add independent-baseline or claim-grading capabilities when the evaluation itself can be biased.
  4. Add execution-control capabilities only when decisions can become actions or authoritative artifacts.
  5. Add capability-discovery and activation capabilities when the problem concerns reuse, visibility or bounded invocation.
  6. 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.