Fidelity Management - Timepoint Pro

The Insight

Not all entities and moments deserve equal detail. Fidelity should concentrate around high-centrality entities at critical timepoints—like a map that renders at higher resolution only where you zoom. Key principle: Resolution is heterogeneous and mutable. Queries elevate resolution (lazy loading), disuse allows compression back down.

M1: Heterogeneous Fidelity Graphs

Each (entity, timepoint) pair maintains independent resolution.

Resolution Levels

class ResolutionLevel(str, Enum):
    TENSOR_ONLY = "tensor_only"      # ~200 tokens
    SCENE = "scene"                   # ~500 tokens
    GRAPH = "graph"                   # ~1,000 tokens
    DIALOG = "dialog"                 # ~3,000 tokens
    TRAINED = "trained"               # ~5,000 tokens
    FULL_DETAIL = "full_detail"       # ~8,000 tokens

From schemas.py:11-17

Example Structure

Timepoint(T0, "Constitutional Convention")
├── Entity("washington", resolution=TRAINED, ~50k tokens)
├── Entity("madison", resolution=DIALOG, ~10k tokens)  
├── Entity("attendee_47", resolution=TENSOR_ONLY, ~200 tokens)
└── causal_link → Timepoint(T1)

Token Economics

Without heterogeneous fidelity:

100 entities × 10 timepoints at uniform high fidelity
Cost: ~50M tokens
Per query: ~$500

With heterogeneous fidelity (power-law distribution):

Same scenario with dynamic resolution
Cost: ~2.5M tokens
95% reduction
Per query: ~$25

Real Implementation

class Entity(SQLModel, table=True):
    entity_id: str = Field(unique=True, index=True)
    entity_type: str = Field(default="human")
    timepoint: str | None = Field(default=None, index=True)
    tensor: str | None = Field(default=None, sa_column=Column(JSON))
    training_count: int = Field(default=0)
    query_count: int = Field(default=0)
    eigenvector_centrality: float = Field(default=0.0)
    resolution_level: ResolutionLevel = Field(default=ResolutionLevel.TENSOR_ONLY)
    entity_metadata: dict[str, Any] = Field(default_factory=dict)
    
    # Tensor maturity tracking
    tensor_maturity: float = Field(default=0.0)  # 0.0-1.0
    tensor_training_cycles: int = Field(default=0)

From schemas.py:138-161

Castaway Colony Example

In the same scene:

Commander Tanaka: TRAINED (heavily queried for command decisions)
Engineer Sharma: DIALOG (repair assessments)
Crashed Meridian: TENSOR (background life support tracking)
Navigator Park: TENSOR_ONLY (inactive until queried about pre-crash data)

Four different fidelity levels coexisting in one timepoint.

M2: Progressive Training

Entity quality exists on a continuous spectrum determined by accumulated interaction, not binary cached/uncached state.

Metadata Structure

class EntityMetadata:
    query_count: int              # Times queried
    training_iterations: int      # LLM elaboration passes
    eigenvector_centrality: float # Graph importance (0-1)
    resolution_level: ResolutionLevel
    last_accessed: datetime

Each query increments metadata. When thresholds are crossed, the system triggers elevation—generating richer state representations and storing both compressed and full versions.

Quality Accumulation

Progression path:

TENSOR_ONLY (query=0) 
  → SCENE (query≥2) 
  → GRAPH (query≥5, centrality>0.3) 
  → DIALOG (query≥10, centrality>0.5)
  → TRAINED (query≥20, centrality>0.7)

Quality accumulates; nothing is thrown away.

Castaway Colony Example

Dr. Okonkwo starts at SCENE resolution—a background doctor. As the crew discovers alien flora, xenobiology queries accumulate:

“Is this lichen edible?”
“What’s the toxicity profile?”
“Is the bioluminescence harmful?”

After 3+ queries, he progressively elevates to DIALOG then TRAINED, becoming the most detailed entity in biosphere-related scenes. His quality tracks expertise demand, not pre-assigned importance.

M5: Query-Driven Lazy Resolution

Resolution decisions happen at query time, not simulation time.

