🔍 Analysis Architecture

Two-pass reflection system for extracting surface and structural metadata from signals.

What is Analysis?

Analysis in Autonomy processes raw signal content through LLM-powered reflection to extract structured metadata. This metadata enables pattern recognition, clustering, and synthesis across signals.

Analysis operates in two distinct passes, each targeting a different layer of signal structure:

Pass 1: Surface Reflection

Observable narrative elements — what happened, who/what was involved, where it occurred.

Output fields: title, summary, environment, temperature, density, actions, entities, tags

Pass 2: Structural Reflection

Underlying architecture — energetic state, ontological position, symbolic elements, engaged subsystems.

Output fields: energy, state, orientation, substrate, ontological_states, symbolic_elements, subsystems, dominant_language

System Architecture

Prompt Structure

Each analysis pass constructs prompts from multiple template files:

invocation.md

Universal framing — defines Autonomy Realms context, epistemic principles, prohibited reductions

realm.md

Realm-specific instructions from realm_llm_settings.realm_context

surface/system.md or structure/system.md

Pass-specific system instructions

surface/user.md or structure/user.md

User prompt with signal content, questions, and response format

surface/questions.json or structure/questions.json

Field-specific extraction prompts

Response Format

Both passes return structured JSON. The system strips markdown code fences and parses the response into database fields.

Surface Response:

{
  "title": "...",
  "summary": "...",
  "environment": "...",
  "temperature": 0.5,
  "density": 0.7,
  "actions": ["..."],
  "entities": [
    {
      "name": "...",
      "type": "people|places|...",
      "context": "..."
    }
  ],
  "tags": ["..."]
}

Structure Response:

{
  "energy": "...",
  "state": "...",
  "orientation": "...",
  "substrate": "...",
  "ontological_states": ["..."],
  "symbolic_elements": ["..."],
  "subsystems": ["..."],
  "dominant_language": ["..."]
}

Model Router

ModelRouter abstracts LLM API calls. Supports Claude (Anthropic), OpenAI, and local models (Ollama-compatible).

Each realm configures LLM accounts in realm_llm_accounts table with provider, API key, model, and enabled status.

Supported Providers:

claude — Anthropic API (recommended)
openai — OpenAI API
local — Ollama or vLLM

Analysis History

Every analysis pass is logged to signal_history with full prompts, responses, token counts, and errors.

{
  "type": "analysis_surface" | "analysis_structure",
  "timestamp": "2025-01-07T...",
  "account_id": "...",
  "model": "claude-sonnet-4",
  "system_prompt": "...",
  "user_prompt": "...",
  "response": "...",
  "tokens": 1234,
  "fields_updated": ["title", "summary", ...],
  "error": null
}

Surface Layer Fields

Field	Type	Description
signal_title	string	Clear, descriptive title (under 10 words)
signal_summary	string	Third-person narrative summary of what happened
signal_environment	string	Physical/digital setting description (max 500 chars)
signal_temperature	decimal	Intensity/volatility (0.0 = calm, 1.0 = highly charged)
signal_density	decimal	Information density (0.0 = sparse, 1.0 = compressed)
signal_actions	object	Actions across temporal layers: performed (during signal), referenced (past actions discussed), planned (future intentions)
signal_entities	array	Named entities with type and context
signal_tags	array	3-7 semantic tags for categorization

Structural Layer Fields

Field	Type	Description
signal_energy	string	Energetic quality (e.g., grounded, turbulent, focused)
signal_state	string	Condition/phase (e.g., stable, transitional, rupturing)
signal_orientation	string	Directional phrase (e.g., toward sovereignty, building infrastructure)
signal_substrate	string	2-3 sentence description of underlying thesis/architecture
signal_ontological_states	array	2-4 ontological conditions (e.g., sovereign, embedded, coherent)
signal_symbolic_elements	array	Symbolic/archetypal elements as field markers
signal_subsystems	array	Engaged subsystems with contextual role (e.g., 'financial (constraint boundary)', 'relational (functional contrast)')
signal_dominant_language	array	2-4 language domains (technical, architectural, ecological, etc.)

Customization

Realm-Specific Instructions

Configure realm_context in realm_llm_settings to provide realm-specific framing for analysis.

This context is injected into every analysis pass via realm.md template.

Signal Annotations

User notes in signal_annotations.user_notes are automatically included in analysis prompts as high-priority context.

Format: [{note: string, timestamp: ISO}]

Modifying Prompts

All prompt templates are in lib/prompts/analyze/

File Structure:

lib/prompts/analyze/
├── invocation.md
├── realm.md
├── surface/
│   ├── system.md
│   ├── user.md
│   └── questions.json
└── structure/
    ├── system.md
    ├── user.md
    └── questions.json

Adding Analysis Fields

1. Add field to Signal schema in prisma/schema.prisma
2. Run npx prisma migrate dev
3. Update questions.json to extract new field
4. Update response parser in AnalysisService
5. Update UI to display new field

Synthesis Pattern

The analysis architecture is also used for synthesis — cluster-level pattern recognition that operates on aggregated signals.

Synthesis uses the same prompt structure (invocation → realm → system → user → questions) but processes multiple signals to generate:

Mirror synthesis: Structural reflection on patterns across signals
Myth synthesis: Archetypal and symbolic pattern recognition
Narrative synthesis: Coherent narrative construction from signal sequence

See Synthesis documentation for implementation details.

Design Principles

Two passes, not one unified analysis

Surface and structural layers serve distinct purposes. Separating them produces cleaner extraction and allows independent re-analysis.

Structural precision over narrative embellishment

Analysis prompts enforce factual field mapping and pattern recognition, not interpretation or emotional overlay.

Full auditability via history logging

Every analysis pass stores complete prompts and responses. Users can inspect what the model saw and regenerate if needed.

Realm sovereignty in framing

realm_context allows each realm to define its own analytical lens without modifying core prompts.