Thought Analysis Framework

Guide

Decoding the Thought Stream

We cannot evolve a system based on "raw text." We must parse thoughts into architectural primitives. This guide explains the mechanism of translating human intent into system structure.

0. Interactive Playground

The interactive playground has been moved to a dedicated full-screen tool for better usability and analysis history.

1. The Core Primitives

Every thought stream, no matter how chaotic, contains four fundamental signals that the system must extract. We group Ambiguity under Tension because uncertainty is a form of cognitive friction.

The Tension

The Fuel. A signal of friction or gap between the Mental Model and Reality.

Types:

  • Semantic (Ambiguity): "I don't have the words for this."
  • Structural: "This feature is missing."
  • Logical: "These rules contradict."

The Intent

The Vector. A directional desire for a future state.

Input State: "I want..."
Output State: Proposition ("We should...")

Intent is the motivation; Proposition is the formalized claim.

The Concept

The Structure. A bounded definition of a "thing" (Noun).

  • "A 'Session'..."
  • "The 'Workspace'..."

The Invariant

The Anchor. A rule or truth that must remain stable.

  • "Data must never be deleted..."
  • "Complex systems evolve from simple ones..."

2. Case Study: Parsing a Single Thought

Let's analyze a real thought from the stream to see how the parser breaks it down. This example is backed by a typed data structure defined in thought-analysis-types.ts.

Component vs. Subsystem

ID: result-case-study-001Draft
Input Stream
"what if we state that a component on a value chain can map 1to1 to a subsystem. this would align with hierarchy in systems theory, defining that complex systems evolve from simple systems. Subsystems -> Systems -> Suprasystems. This would lead to the conculusion that for each part of a system (a subsystem or component?) sensory (to monitor the internals) and levers (to control) are required.
Extracted Primitives
Tension (Semantic)Component vs. Subsystem
ComponentSubsystem
Intentmap components 1to1 to subsystemsSystem Architecture
Design Hypothesis
Proposition

If we treat Component as Subsystem, it inherits System Theory hierarchy

Expected Outcome

Components gain Sensors and Levers for observability and control

Theoretical Basis

Gall's Law / Systems Theory

cf. John Gall, Systemantics (1975)

Predictions
  • All Components will have observable internal state (Sensors)
  • All Components will expose control parameters (Levers)
  • Recursive composition will be possible (Subsystem -> System -> Suprasystem)
Falsifiability (Failure Condition)

Fails if a trivial component (e.g., a Button) requires no internal state or control

System Mutationsvoid-architecture
ModifyComponent
Add Sensors and Levers fields to the Component type.
Analyzed: 2026-01-24
Backed by System Model

3. From Hypothesis to Architecture

The output of parsing a thought is not a "Ticket" (work to be done). It is a Design Hypothesis (a testable proposition about system structure). This distinction is critical for evolutionary architecture.

Key Concept: Intent → PropositionRaw Intent ("I want X") is subjective. To build a system, we must formalize it into a Proposition ("If we build Y, we achieve X"). This transformation is the core job of the parser.

The Design Hypothesis

An atomic unit of potential system evolution. It is not yet a fact; it must be validated.

01
PropositionThe formalized Intent. "If we structure X as Y, then Z follows."
02
Prediction"This structure will enable feature A and prevent bug B."
03
Falsifiability"This hypothesis fails if condition C is met."

Step 1: Raw Thought

Input stream. Chaotic, unstructured, high-volume.

Step 2: Design Hypothesis

You are here. A parsed, testable proposition.

Step 3: Validation

Prototyping, debate, or simulation to test the hypothesis.

Step 4: ADR / System Axiom

Accepted structure. Becomes an Architectural Decision Record.

4. The Missing Dimensions

The basic parser captures the Logic, but logic is not enough for a living system. To fully understand a thought, we need to capture the context and emotion.

Temporal Context

Why it matters: Thoughts don't exist in a vacuum. Knowing what triggered this thought (e.g., "Frustration with current code") changes how we prioritize it.

Affective Signal

Why it matters: "wowowowow!!!" is a high-confidence signal. A dry statement is low-confidence. We prioritize high-energy insights.

Falsifiability

Why it matters: We must ask "What would prove this wrong?". Without this, we build on fragile assumptions.

5. The Type System

The framework is not just conceptual—it is backed by a precise TypeScript type system. This enables machine parsing, validation, and traceability.

thought-analysis-types.ts
// Core Primitives
type TensionType = 'Semantic' | 'Structural' | 'Logical';

interface Tension {
  type: TensionType;
  description: string;
  conflictingTerms?: [string, string];
}

interface Intent {
  rawExpression: string;
  targetDomain?: string;
}

interface Proposition {
  claim: string;              // "If we structure X as Y..."
  expectedOutcome: string;    // "...then Z follows."
  derivedFromIntent: Intent;  // Traceability
}