Decision Logic

def decide_resolution(entity, timepoint, query_history, thresholds):
    if entity.query_count > thresholds.frequent_access:
        return max(entity.resolution, DIALOG)
    if entity.eigenvector_centrality > thresholds.central_node:
        return max(entity.resolution, GRAPH)
    if timepoint.importance_score > thresholds.critical_event:
        return max(entity.resolution, SCENE)
    return TENSOR_ONLY

Key Principle

We never pay for detail nobody asked about. This is the core of cost reduction: detail is generated lazily, only when queries require it.

Castaway Colony Example

Navigator Jin Park starts at TENSOR_ONLY—injured, inactive, consuming minimal tokens. When Branch C (Repair & Signal) needs pre-crash orbital data to locate the emergency beacon, a query about navigation logs triggers lazy elevation to DIALOG. Park reveals the hemisphere landing error, which cascades to:

Vasquez: recalibrate weather models
Tanaka: explains terrain mismatch

The system paid nothing for Park’s detail until the moment it mattered.

Query History Tracking

class QueryHistory(SQLModel, table=True):
    query_id: str = Field(unique=True, index=True)
    entity_id: str = Field(foreign_key="entity.entity_id", index=True)
    query_type: str  # knowledge, relationships, actions, dialog, general
    required_resolution: str  # Resolution level required
    timestamp: datetime = Field(default_factory=datetime.utcnow)
    success: bool = True
    resolution_elevated: bool = False  # Whether elevation occurred

From schemas.py:294-304

M6: TTM Tensor Compression

At TENSOR_ONLY resolution, entities are represented as structured tensors.

Tensor Structure

class TTMTensor(SQLModel):
    context_vector: bytes   # Knowledge state (8 dims)
    biology_vector: bytes   # Physical attributes (4 dims)
    behavior_vector: bytes  # Personality/decision patterns (8 dims)
    
    @classmethod
    def from_arrays(cls, context, biology, behavior):
        return cls(
            context_vector=msgspec.msgpack.encode(context.tolist()),
            biology_vector=msgspec.msgpack.encode(biology.tolist()),
            behavior_vector=msgspec.msgpack.encode(behavior.tolist()),
        )

From schemas.py:84-100

Context Vector Layout

# context_vector: 8 dimensions
[0] = knowledge      # Amount of information possessed
[1] = valence        # Emotional positive/negative (-1 to 1)
[2] = arousal        # Emotional activation level (0 to 1)
[3] = energy         # Cognitive/physical resources (0 to 1)
[4] = confidence     # Decision certainty (0 to 1)
[5] = patience       # Frustration tolerance (0 to 1)
[6] = risk           # Risk-taking propensity (0 to 1)
[7] = social         # Social engagement willingness (0 to 1)

Compression Ratios

Representation	Token Count	Compression
Full entity	~50,000 tokens	Baseline
TTM tensor	~1,600 tokens	97%

Overall at TENSOR_ONLY: 99.6% compression

Detailed Compression by Vector

Context tensor: 1000 dims → 8 dims (99.2%)
Biology tensor: 50 dims → 4 dims (92%)
Behavior tensor: 100 dims → 8 dims (92%)

Castaway Colony Example

The Kepler-442b biosphere is compressed as a TTM tensor:

context_vector = [
    bioluminescence_intensity,
    electromagnetic_sensitivity,
    growth_rate
]

biology_vector = [
    toxicity_index,
    nutrient_profile,
    symbiotic_relationships
]

This captures the alien ecosystem’s state in ~1,600 tokens instead of ~50k — 97% compression. When a query asks “How does the flora respond to the crew’s radio equipment?”, the electromagnetic_sensitivity dimension reconstructs the relevant behavior without decompressing the entire biosphere.

Dual Tensor Architecture & Synchronization

The system maintains two representations of cognitive/emotional state:

Two Tensor Types

TTMTensor (entity.tensor): Trained, compressed tensor with emotional values (0-1 scale)
CognitiveTensor (entity.entity_metadata["cognitive_tensor"]): Runtime state used during dialog synthesis (-1 to 1 scale for valence, 0-100 for energy)

