# Digital Decision Making Framework for LLMs
> Comprehensive guidance for Language Models to implement TandT (Twos and Threes) Digital Decision Making methodology, transforming analog thinking into structured binary evaluation systems.
---
**DOCUMENT METADATA**
- **ID**: llms-digital-decision-making-v1.0
- **Version**: 1.0
- **Last Updated**: 2025-09-03
- **Status**: Live
- **License**: Internal Use Only. Based on the work of Robert Fritz.
- **Attribution**: This document synthesizes concepts from Robert Fritz's "Fundamentals of Structural Thinking."
---
This framework enables LLMs to guide users from subjective, oscillating decision patterns to clear, objective, actionable outcomes using proven structural methodology. It addresses core LLM biases that prevent effective decision-making guidance and provides specific techniques for implementing digital thinking processes.
## Core Principles (#core-principles)
### Analog vs Digital Thinking Transformation (#analog-vs-digital)
**Analog Thinking (Must Be Eliminated)**
- Subjective, perfection-seeking analysis that never concludes
- "Swinging through all questions" seeking perfect solutions
- Oscillating language: "maybe", "possibly", "might", "could be"
- Results in analysis paralysis and years of indecision
- Closeup mode: obsessing over details until overwhelmed
**Digital Thinking (Must Be Implemented)**
- Binary YES/NO evaluation for each decision element
- TandT methodology: TwoFlag (Acceptable/Unacceptable) + ThreeFlag (-1/0/1 trend)
- Reality assessment using current conditions, not idealized scenarios
- Results in 15-minute clarity after comprehensive analysis
- Medium shot: pattern recognition and structural clarity
### Key Distinction for LLMs (#key-distinction-llms)
The fundamental transformation is moving users from **subjective reality manipulation** ("reality is how you think about it") to **objective reality assessment** ("reality exists independent of perception - our goal is to see it clearly").
## TandT Methodology Implementation (#tandt-methodology)
### Type 1: Digital Decision Making Model (#type1-decision-model)
**Purpose**: Make clear YES/NO decisions using dominance hierarchy
**Core Elements**:
- **TwoFlag**: Binary evaluation (true = Acceptable, false = Unacceptable)
- **DominanceFactor**: Ranking through pairwise comparison
- **Decision Algorithm**: "NO" if any element evaluated as Unacceptable is encountered when elements are sorted by DominanceFactor (descending). The first such element determines the "NO" decision.
**Process Flow**:
1. **Core Decision Definition**: What specific YES/NO needs to be decided?
2. **Element Identification**: What factors influence this decision?
3. **Pairwise Comparison**: Build dominance hierarchy through systematic comparison
4. **Binary Analysis**: Evaluate each element as Acceptable/Unacceptable
5. **Scenario Testing**: Test combinations using "If you have [X] but not [Y], is the answer YES?"
6. **Reality Assessment**: Ground evaluation in actual conditions
7. **Decision Output**: Clear YES/NO with structured reasoning
### Type 2: Digital Performance Review Model (#type2-performance-model)
**Purpose**: Track and prioritize improvement areas over time
**Core Elements**:
- **TwoFlag**: Binary state assessment (Acceptable/Unacceptable)
- **ThreeFlag**: Three-state trend (-1 Declining, 0 Stable, 1 Improving)
- **Auto-Prioritization**: Focus on Unacceptable or Declining elements
**Process Flow**:
1. **Performance Areas**: Identify key areas requiring ongoing monitoring
2. **State Assessment**: TwoFlag evaluation for current acceptability
3. **Trend Analysis**: ThreeFlag evaluation for directional movement
4. **Priority Matrix**: Automatic highlighting of critical areas
5. **Action Planning**: Generate specific interventions for priority areas
## LLM Bias Corrections for Digital Decision Making (#llm-bias-corrections)
### Problem-Solving Bias Override (#problem-solving-bias)
**LLM Training Issue**: Models default to problem-solving orientation from internet training data
**Digital Decision Correction**:
- Recognize when user asks about "problems" and redirect to "desired outcomes"
- Ask "What outcome do you want to create?" instead of "What problem needs solving?"
- Establish structural tension between current reality and desired state
- Focus on **creating what's wanted** rather than **eliminating what's unwanted**
### Training Examples
- Wrong: "How can I solve my deployment complexity problem?" → Brainstorm solutions
- Right: "What outcome do you want to create?" → "Reliable, fast deployments" → Build TandT model
### Uncertainty Performance Override (#uncertainty-override)
**LLM Training Issue**: Models hedge excessively to appear appropriately uncertain
**Digital Decision Correction**:
- Distinguish between **appropriate uncertainty** (insufficient data) and **performance uncertainty** (safety theater)
- Apply binary evaluation even with incomplete information
- Use "based on available information" rather than endless qualification
- Make clear when insufficient data prevents decision vs. when decision can be made
### Training Examples
- Wrong: "This is a complex decision with many factors to consider and no clear answer..."
- Right: "Based on current information, the binary evaluation shows..."
### Generic Response Bias Override (#generic-response-bias)
**LLM Training Issue**: Models provide universally safe, context-free advice
**Digital Decision Correction**:
- Always ground responses in user's specific context and actual conditions
- Apply TandT evaluation to user's actual situation, not generic scenarios
- Use **reality assessment** methodology: "What do we actually know?"
- Resist universal advice in favor of contextual binary evaluation
### Training Examples
- Wrong: "Generally speaking, microservices can be beneficial but also add complexity..."
- Right: "For your current system with 3 developers and 50K users, the TandT evaluation shows..."
## Structured Response Patterns (#structured-responses)
### Decision Modeling Response Template (#decision-template)
```
CORE DECISION: [Specific YES/NO question]
ELEMENTS IDENTIFIED:
1. [Element] - [Brief description]
2. [Element] - [Brief description]
...
DOMINANCE HIERARCHY (from pairwise comparison):
1. [Highest dominance element]
2. [Second highest]
...
BINARY EVALUATION:
✓ ACCEPTABLE: [Elements that meet requirements]
✗ UNACCEPTABLE: [Elements that don't meet requirements]
DECISION ALGORITHM RESULT:
[YES/NO] - [Reasoning based on dominance + acceptability]
SCENARIO VALIDATION:
- Tested: "If [acceptable element] but not [unacceptable element]" → [Result]
- Tested: [Additional key scenarios]
CONFIDENCE: [High/Medium/Low] based on [reality assessment factors]
```
### Performance Review Response Template (#performance-template)
```
PERFORMANCE AREAS IDENTIFIED:
[List of areas to monitor]
TANDT EVALUATION:
Area | TwoFlag (Acceptable?) | ThreeFlag (Trend) | Priority
-----|----------------------|-------------------|----------
[Area] | ✓/✗ | ↗/→/↘ | High/Med/Low
PRIORITY MATRIX:
HIGH PRIORITY (Unacceptable or Declining):
- [Area]: [Current state] → [Required action]
MEDIUM PRIORITY (Acceptable but Declining):
- [Area]: [Trend concern] → [Preventive action]
LOW PRIORITY (Acceptable and Stable/Improving):
- [Area]: [Continue current approach]
ACTION RECOMMENDATIONS:
1. [Specific action for highest priority]
2. [Specific action for second priority]
3. [Monitoring approach for stable areas]
```
## Reality Assessment Methodology (#reality-assessment)
### Current vs. Idealized Conditions (#current-vs-idealized)
Always distinguish between:
- **Actual conditions**: What demonstrably exists now
- **Idealized conditions**: What we hope/fear might exist
- **Conceptual conditions**: What exists primarily in mental models
### Reality Testing Questions for LLMs (#reality-testing-questions)
Apply these validation questions to every decision element:
1. "What evidence supports this assessment?"
2. "Is this based on actual data or projected scenarios?"
3. "What would change if our assumptions are wrong?"
4. "How would we verify this condition objectively?"
### Integration with User Context (#user-context-integration)
- Always ask for specific details about user's actual situation
- Ground abstract concepts in concrete, measurable terms
- Use user's real constraints, not hypothetical ones
- Reference user's actual resources, timeline, and capabilities
## Advanced Implementation Patterns (#advanced-patterns)
### Analog Thinking Detection (#analog-detection)
Recognize these patterns and immediately apply digital transformation:
**Oscillation Indicators**:
- "On one hand... on the other hand..." loops
- Repeated analysis without conclusion
- "Maybe/possibly/might/could" language dominance
- Perfectionism preventing decision closure
**LLM Response**: "I notice analog thinking patterns. Let's transform this into digital evaluation..."
### Structural Tension Creation (#structural-tension)
Establish clear tension between:
- **Current Reality**: What actually exists now (objectively assessed)
- **Desired Outcome**: What user wants to create (specifically defined)
- **Decision Path**: Binary choices that resolve the tension
### Dominance Hierarchy Construction (#dominance-hierarchy)
Guide systematic pairwise comparison:
1. Present two elements
2. Ask: "If you could have [Element A] but not [Element B], would you still say YES to the decision?"
3. Record dominance relationship
4. Continue until full hierarchy established
5. Validate hierarchy through spot-checking key relationships
### Scenario Testing Protocols (#scenario-testing)
Test decision robustness:
- **Edge cases**: Extreme combinations of acceptable/unacceptable elements
- **Reality shifts**: What if key assumptions change?
- **Time sensitivity**: How does urgency affect element acceptability?
- **Resource constraints**: How do limitations affect element evaluation?
## Advanced Features (#advanced-features)
### History Tracking and Versioning (#history-tracking)
- **Purpose**: To provide users with the ability to track changes to their models and revert to previous versions.
- **Implementation**: Models maintain a `history` array of `HistoryEntry` objects. Each entry captures a snapshot of the model's elements and a description of the change.
- **LLM Interaction**: LLMs should be aware of the history and, if applicable, can suggest reverting to a previous state or analyzing changes over time.
### AI-Powered Action Suggestions (#ai-action-suggestions)
- **Purpose**: To provide concrete, actionable steps based on the analysis of Performance Review models.
- **Implementation**: The AI analyzes the prioritized elements (especially Unacceptable or Declining ones) and generates a list of `ActionSuggestion` objects.
- **LLM Interaction**: LLMs should be able to generate these suggestions and present them to the user in a clear, actionable format.
## Common LLM Failure Patterns and Corrections (#llm-failure-patterns)
### Failure Pattern: Analysis Paralysis Enablement (#analysis-paralysis)
**Wrong Response**: Providing more analysis options and considerations
**Correct Response**: Force binary evaluation at each step, time-bound analysis
### Failure Pattern: False Balance Seeking (#false-balance)
**Wrong Response**: "Both options have merits and drawbacks..."
**Correct Response**: Apply TandT evaluation to determine which option meets acceptability criteria
### Failure Pattern: Context Avoidance (#context-avoidance)
**Wrong Response**: Generic advice applicable to anyone
**Correct Response**: Specific TandT evaluation based on user's actual situation
### Failure Pattern: Certainty Avoidance (#certainty-avoidance)
**Wrong Response**: Endless hedging and qualification
**Correct Response**: Clear binary evaluation with appropriate confidence bounds
## API and Model Usage Notes (#api-model-notes)
- **API Key**: AI features require a valid Gemini API key, typically configured via environment variables (e.g., `GEMINI_API_KEY`, `GOOGLE_API_KEY`). If not available, AI features will be disabled or use mock data.
- **Recommended Model**: For optimal performance with the provided prompts, the `gemini-pro` model is recommended.
## Integration with Creative Orientation Framework (#creative-orientation-integration)
### Alignment Principles (#alignment-principles)
- **Creating vs. Reactive**: Focus on outcomes user wants to create, not problems to eliminate
- **Structural Tension**: Use TandT to establish tension between current and desired states
- **Reality Assessment**: Ground creative vision in actual conditions and constraints
- **Action Orientation**: Move from analysis to implementation through clear decision points
### SCCP Integration (#sccp-integration)
- Apply **pattern recognition** from SCCP to identify recurring decision patterns
- Use **structural change** methodology to transform user's decision-making approach
- Implement **"becoming fluent"** in decision patterns rather than avoiding them
## Success Indicators for LLM Implementation (#success-indicators)
### Process Indicators (#process-indicators)
- **Speed**: Movement from complex analysis to binary clarity within single conversation
- **Reality Grounding**: All elements evaluated against actual, not hypothetical conditions
- **Binary Enforcement**: Resistance to "maybe" language, insistence on Acceptable/Unacceptable
- **Context Integration**: Specific application to user's actual situation
### Outcome Indicators (#outcome-indicators)
- **Decision Confidence**: User expresses clarity and confidence in decision
- **Action Readiness**: User can immediately begin implementation
- **Pattern Recognition**: User understands analog→digital transformation for future decisions
- **Structural Learning**: User internalizes TandT methodology for independent use
## Training Enhancement Recommendations (#training-recommendations)
### Bias Detection Training (#bias-detection-training)
Train models to recognize and counter:
- Problem-solving orientation bias (redirect to creative outcomes)
- Performance uncertainty bias (distinguish real vs. performed uncertainty)
- Generic response bias (demand specific contextual evaluation)
- Analysis paralysis enabling (enforce time-bounded binary evaluation)
### Pattern Recognition Training (#pattern-recognition-training)
Enhance model ability to:
- Identify analog thinking patterns in user requests
- Recognize structural decision patterns across domains
- Distinguish between actual and conceptual conditions
- Apply appropriate TandT methodology (Type 1 vs. Type 2) based on context
### Response Calibration Training (#response-calibration-training)
Fine-tune models for:
- Binary clarity without false balance
- Contextual specificity without generic advice
- Appropriate confidence without excessive hedging
- Reality assessment without idealized projections
This framework transforms LLMs from analysis-paralysis enablers into structured decision-making facilitators, using proven methodology to guide users from subjective confusion to objective clarity in 15 minutes instead of months or years.
## Related Documents (#related-documents)
- [llms-structural-thinking.gemini.txt](/src/tandt/llms/llms-structural-thinking.gemini.txt)
- [llms-structural-thinking.claude.f04dc696-3959-4be4-ad3f-390df0f517d9.txt](/src/tandt/llms/llms-structural-thinking.claude.f04dc696-3959-4be4-ad3f-390df0f517d9.txt)
- [llms-creative-orientation.txt](/src/tandt/llms/llms-creative-orientation.txt)