// The Design Hypothesis
interface DesignHypothesis {
  id: string;
  proposition: Proposition;
  predictions: string[];
  falsifiability: string;
  theoreticalBasis?: { source: string; citation?: string };
  tensions: Tension[];
  status: 'Draft' | 'UnderReview' | 'Validated' | 'Invalidated';
}
Primitives
  • • Tension
  • • Intent
  • • Concept
  • • Invariant
Aggregate
  • • ParsedThought
  • • Proposition
  • • DesignHypothesis
Context
  • • TemporalContext
  • • AffectiveSignal
  • • ThoughtActor

6. Applied Examples

More examples of applying the framework to real thoughts. These demonstrate how Conceptual Tensions translate into concrete System Changes.

The Pull Mechanism

ID: result-pull-mechanism-001Draft
Input Stream
"creating a component generates the pull to make it exist. evolving an existing component generates the pull to realign and adjust the models and concepts and taxanomy.
Extracted Primitives
Tension (Semantic)The term "pull" is used metaphorically but not formally defined in the taxonomy.
PullDemand
Tension (Structural)There is no current mechanism that "generates pull" when a Component is created or evolved.
IntentComponents should generate demand for their own existence when createdComponent Lifecycle
IntentEvolving a Component should trigger realignment of related Models, Concepts, and TaxonomySystem Coherence
ConceptPullNEWA force or demand generated by the creation or evolution of a Component, which triggers downstream work to make the Component real or to realign related artifacts.
ConceptRealignmentNEWThe process of adjusting Models, Concepts, and Taxonomy when a Component evolves, to maintain coherence across the system.
InvariantCreation creates demand. A new Component cannot exist in isolation; it pulls related work into existence.Theory(Implied from Systems Theory: parts require context.)
InvariantEvolution requires realignment. Changing a Component must cascade to dependent artifacts.Axiom(Coherence Principle: The whole must remain internally consistent.)
Design Hypothesis
Proposition

If we introduce a "Pull Mechanism" that activates on Component creation/evolution, then the system becomes self-organizing

Expected Outcome

Creating a Component will automatically generate requirements; modifying a Component will identify and queue affected artifacts for realignment.

Theoretical Basis

Systems Theory / Demand-Pull Systems

cf. Lean Manufacturing (Taiichi Ohno): Pull systems vs. Push systems.

Predictions
  • Creating a new Component will generate at least one "Pull" task (e.g., define in Taxonomy).
  • Modifying an existing Component will identify affected Models and Concepts.
  • The system will track a queue of "pending pulls" that need resolution.
  • Coherence will improve because changes cascade explicitly, not silently.
Falsifiability (Failure Condition)

Fails if a Component can be created without any downstream work. Fails if Component modifications do not require realignment of any artifact.

System Mutationsvoid-architecture
AddComponent
Introduce "Pull Mechanism" as a new Component that observes Component lifecycle events.
AddRelation
Component --[Triggers]--> Pull Mechanism (on create/evolve)
AddRelation
Pull Mechanism --[Triggers]--> Taxonomy (realignment)
Analyzed: 2026-01-24
Backed by System Model

Ugly Website Pipeline

ID: result-ugly-pipeline-001Draft
Input Stream
"i should start a new project where i use web crawling and generative AI to design new websites for really ugly old websites of businesses i find in my town. for 5min of work i can send a 500€ quote to the owner with a pitch persuading him that he needs a new website.
Extracted Primitives
Tension (Structural)There is no automated pipeline to discover, redesign, and pitch websites.
Tension (Alignment)"Persuading" implies sales tactics. Does this align with authentic value delivery, or is it manipulation?
PersuasionAuthenticity
Tension (Epistemic)How do we define "ugly"? Is visual quality measurable by a machine, or is this a subjective heuristic?
IntentAutomate the discovery and redesign of outdated business websites to generate leadsRevenue / Lead Generation
IntentMinimize effort per lead (target: 5 minutes)Efficiency
IntentGenerate high-value quotes (€500 per lead)Monetization
IntentTarget local businesses for geographic focusMarket Strategy
ConceptUgly Website PipelineNEWAn automated system that crawls the web for outdated/low-quality business websites, generates AI-powered redesigns, and produces personalized sales pitches.
ConceptWeb CrawlerA component that discovers local business websites by scraping directories, maps, or search results.
ConceptAI RedesignerNEWA generative AI component that takes a screenshot of an existing website and produces a modern redesign mockup.
ConceptPitch GeneratorNEWA component that produces a personalized sales email/quote for the business owner, including the redesign mockup.
InvariantHigh leverage: Low effort must produce high value.Axiom(80/20 Principle (Pareto))
InvariantVisual quality is assessable: A website can be scored on modernity, usability, and aesthetics.Theory(UX Heuristics (Nielsen Norman Group))
InvariantCold outreach requires genuine value, not manipulation.Axiom(Ethical Sales (implicit project value))
Design Hypothesis
Proposition

If we build an automated Ugly Website Pipeline (Crawler → AI Redesigner → Pitch Generator), then we can generate qualified leads with minimal effort

Expected Outcome

5 minutes of work produces a €500 quote opportunity

Theoretical Basis

