Apply a systems thinking model to the current problem.

IMPORTANT: The "analysis" parameter is your narrative analysis text. The "findings" parameter is a JSON object where keys are the model's required field names and values are your findings for each. Do NOT pass finding fields as top-level parameters — they must be nested inside the "findings" object.

Example call structure: { "sessionId": "abc123", "modelId": "stock-and-flow", "analysis": "Your narrative analysis through this lens...", "findings": { "stocks": "Your finding about stocks...", "inflows": "Your finding about inflows...", "outflows": "Your finding about outflows...", "equilibrium_analysis": "Your finding about equilibrium..." } }

Available models: blast-radius (Blast Radius), contract-boundaries (Contract Boundaries), conways-law (Conway's Law), coupling-cohesion (Coupling & Cohesion), data-transformation-fidelity (Data Transformation Fidelity), error-propagation (Error Propagation), failure-modes (Failure Modes), idempotency (Idempotency), kiss (KISS), modularity (Modularity), separation-of-concerns (Separation of Concerns), state-ownership (State Ownership), causal-loop-diagrams (Causal Loop Diagrams), feedback-loops (Feedback & Feedforward Loops), local-vs-global (Local vs Global Optimization), source-sink (Source & Sink), stock-and-flow (Stock & Flow), system-dynamics (System Dynamics), buffers (Buffers & Buffer Sizing), constraints (Constraint Analysis), leverage-points (Leverage Points), migration (Migration), queuing-theory (Queuing Theory), domain-modeling (Domain Modeling Lens), event-driven (Event-Driven Lens), functional (Functional Lens), adversarial (Adversarial Analysis), build-vs-buy (Build vs. Buy), circle-of-competence (Circle of Competence), dependency-risk (Dependency Risk), goodharts-law (Goodhart's Law), hanlons-razor (Hanlon's Razor), inversion (Inversion), map-vs-territory (Map vs Territory), margin-of-safety (Margin of Safety), occams-razor (Occam's Razor), reversibility (Reversibility), second-order-thinking (Second-Order Thinking), back-pressure (Back Pressure), error-budgets (Error Budgets), graceful-degradation (Graceful Degradation), observability-gaps (Observability Gaps), operational-complexity (Operational Complexity), denormalization (Denormalization), normalization (Normalization), attack-surface (Attack Surface), cia-triad (CIA Triad), defense-in-depth (Defense in Depth), least-privilege (Principle of Least Privilege), trust-boundaries (Trust Boundaries), binary-search (Binary Search), bottom-up (Bottom-Up), caches (Caches), parallelism (Parallelism), top-down (Top-Down), whats-changed (What's Changed)

IMPORTANT: Do NOT stop after one lens. Apply 2-4 lenses per session to get genuine multi-perspective insight. The response includes prior findings from earlier lenses — use these to identify connections and build on previous analysis. When you've built enough perspective, call synthesize to integrate across lenses.

Can be called multiple times per session. Allowed after synthesize.

Get full details for selected models plus their graph neighbors and counterbalances.

Call after start_analysis with the model IDs you've chosen. Returns:

• Full model details (guiding questions, required fields) for your selection

• Graph neighbors (related models one hop away) with relationship reasons

• Counterbalances (opposing perspectives) with tension descriptions

• Uncovered categories to highlight analytical gaps

Use this to review your selection before committing to apply_lens calls.

Get a predefined analysis strategy. Strategies define which concerns to cover and how to approach them, without prescribing specific models.

Available strategies: capacity-planning (Capacity Planning), code-review (Code Review), codebase-understanding (Codebase Understanding), incident-investigation (Incident Investigation), post-mortem (Post-Mortem), security-audit (Security Audit), system-design (System Design), technical-decision (Technical Decision)

Call without strategyId to list all strategies. Call with a strategyId to get the concern map.

Strategies work for any system — code, infrastructure, pipelines, platforms, or design documents. For example, system-design applies equally to a Kubernetes migration plan as to a code architecture spec.

USAGE: Get a strategy, then for each concern: evaluate relevance to your specific problem, use expand_selection with models from that concern's domain, pick appropriate lenses, and apply them. Concerns marked "required" should always be evaluated. "Conditional" concerns depend on the scale and nature of the change. Each concern can be run in parallel as an independent analysis track.

Begin a systems thinking analysis session. Returns model clusters organized by category for you to review and select from.

BEFORE calling this, consider whether a predefined strategy fits your use case. Call get_strategy (with no arguments) to see available strategies.

THE EXPECTED WORKFLOW IS:

1. start_analysis → review clusters, pick relevant models

2. expand_selection → get full details + graph neighbors for your picks

3. apply_lens (2-4 times) → apply your chosen lenses

4. synthesize → integrate findings

The value is in COMPOSING multiple perspectives. Apply at least 2-3 lenses before synthesizing.

Synthesize findings across all applied lenses into a unified view. This is the payoff — where cross-lens connections become actionable insight.

Call after applying 2+ lenses. Your synthesis should integrate findings across lenses: where did different perspectives agree (reinforcing confidence), where did they contradict (revealing tension), and what gaps remain? The best syntheses surface connections that no single lens would have found.

Provide concrete, actionable recommendations grounded in the multi-lens evidence. Note contradictions explicitly — they often point to the most important design tensions. Note gaps — they suggest which lenses to apply next if deeper analysis is needed.

The session stays open after synthesis. If the synthesis reveals gaps, apply more lenses and synthesize again.