The Sync Problem

Without synchronization:

Entities start dialog with default CognitiveTensor values (valence=0.0, arousal=0.0)
This ignores their trained TTMTensor state
Emotional changes from dialog are lost when entities are reloaded

The Solution: Bidirectional Sync

Entity Load → TTM→Cog Sync → Dialog Synthesis → Emotional Updates → Cog→TTM Sync → Persist
              (pretraining)                                          (backprop)

Scale Conversions

# TTM valence (0-1) ↔ Cog valence (-1 to 1)
cog_valence = ttm_valence * 2 - 1

# TTM energy (0-1) ↔ Cog energy (0-100)
cog_energy = ttm_energy * 100

# TTM arousal (0-1) ↔ Cog arousal (0-1)
# Same scale, direct copy

Implementation

In workflows/dialog_synthesis.py:

_sync_ttm_to_cognitive(): Called before dialog, copies trained tensor values to runtime state
_sync_cognitive_to_ttm(): Called after dialog, writes emotional changes back to tensor

This enables emotional evolution across dialogs—entities accumulate emotional state changes throughout the simulation rather than resetting to defaults.

Resolution Token Budgets

From workflows/temporal_agent.py:27-34:

RESOLUTION_TOKEN_BUDGET = {
    ResolutionLevel.TENSOR_ONLY: 100,    # Minimal state snapshot
    ResolutionLevel.SCENE: 500,          # Brief scene description
    ResolutionLevel.GRAPH: 1000,         # Relationship context
    ResolutionLevel.DIALOG: 3000,        # Full dialog turns
    ResolutionLevel.TRAINED: 5000,       # Rich trained detail
    ResolutionLevel.FULL_DETAIL: 8000,   # Complete entity state
}

Higher resolution entities get more tokens for richer content generation. This connects M1 (Fidelity) → M17 (Generation Granularity).

Performance Validation

Validation complexity: O(n) for n validators using set operations and vector norms. From production runs:

Typical simulation: 100 entities, 10 timepoints
With uniform fidelity: 50M tokens (~$500)
With M1+M2+M5+M6: 250k tokens (~$2.50)
200x cost reduction

Next Steps

Temporal Reasoning

Five temporal modes and causal chains

Knowledge Provenance

Who knows what, from whom, when

Getting Started

Core Concepts

Temporal Modes

Mechanisms

Guides

Examples

​The Insight

​M1: Heterogeneous Fidelity Graphs

​Resolution Levels

​Example Structure

​Token Economics

​Real Implementation

​Castaway Colony Example

​M2: Progressive Training

​Metadata Structure

​Quality Accumulation

​Castaway Colony Example

​M5: Query-Driven Lazy Resolution

​Decision Logic

​Key Principle

​Castaway Colony Example

​Query History Tracking

​M6: TTM Tensor Compression

​Tensor Structure

​Context Vector Layout

​Compression Ratios

​Detailed Compression by Vector

​Castaway Colony Example

​Dual Tensor Architecture & Synchronization

​Two Tensor Types

​The Sync Problem

​The Solution: Bidirectional Sync

​Scale Conversions

​Implementation

​Resolution Token Budgets

​Performance Validation

​Next Steps

Temporal Reasoning

Knowledge Provenance

Build docs developers (and LLMs) love

The Insight

M1: Heterogeneous Fidelity Graphs

Resolution Levels

Example Structure

Token Economics

Real Implementation

Castaway Colony Example

M2: Progressive Training

Metadata Structure

Quality Accumulation

Castaway Colony Example

M5: Query-Driven Lazy Resolution

Decision Logic

Key Principle

Castaway Colony Example

Query History Tracking

M6: TTM Tensor Compression

Tensor Structure

Context Vector Layout

Compression Ratios

Detailed Compression by Vector

Castaway Colony Example

Dual Tensor Architecture & Synchronization

Two Tensor Types

The Sync Problem

The Solution: Bidirectional Sync

Scale Conversions

Implementation

Resolution Token Budgets

Performance Validation

Next Steps