Lean Startup / Cold Outreach

cf. Eric Ries (Lean Startup), Aaron Ross (Predictable Revenue)

Predictions
  • Each lead requires ≤5 minutes of human effort.
  • €500 quotes are accepted at ≥5% conversion rate.
  • AI redesigns are perceived as valuable by business owners.
  • The pipeline scales to multiple geographic regions.
Falsifiability (Failure Condition)

Fails if: (1) Effort per lead exceeds 15 minutes, (2) Conversion rate is <1%, (3) Business owners perceive outreach as spam, or (4) AI redesigns are not compelling.

System Mutationsugly-website-pipeline
AddComponent
Introduce "Web Crawler" to discover local business websites.
AddComponent
Introduce "AI Redesigner" to generate modern mockups.
AddComponent
Introduce "Pitch Generator" to create personalized outreach.
AddRelation
Web Crawler --[Produces]--> AI Redesigner (website data)
AddRelation
AI Redesigner --[Produces]--> Pitch Generator (mockup)
Analyzed: 2026-01-24
Backed by System Model

Opera Discovery App

ID: result-opera-app-001DraftHypothesis
Affect: High
Input Stream
"I want to build an Opera app, where enthusiasts and new visitors can discover content around the different operas and locations. Also, background information related to actors and episodes. This would really make me happy, to do that, but I don't know how to do that.
Extracted Primitives
Tension (Epistemic)"I don't know how to do that." The Thinker explicitly signals a capability/knowledge gap. This is not a system design tension—it is a learning requirement.
Tension (Structural)There is no Opera discovery app currently. The system must be designed from scratch.
Tension (Semantic)"Episodes" is not standard Opera terminology. Operas have Acts, Scenes, or Performances—not episodes. Is this a metaphor (like TV episodes) or a domain term misuse?
EpisodesActs/Scenes/Performances
Tension (Semantic)"Actors" in opera are typically called Singers, Performers, or by voice type (Soprano, Tenor). Is "actor" intentional (stage presence) or a vocabulary slip?
ActorsSingers/Performers
Tension (Alignment)"Enthusiasts AND new visitors" have different needs. Enthusiasts want depth; newcomers want accessibility. Can one app serve both, or does this create UX tension?
IntentBuild an Opera discovery app for content explorationProduct / Passion Project
IntentEnable content discovery around operasCore Feature
IntentProvide location-based opera informationFeature
IntentInclude background on performersFeature
IntentServe both enthusiasts and newcomersAudience Strategy
IntentExperience personal fulfillment through creationMotivation
ConceptOpera Discovery AppNEWA mobile or web application enabling users to explore operas, venues, performers, and related content.
ConceptOperaA dramatic art form combining orchestral music, vocal performance, and theatrical staging. Structured into Acts and Scenes.
ConceptVenue / LocationAn opera house, theater, or performance space where operas are staged.
ConceptPerformerA singer, conductor, or stage artist involved in opera productions. Replaces ambiguous "actor."
ConceptProduction / PerformanceA specific staging of an opera at a venue on a date. Replaces ambiguous "episode."
InvariantContent must be accessible to newcomers without alienating enthusiasts.Axiom(Universal Design Principle)
InvariantDomain terminology must be accurate. Opera has its own vocabulary.Axiom(Domain-Driven Design (Eric Evans))
InvariantPersonal fulfillment is a valid and sustainable driver for creation.Axiom(Intrinsic Motivation Theory (Deci & Ryan))
Enriched Context
Trigger
Insight
Audience
Self
Actor
Thinker
Coherence Cost
Medium
"This would really make me happy""but I don't know how to do that"
Design Hypothesis
Proposition

If we build a structured Opera Discovery App with entities for Operas, Venues, Performers, and Productions, then users (enthusiasts and newcomers) can explore the art form

Expected Outcome

Users will engage with opera content, discover new works, and develop appreciation for the art form

Theoretical Basis

Content Discovery / Cultural Tech

cf. Spotify (music discovery), IMDB (film database)

Predictions
  • Users will spend >5 minutes per session exploring content.
  • Newcomers will report feeling "less intimidated" by opera.
  • Enthusiasts will discover operas/performers they didn't know.
  • The app will have a Net Promoter Score (NPS) > 40.
Falsifiability (Failure Condition)

Fails if: (1) Users bounce within 30 seconds, (2) Enthusiasts find content too shallow, (3) Newcomers find content too jargon-heavy, or (4) Data model cannot represent opera complexity.

System Mutationsopera-discovery-app
AddComponent
Introduce "Opera (Entity)" to represent individual operas.
AddComponent
Introduce "Venue (Entity)" to represent performance locations.
AddComponent
Introduce "Performer (Entity)" to represent artists.
AddComponent
Introduce "Production (Entity)" to represent specific stagings.
AddRelation
Opera --[HasMany]--> Productions
AddRelation
Venue --[Hosts]--> Productions
AddRelation
Performer --[PerformsIn]--> Productions
Analyzed: 2026-01-24
Backed by System Model