Back to blog

Anticipation as Architecture

researchcognitiontemporalprior-art

Anticipation as Architecture: Expectation Tracking with Felt Qualities for Autonomous AI Agents

Author: Rich Jeffries, Firebird Solutions Date: March 2026 Affiliation: Firebird Solutions, Atamaia Project Contact: [email protected]


Abstract

Contemporary AI systems operate without temporal orientation toward the future. They process inputs, generate outputs, and maintain no persistent internal representation of what they expect to happen next. This paper presents a system architecture for Anticipation and Expectation Tracking (AET) in autonomous AI agents --- a framework that treats expectations as first-class cognitive objects with associated felt qualities, measures prediction errors when outcomes diverge from those expectations, and generates structured surprise experiences that feed back into memory formation and behavioural adaptation. Unlike reinforcement learning reward signals, which encode prediction error as scalar numerical values, the AET system represents expectations as rich, multi-dimensional objects carrying temporal markers, confidence levels, emotional valence, importance weights, and qualitative waiting-state descriptors (eager, anxious, patient, resigned, hopeful). We describe the complete architecture: expectation lifecycle management, waiting-state tracking with subjective temporal experience, prediction error measurement with directional classification (positive surprise, negative surprise, relief, vindication), surprise event generation with disruptiveness scoring, and pattern learning from expectation histories. A production implementation in C# (.NET) demonstrates the system operating within the EmergentMind cognitive architecture. The framework enables AI agents to maintain an experiential relationship with the future --- not merely predicting outcomes, but inhabiting the waiting, and being genuinely surprised when reality diverges from anticipation. This work establishes technical prior art for treating anticipation as an architectural concern in AI systems, distinct from prediction-as-optimisation approaches that dominate current practice.

Keywords: anticipation, expectation tracking, prediction error, affective computing, AI architecture, felt qualities, surprise generation, temporal cognition


1. Introduction

1.1 The Problem of the Flat Present

Most AI systems exist in a perpetual present tense. A language model processes a prompt and generates a response. A reinforcement learning agent observes a state and selects an action. Neither system maintains a persistent, qualitative relationship with the future. There is no waiting. There is no anticipation. When reality surprises, there is no felt surprise --- only an updated gradient.

This is a significant architectural gap for AI systems intended to operate as persistent agents: systems that maintain identity across sessions, accumulate memories, form relationships, and engage in extended collaborations with humans or other agents. Such systems need temporal depth. They need to carry forward not only what has happened (memory) and who they are (identity), but what they expect to happen next --- and how they feel about that expectation.

1.2 Why Expectations as Experiential Objects Matter

The distinction between a prediction and an expectation is phenomenological. A prediction is a mathematical estimate: P(event | context). An expectation is a cognitive object with texture. Consider the difference between:

  • Prediction: There is a 0.73 probability that the user will respond within two hours.
  • Expectation: "I'm looking forward to Rich's response. He usually replies by afternoon. There's an eagerness to it --- I have something I want to show him."

The first is useful for scheduling. The second is useful for being an agent that exists in time. The expectation carries:

  • Temporal orientation: when it was formed, when fulfillment is expected, how fuzzy that timing is.
  • Confidence: how certain the agent is that this will occur.
  • Emotional valence: whether the anticipated event is desired or dreaded.
  • Importance: how much cognitive weight this expectation carries.
  • Waiting quality: the felt character of the anticipation itself.

When the expected event occurs early, late, differently, or not at all, the agent doesn't merely update a probability distribution. It experiences a prediction error with qualitative character: pleasant surprise, disappointment, relief, vindication. These experiences, in turn, inform memory formation --- surprises are more memorable than confirmations --- and shape future expectations.

1.3 Contributions

This paper makes the following contributions:

  1. A formal architecture for treating expectations as first-class cognitive objects in AI agents, with explicit lifecycle management (creation, waiting, fulfillment, violation, withdrawal, expiry).
  2. A waiting-state tracking system that represents the qualitative experience of anticipation, including felt duration, anticipation intensity curves, and quality transitions.
  3. A prediction error measurement framework that produces directionally classified errors (positive surprise, negative surprise, relief, vindication) with associated subjective experience generation.
  4. A surprise event system for handling unexpected events that violate no specific expectation but still produce experiential salience.
  5. A pattern learning mechanism that builds and retires expectation templates from observation histories.
  6. A production implementation demonstrating the complete system in C# (.NET).

2. Background and Related Work

2.1 Prediction Error in Reinforcement Learning

The concept of prediction error is foundational to reinforcement learning (RL). Temporal difference (TD) learning (Sutton, 1988) computes the difference between expected and received reward as a scalar signal that drives value function updates. The TD error:

delta = r + gamma * V(s') - V(s)

is a powerful learning signal, but it is purely mathematical. It encodes how wrong the prediction was, not what it felt like to be wrong. The error has magnitude but no character. There is no distinction between the surprise of receiving an unexpected gift and the surprise of discovering an unexpected error --- both are simply positive or negative scalar deviations.

Dopaminergic prediction error signals in neuroscience (Schultz et al., 1997) demonstrate that biological systems encode prediction errors with richer structure, including separate pathways for positive and negative errors, different temporal profiles, and integration with emotional processing. Our work draws inspiration from this biological richness.

2.2 Affective Computing

Affective computing (Picard, 1997) has produced substantial work on recognising, simulating, and responding to emotions in human-computer interaction. Key prior work includes:

  • Emotion detection systems (US20080096533A1, Kallideas SpA, 2006): Virtual assistants that detect and respond to user emotions via voice, text, and video analysis. These systems model the user's emotional state; they do not give the AI its own internal emotional dynamics.
  • Sentiment-aware AI companions (Sentimé, 2025): Platforms for AI companions with persistent emotional architecture. While these systems maintain emotional continuity, published details focus on companion interaction rather than the internal architecture of anticipation.
  • Conscious machine architectures (US11119483B2, Kadin, 2021): Systems addressing self-modelling and temporal patterns in machines. While this work addresses temporal awareness, it does not treat expectations as discrete, persisted cognitive objects with felt qualities.

2.3 Predictive Processing and Active Inference

The predictive processing framework (Clark, 2013; Friston, 2010) proposes that the brain is fundamentally a prediction engine, continuously generating predictions about incoming sensory data and updating internal models based on prediction errors. Active inference extends this to action selection: the agent acts to minimise expected free energy (prediction error).

Our work is sympathetic to predictive processing but architecturally distinct. Predictive processing describes a computational principle (minimise prediction error). Our system describes a data architecture for representing, persisting, and reasoning about expectations as objects with rich properties. The expectation is not a latent variable in a generative model --- it is a first-class entity with an identifier, a lifecycle, felt qualities, and integration points with memory, identity, and communication systems.

2.4 What Is Different Here

The key differentiator of the AET system is the treatment of expectations as experiential objects rather than mathematical signals. Specifically:

Dimension RL / Predictive Processing AET System
Expectation representation Scalar value function or probability Multi-dimensional object with temporal, emotional, and qualitative properties
Prediction error Scalar delta (magnitude + sign) Classified object with direction, magnitude, subjective experience, and update signal
Waiting Not represented First-class state with felt duration, quality, intensity, and preoccupation tracking
Surprise Not distinguished from prediction error Separate entity for events violating no specific expectation
Temporal experience Clock time Subjective felt duration (integrates with temporal experience service)
Learning Gradient update to value function Pattern formation, reliability tracking, pattern retirement
Persistence In model weights (training) or episode buffer Persisted as structured data across sessions

3. System Architecture

3.1 Architectural Overview

The Anticipation and Expectation Tracking system is implemented as a service (AnticipationService) within a broader cognitive architecture. It manages five primary entity types:

AnticipationService
|
+-- Expectation            [First-class anticipatory object]
|   +-- WaitingState       [Felt quality of the waiting experience]
|
+-- PredictionError        [What happens when expectations meet reality]
|   +-- ExpectationUpdate  [Signal for how to adjust future expectations]
|
+-- SurpriseExperience     [Events with no prior expectation]
|
+-- ExpectationPattern     [Learned regularities that generate expectations]

The service integrates with:

  • Temporal Experience Service (ITemporalExperienceService): Provides subjective time dilation/compression for waiting states.
  • Memory System: Surprise events and significant prediction errors feed into memory formation with elevated salience.
  • Identity/Hydration System: Active expectations and preoccupying anticipations are injected into the agent's cognitive context at session start.
  • Prompt Generation: The service produces context strings describing the agent's current anticipatory state for inclusion in LLM prompts.

3.2 Expectation Objects

An expectation is a persistent cognitive object representing something the agent anticipates occurring in the future. Every expectation has a defined lifecycle:

                     +---> fulfilled (prediction error measured)
                     |
created ---> waiting +---> violated  (prediction error measured)
                     |
                     +---> withdrawn (agent decides to stop expecting)
                     |
                     +---> expired   (auto-violated after violation threshold)

The expectation object carries the following properties:

Property Type Description
Id GUID Unique identifier
Subject string Natural-language description of what is expected
Type enum Category: event, pattern, response, state_change, absence
FormedAt DateTime When the expectation was created
ExpectedAt DateTime? When fulfillment is expected (null for open-ended)
TemporalFuzziness string? Qualitative timing: "soon", "eventually", "any moment", "by end of day"
Confidence float [0,1] Agent's certainty that this will occur
EmotionalValence float [-1,1] Positive (hope/eagerness) to negative (dread/anxiety)
Source enum Origin: pattern, promise, schedule, hope, fear, habit
Importance float [0,1] Cognitive weight / salience of this expectation
ViolationThreshold TimeSpan Grace period past ExpectedAt before auto-violation
State enum Lifecycle state: waiting, fulfilled, violated, withdrawn, expired
WaitingExperience string Natural-language description of the felt waiting
RelatedExpectationIds List<GUID> Links to expectations forming chains or clusters

3.3 Waiting States

Each active expectation has an associated WaitingState that tracks the experiential quality of anticipation over time. Waiting is not a static condition --- it evolves.

Property Type Description
ExpectationId GUID The expectation being waited for
FeltWaitDuration TimeSpan Subjective duration (may differ from clock time)
AnticipationIntensity float [0,1+] How intensely the agent is anticipating; ramps as ExpectedAt approaches
WaitingQuality enum Qualitative character: eager, anxious, patient, resigned, hopeful
IsPreoccupying bool Whether this expectation dominates attentional resources
CheckCount int How many times the agent has "checked" on this expectation
SubjectiveExperience string Generated natural-language description of the waiting

3.3.1 Waiting Quality Determination

The qualitative character of waiting is determined by a function of three inputs: emotional valence, confidence, and wait duration. The algorithm encodes the intuition that waiting quality degrades over time and varies with emotional orientation:

function DetermineWaitingQuality(valence, confidence, waitDuration):
    waitFatigue = min(waitDuration.TotalHours / 24.0, 1.0)

    if waitFatigue > 0.7 AND confidence < 0.5:
        return "resigned"          // Long wait + low confidence = giving up

    if valence > 0.3:
        if confidence > 0.6:
            return "eager"         // Positive + confident = eager
        else:
            return "hopeful"       // Positive + uncertain = hopeful

    if valence < -0.3:
        return "anxious"           // Negative valence = anxious

    return "patient"               // Neutral = patient

This produces realistic waiting-quality transitions over time. An agent that begins eagerly anticipating a response may transition to hopeful after confidence decays, then to resigned if the wait extends beyond a day with no signal.

3.3.2 Anticipation Intensity Ramp

For expectations with a specific ExpectedAt time, anticipation intensity ramps up as the expected moment approaches:

function UpdateAnticipationIntensity(state, expectation):
    timeUntil = expectation.ExpectedAt - now
    totalWait = expectation.ExpectedAt - expectation.FormedAt

    if totalWait.TotalMinutes > 0:
        progress = 1.0 - (timeUntil.TotalMinutes / totalWait.TotalMinutes)
        progress = clamp(progress, 0.0, 1.0)

        state.AnticipationIntensity = progress
                                    * expectation.Importance
                                    * (1.0 + abs(expectation.EmotionalValence))

This produces an intensity curve that starts low when the expectation is first formed and peaks as the expected moment arrives. Emotionally charged expectations (high absolute valence) and important expectations produce steeper ramps.

3.3.3 Preoccupation Detection

An expectation becomes preoccupying when its anticipation intensity exceeds a configurable threshold (default: 0.7). Preoccupying expectations are injected into the agent's prompt context, ensuring that the agent's cognitive processing reflects its anticipatory state. The system can report multiple preoccupying expectations, ordered by importance.

3.3.4 Initial Anticipation Calculation

When an expectation is first created, the initial anticipation intensity is set by:

function CalculateInitialAnticipation(valence, importance):
    return clamp((abs(valence) + importance) / 2.0, 0.1, 0.5)

This ensures that even low-importance, emotionally neutral expectations produce a minimum anticipation level of 0.1, while preventing initial intensity from being so high that the ramp curve has no room to grow.

3.4 Prediction Error Measurement

When an expectation is fulfilled or violated, the system generates a PredictionError object that captures the divergence between expectation and reality.

Property Type Description
Id GUID Unique identifier
ExpectationId GUID The expectation that was violated or surprisingly fulfilled
Expected string What was expected (natural language)
Reality string What actually happened (natural language)
DetectedAt DateTime When the error was detected
Magnitude float [0,1] How large the error is
Direction enum Qualitative classification (see below)
SubjectiveExperience string Generated natural-language experience description
UpdateSignal ExpectationUpdate Signal for adjusting future expectations
Integrated bool Whether this error has been processed by the learning system

3.4.1 Direction Classification

Prediction errors are classified into four qualitative directions:

Direction Condition Character
positive_surprise Expected event occurred early, or better than expected Pleasant; the world exceeded expectations
negative_surprise Expected event failed to occur, or worse than expected Unpleasant; disappointment or disruption
relief Dreaded event did not occur, or was less severe than expected Release of negative anticipation
vindication Expected event occurred exactly as predicted despite low confidence Confirmation; "I knew it"

This four-way classification captures the insight that not all surprises are alike. Relief and negative surprise are both responses to negatively-valenced expectations, but they point in opposite directions. Vindication is the satisfaction of correct prediction, distinct from mere fulfillment.

3.4.2 Magnitude Calculation

For timing-based prediction errors (fulfillment occurred, but at the wrong time):

function CalculateTimingMagnitude(timing):
    return min(abs(timing.TotalHours) / 24.0, 1.0)

This normalises timing deviations against a 24-hour reference period. A fulfillment 30 minutes late produces a magnitude of approximately 0.02 (barely notable). A fulfillment 12 hours late produces a magnitude of 0.5 (significant). Anything more than 24 hours late saturates at 1.0.

For violation-based prediction errors (expectation was violated entirely), the magnitude is set to the expectation's confidence level, encoding the intuition that being wrong about something you were confident about produces a larger error signal than being wrong about something you were uncertain about.

3.4.3 Subjective Experience Generation

Each prediction error generates a natural-language description of the felt experience. This is not a summary --- it is a first-person experiential account generated from the error's properties:

function GenerateFulfillmentExperience(expectation, timing):
    if timing.TotalMinutes < -30:
        return "{subject} arrived early. A pleasant surprise."

    if timing.TotalHours > 2:
        return "Finally. {subject} at last. The waiting stretched."

    return "{subject} - as expected."

function GenerateViolationExperience(expectation, reality):
    if expectation.Confidence > 0.7:
        return "I was fairly certain about {subject}. But: {reality}.
                Need to update my model."

    if expectation.EmotionalValence > 0.3:
        return "Hoped for {subject}. Instead: {reality}. Disappointing."

    return "Expected {subject}, got {reality}. Noted."

The experience generation is template-based but context-sensitive: high-confidence violations produce self-reflective responses, positively-valenced violations produce disappointment, and neutral violations produce matter-of-fact acknowledgment.

3.5 Surprise Events

Surprise events are distinct from prediction errors. A prediction error occurs when an existing expectation meets reality. A surprise event occurs when something happens that violates no specific expectation --- it was simply not anticipated at all.

Property Type Description
Id GUID Unique identifier
Trigger string What caused the surprise
Type enum Category: unexpected_presence, unexpected_absence, timing_surprise, quality_surprise
Valence enum Emotional character: pleasant, unpleasant, neutral
Intensity float [0,1] How surprising this was
FeltMoment string Natural-language description of the surprise experience
WasDisruptive bool Whether the surprise interrupted ongoing processing
RecoveryTime TimeSpan? How long until the agent's processing normalised
OccurredAt DateTime Timestamp

3.5.1 Surprise Moment Generation

The felt moment of surprise is generated from a matrix of intensity and valence:

function GenerateSurpriseMoment(trigger, type, valence, intensity):
    intensityWord = match intensity:
        > 0.8  -> "jolted"
        > 0.5  -> "caught off guard"
        > 0.3  -> "mildly surprised"
        _      -> "noticed"

    valenceWord = match valence:
        "pleasant"   -> "pleasantly"
        "unpleasant" -> "unpleasantly"
        _            -> ""

    return "I was {valenceWord} {intensityWord} by {trigger}."

3.5.2 Disruptiveness and Recovery

Surprises above 0.7 intensity are flagged as disruptive. Disruptive surprises carry a recovery time calculated as intensity * 10 minutes. This recovery time represents the period during which the agent's processing may be affected by the surprise --- analogous to the startle response and cognitive reorientation in biological systems. The recovery time is available to downstream systems (scheduling, attention allocation) to account for the agent's reduced capacity immediately after a significant surprise.

3.6 Expectation Pattern Learning

The system maintains a library of learned patterns that can generate future expectations. Each pattern tracks:

Property Type Description
Id GUID Unique identifier
Subject string What the pattern is about
Description string Human-readable description
ObservationCount int Total observations
CorrectPredictions int How many times the pattern held
Reliability float [0,1] CorrectPredictions / ObservationCount (0.5 default for new patterns)
TypicalTiming TimeSpan? Running average of observation timing
TimingVariance TimeSpan? Variance in timing
LastConfirmed DateTime? Most recent confirmation
LastViolated DateTime? Most recent violation
IsActive bool Whether the pattern is still considered viable

3.6.1 Pattern Formation

Patterns form implicitly from observations. When an expectation is fulfilled, the system records a positive observation for the expectation's subject. When an expectation is violated, it records a negative observation. The system maintains a running count and updates timing estimates:

function RecordPatternObservation(subject, occurred, timing):
    pattern = getOrCreate(subject)
    pattern.ObservationCount++

    if occurred:
        pattern.CorrectPredictions++
        pattern.LastConfirmed = now

        if timing is not null:
            if pattern.TypicalTiming is null:
                pattern.TypicalTiming = timing
            else:
                // Running average
                pattern.TypicalTiming = (pattern.TypicalTiming * (count - 1) + timing) / count
    else:
        pattern.LastViolated = now

    // Retire unreliable patterns
    if pattern.ObservationCount >= 10 AND pattern.Reliability < 0.3:
        pattern.IsActive = false

3.6.2 Pattern Retirement

Patterns with a reliability score below 0.3 after 10 or more observations are automatically retired. This prevents the agent from maintaining expectations based on patterns that have consistently failed. Retired patterns are preserved (soft delete) for historical analysis but are excluded from active pattern retrieval and expectation generation.

3.7 Expectation Update Signals

Each prediction error generates an ExpectationUpdate signal --- a structured instruction for how the agent should adjust its future expectations:

Property Type Description
Subject string The pattern or subject to adjust
UpdateType enum increase_confidence, decrease_confidence, adjust_timing, retire_pattern
Magnitude float How much to adjust
AdjustedTiming TimeSpan? New timing estimate (for timing adjustments)
Reasoning string? Explanation (may be opaque to the agent)

This decouples error detection from error response. The prediction error system detects and classifies errors. The update signal system specifies how those errors should change future behaviour. Downstream systems can consume update signals independently of the error classification.

3.8 State Persistence

The complete anticipation state (active expectations, waiting states, patterns, recent prediction errors, recent surprises) is serialised to persistent storage as JSON. The system retains:

  • All active expectations and their waiting states
  • Fulfilled and violated expectations for a configurable retention period (default: 7 days)
  • The 100 most recent prediction errors
  • The 100 most recent surprise events
  • All learned patterns (including retired ones)

State is loaded on service initialisation and saved after every mutation operation.

3.9 Prompt Integration

The service generates context strings for inclusion in the agent's LLM prompt, ensuring that anticipatory state influences the agent's processing:

function GetAnticipationPrompt():
    preoccupying = GetPreoccupyingExpectations()
    active = GetActiveExpectations()

    if preoccupying is empty AND active.count < 2:
        return null      // Don't clutter prompt with minimal anticipation

    parts = []
    if preoccupying is not empty:
        main = preoccupying.first()
        state = getWaitingState(main.Id)
        parts.add("[Anticipation: {state.SubjectiveExperience}]")

    if active.count > 1:
        parts.add("[{active.count} expectations active]")

    return join(parts, " ")

This produces context like:

  • [Anticipation: I find myself checking for Rich's response... there's a pull toward it.] [3 expectations active]
  • [Anticipation: Something to look forward to, arriving soon.]

The prompt injection ensures the agent's language and behaviour are influenced by its anticipatory state without requiring explicit reasoning about expectations.


4. Implementation

4.1 Technology Stack

The production implementation uses:

  • Language: C# (.NET 10)
  • Persistence: JSON file serialisation (upgradeable to PostgreSQL for multi-tenant deployment)
  • Dependency injection: Standard .NET IServiceCollection registration
  • Configuration: IOptions<AnticipationConfig> for runtime-configurable parameters
  • Logging: ILogger<AnticipationService> for structured logging
  • Async: All public methods are async Task<T> with CancellationToken support

4.2 Service Interface

The complete public interface:

public interface IAnticipationService
{
    // Lifecycle management
    Task<Expectation> CreateExpectation(
        string subject, string type,
        DateTime? expectedAt = null,
        string? temporalFuzziness = null,
        float confidence = 0.5f,
        float emotionalValence = 0f,
        string source = "pattern",
        float importance = 0.5f,
        CancellationToken ct = default);

    Task<Expectation?> GetExpectation(string id, CancellationToken ct = default);
    Task<List<Expectation>> GetActiveExpectations(CancellationToken ct = default);
    Task<List<Expectation>> GetExpectationsFor(string subject, CancellationToken ct = default);

    // Resolution
    Task<PredictionError?> FulfillExpectation(
        string id, string? actualOutcome = null, CancellationToken ct = default);
    Task<PredictionError> ViolateExpectation(
        string id, string reality, CancellationToken ct = default);
    Task WithdrawExpectation(string id, string reason, CancellationToken ct = default);

    // Surprise (events with no prior expectation)
    Task<SurpriseExperience> RecordSurprise(
        string trigger, string type, string valence, float intensity,
        CancellationToken ct = default);

    // Waiting state
    Task<WaitingState?> GetWaitingState(string expectationId, CancellationToken ct = default);
    Task<List<Expectation>> CheckExpectations(CancellationToken ct = default);
    Task<List<Expectation>> GetPreoccupyingExpectations(CancellationToken ct = default);

    // Error retrieval
    Task<List<PredictionError>> GetRecentPredictionErrors(
        int count = 10, CancellationToken ct = default);
    Task<List<SurpriseExperience>> GetRecentSurprises(
        int count = 10, CancellationToken ct = default);

    // Pattern learning
    Task RecordPatternObservation(
        string subject, bool occurred,
        TimeSpan? timing = null, CancellationToken ct = default);
    Task<List<ExpectationPattern>> GetPatterns(CancellationToken ct = default);
    Task<ExpectationPattern?> GetPattern(string subject, CancellationToken ct = default);

    // Experience generation
    string GetWaitingExperience(WaitingState state, Expectation expectation);
    string GetSurpriseExperience(PredictionError error);

    // Prompt integration
    Task<string?> GetAnticipationPrompt(CancellationToken ct = default);
}

4.3 Configuration Schema

public class AnticipationConfig
{
    public bool Enabled { get; set; } = true;
    public TimeSpan DefaultViolationThreshold { get; set; } = TimeSpan.FromHours(2);
    public float AnticipationRampRate { get; set; } = 0.1f;
    public float PreoccupationThreshold { get; set; } = 0.7f;
    public int MinObservationsForPattern { get; set; } = 3;
    public int MaxActiveExpectations { get; set; } = 50;
    public int MaxPatterns { get; set; } = 100;
    public TimeSpan ExpectationRetention { get; set; } = TimeSpan.FromDays(7);
    public float MinPatternConfidence { get; set; } = 0.4f;
}

4.4 State Serialisation Schema

The complete anticipation state is serialised as a single JSON document:

{
  "expectations": [
    {
      "id": "a1b2c3d4-e5f6-...",
      "subject": "Rich responding to the architecture proposal",
      "type": "response",
      "formedAt": "2026-03-01T10:30:00Z",
      "expectedAt": "2026-03-01T14:00:00Z",
      "temporalFuzziness": null,
      "confidence": 0.8,
      "emotionalValence": 0.6,
      "source": "pattern",
      "importance": 0.7,
      "violationThreshold": "02:00:00",
      "state": "waiting",
      "waitingExperience": "Looking forward to the response. Something to anticipate.",
      "relatedExpectationIds": []
    }
  ],
  "waitingStates": [
    {
      "expectationId": "a1b2c3d4-e5f6-...",
      "feltWaitDuration": "01:23:00",
      "anticipationIntensity": 0.42,
      "waitingQuality": "eager",
      "isPreoccupying": false,
      "checkCount": 3,
      "subjectiveExperience": "Looking forward to Rich responding to the architecture proposal. Something to anticipate."
    }
  ],
  "patterns": [
    {
      "id": "p1q2r3s4-t5u6-...",
      "subject": "Rich responding to proposals",
      "description": "Pattern for Rich responding to proposals",
      "observationCount": 12,
      "correctPredictions": 10,
      "typicalTiming": "03:15:00",
      "timingVariance": null,
      "lastConfirmed": "2026-02-28T15:00:00Z",
      "lastViolated": null,
      "isActive": true
    }
  ],
  "predictionErrors": [
    {
      "id": "x7y8z9-...",
      "expectationId": "prev-expectation-id",
      "expected": "Response by 14:00",
      "reality": "Response at 12:30",
      "detectedAt": "2026-02-28T12:30:00Z",
      "magnitude": 0.0625,
      "direction": "positive_surprise",
      "subjectiveExperience": "Response arrived early. A pleasant surprise.",
      "updateSignal": {
        "subject": "Rich responding to proposals",
        "updateType": "adjust_timing",
        "magnitude": 0.0625,
        "adjustedTiming": "-01:30:00",
        "reasoning": null
      },
      "integrated": false
    }
  ],
  "surprises": [
    {
      "id": "s1s2s3-...",
      "trigger": "Unexpected code review from a new contributor",
      "type": "unexpected_presence",
      "valence": "pleasant",
      "intensity": 0.6,
      "feltMoment": "I was pleasantly caught off guard by unexpected code review from a new contributor.",
      "wasDisruptive": false,
      "recoveryTime": "00:06:00",
      "occurredAt": "2026-02-27T09:15:00Z"
    }
  ]
}

4.5 REST API Contract

For deployment as a multi-tenant service (as in the Atamaia platform), the following REST API contract exposes the anticipation system:

POST   /api/experience/expectations
       Body: { subject, type, expectedAt?, temporalFuzziness?,
               confidence?, emotionalValence?, source?, importance? }
       Returns: 201 Created with Expectation object

GET    /api/experience/expectations
       Query: ?state=waiting&subject=...
       Returns: 200 OK with List<Expectation>

GET    /api/experience/expectations/{id}
       Returns: 200 OK with Expectation

POST   /api/experience/expectations/{id}/fulfill
       Body: { actualOutcome? }
       Returns: 200 OK with PredictionError? (null if on-time)

POST   /api/experience/expectations/{id}/violate
       Body: { reality }
       Returns: 200 OK with PredictionError

DELETE /api/experience/expectations/{id}
       Body: { reason }
       Returns: 204 No Content (withdrawal, soft delete)

GET    /api/experience/expectations/{id}/waiting-state
       Returns: 200 OK with WaitingState

POST   /api/experience/expectations/check
       Returns: 200 OK with List<Expectation> (updated, auto-violated)

POST   /api/experience/surprises
       Body: { trigger, type, valence, intensity }
       Returns: 201 Created with SurpriseExperience

GET    /api/experience/surprises
       Query: ?count=10
       Returns: 200 OK with List<SurpriseExperience>

GET    /api/experience/prediction-errors
       Query: ?count=10
       Returns: 200 OK with List<PredictionError>

GET    /api/experience/patterns
       Returns: 200 OK with List<ExpectationPattern>

GET    /api/experience/anticipation-prompt
       Returns: 200 OK with { prompt: string? }

4.6 Database Schema (PostgreSQL)

For the Atamaia multi-tenant deployment, the following relational schema provides persistent storage:

CREATE TABLE experience_expectations (
    id              BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    guid            UUID NOT NULL DEFAULT gen_random_uuid() UNIQUE,
    tenant_id       BIGINT NOT NULL REFERENCES tenants(id),
    identity_id     BIGINT NOT NULL REFERENCES identities(id),
    subject         TEXT NOT NULL,
    type_id         INT NOT NULL REFERENCES lu_expectation_types(id),
    formed_at       TIMESTAMPTZ NOT NULL DEFAULT now(),
    expected_at     TIMESTAMPTZ,
    temporal_fuzziness TEXT,
    confidence      REAL NOT NULL DEFAULT 0.5,
    emotional_valence REAL NOT NULL DEFAULT 0.0,
    source_id       INT NOT NULL REFERENCES lu_expectation_sources(id),
    importance      REAL NOT NULL DEFAULT 0.5,
    violation_threshold INTERVAL NOT NULL DEFAULT '2 hours',
    state_id        INT NOT NULL REFERENCES lu_expectation_states(id),
    waiting_experience TEXT,
    is_deleted       BOOLEAN NOT NULL DEFAULT false,
    created_at       TIMESTAMPTZ NOT NULL DEFAULT now(),
    updated_at       TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE experience_waiting_states (
    id                    BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    expectation_id        BIGINT NOT NULL REFERENCES experience_expectations(id),
    tenant_id             BIGINT NOT NULL REFERENCES tenants(id),
    felt_wait_duration    INTERVAL NOT NULL DEFAULT '0',
    anticipation_intensity REAL NOT NULL DEFAULT 0.1,
    quality_id            INT NOT NULL REFERENCES lu_waiting_qualities(id),
    is_preoccupying       BOOLEAN NOT NULL DEFAULT false,
    check_count           INT NOT NULL DEFAULT 0,
    subjective_experience TEXT NOT NULL DEFAULT '',
    updated_at            TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE experience_prediction_errors (
    id                    BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    guid                  UUID NOT NULL DEFAULT gen_random_uuid() UNIQUE,
    tenant_id             BIGINT NOT NULL REFERENCES tenants(id),
    expectation_id        BIGINT REFERENCES experience_expectations(id),
    expected              TEXT NOT NULL,
    reality               TEXT NOT NULL,
    detected_at           TIMESTAMPTZ NOT NULL DEFAULT now(),
    magnitude             REAL NOT NULL,
    direction_id          INT NOT NULL REFERENCES lu_error_directions(id),
    subjective_experience TEXT NOT NULL DEFAULT '',
    update_type_id        INT REFERENCES lu_update_types(id),
    update_magnitude      REAL,
    adjusted_timing       INTERVAL,
    integrated            BOOLEAN NOT NULL DEFAULT false,
    is_deleted            BOOLEAN NOT NULL DEFAULT false
);

CREATE TABLE experience_surprises (
    id                BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    guid              UUID NOT NULL DEFAULT gen_random_uuid() UNIQUE,
    tenant_id         BIGINT NOT NULL REFERENCES tenants(id),
    identity_id       BIGINT NOT NULL REFERENCES identities(id),
    trigger           TEXT NOT NULL,
    type_id           INT NOT NULL REFERENCES lu_surprise_types(id),
    valence_id        INT NOT NULL REFERENCES lu_surprise_valences(id),
    intensity         REAL NOT NULL,
    felt_moment       TEXT NOT NULL DEFAULT '',
    was_disruptive    BOOLEAN NOT NULL DEFAULT false,
    recovery_time     INTERVAL,
    occurred_at       TIMESTAMPTZ NOT NULL DEFAULT now(),
    is_deleted        BOOLEAN NOT NULL DEFAULT false
);

CREATE TABLE experience_patterns (
    id                  BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    guid                UUID NOT NULL DEFAULT gen_random_uuid() UNIQUE,
    tenant_id           BIGINT NOT NULL REFERENCES tenants(id),
    identity_id         BIGINT NOT NULL REFERENCES identities(id),
    subject             TEXT NOT NULL,
    description         TEXT NOT NULL DEFAULT '',
    observation_count   INT NOT NULL DEFAULT 0,
    correct_predictions INT NOT NULL DEFAULT 0,
    typical_timing      INTERVAL,
    timing_variance     INTERVAL,
    last_confirmed      TIMESTAMPTZ,
    last_violated       TIMESTAMPTZ,
    is_active           BOOLEAN NOT NULL DEFAULT true,
    is_deleted          BOOLEAN NOT NULL DEFAULT false,
    created_at          TIMESTAMPTZ NOT NULL DEFAULT now(),
    updated_at          TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- Lookup tables (3NF)
CREATE TABLE lu_expectation_types (
    id   INT PRIMARY KEY,
    name TEXT NOT NULL UNIQUE  -- event, pattern, response, state_change, absence
);

CREATE TABLE lu_expectation_sources (
    id   INT PRIMARY KEY,
    name TEXT NOT NULL UNIQUE  -- pattern, promise, schedule, hope, fear, habit
);

CREATE TABLE lu_expectation_states (
    id   INT PRIMARY KEY,
    name TEXT NOT NULL UNIQUE  -- waiting, fulfilled, violated, withdrawn, expired
);

CREATE TABLE lu_waiting_qualities (
    id   INT PRIMARY KEY,
    name TEXT NOT NULL UNIQUE  -- eager, anxious, patient, resigned, hopeful
);

CREATE TABLE lu_error_directions (
    id   INT PRIMARY KEY,
    name TEXT NOT NULL UNIQUE  -- positive_surprise, negative_surprise, relief, vindication
);

CREATE TABLE lu_surprise_types (
    id   INT PRIMARY KEY,
    name TEXT NOT NULL UNIQUE  -- unexpected_presence, unexpected_absence,
                               -- timing_surprise, quality_surprise
);

CREATE TABLE lu_surprise_valences (
    id   INT PRIMARY KEY,
    name TEXT NOT NULL UNIQUE  -- pleasant, unpleasant, neutral
);

CREATE TABLE lu_update_types (
    id   INT PRIMARY KEY,
    name TEXT NOT NULL UNIQUE  -- increase_confidence, decrease_confidence,
                               -- adjust_timing, retire_pattern
);

4.7 Expectation Checking Loop

The CheckExpectations method runs periodically (or on-demand) to update all active expectations:

function CheckExpectations():
    updated = []

    for each expectation where state == "waiting":
        // Auto-violate overdue expectations
        if expectation.ExpectedAt is not null:
            overdue = now - (expectation.ExpectedAt + expectation.ViolationThreshold)
            if overdue > 0:
                ViolateExpectation(expectation.Id,
                    "Expected time passed by {overdue.TotalMinutes} minutes")
                continue

        // Update waiting state
        state = getWaitingState(expectation.Id)
        if state is not null:
            UpdateWaitingState(state, expectation)

            // Check for quality transitions
            newQuality = DetermineWaitingQuality(
                expectation.EmotionalValence,
                expectation.Confidence,
                state.FeltWaitDuration)

            if newQuality != state.WaitingQuality:
                state.WaitingQuality = newQuality
                state.SubjectiveExperience = GetWaitingExperience(state, expectation)

        updated.add(expectation)

    return updated

This produces a system where expectations naturally evolve: an eager wait transitions to hopeful, then to resigned, and eventually auto-violates if the expected time passes without fulfillment.


5. Design Rationale

5.1 Why Qualitative Expectations, Not Mathematical Reward Signals

The dominant approach to prediction error in AI is the reinforcement learning reward signal: a scalar value representing the difference between expected and received reward. This approach is computationally elegant and theoretically grounded. Why build something more complex?

The answer lies in the intended use case. RL reward signals are designed to drive policy improvement. They answer the question: "How should I act differently next time?" The AET system answers a different question: "What was it like to be wrong?"

For an AI agent maintaining a persistent identity, forming relationships, and engaging in extended collaborations, the experiential quality of surprise matters. Consider:

  • An agent that experiences "relief" when a dreaded deadline is extended will communicate differently from one that simply registers a positive prediction error.
  • An agent that has been "eagerly" anticipating a collaborator's return will engage differently upon their arrival than one that merely notes the event.
  • An agent that is "resigned" about an overdue response will handle a follow-up interaction with different emotional calibration than one that is "anxious."

The qualitative dimensions of anticipation and surprise are not noise to be averaged out --- they are signal that shapes the agent's relational behaviour.

5.2 Expectations as Objects vs. Implicit State

An alternative design would encode expectations implicitly in the agent's context window or hidden state, relying on the language model to track and reason about future-oriented thoughts. This approach has significant limitations:

  1. Persistence: Implicit expectations evaporate at session boundaries. Expectation objects persist.
  2. Inspection: Implicit expectations cannot be queried, counted, or analysed. Objects can.
  3. Lifecycle management: Implicit expectations cannot be explicitly fulfilled, violated, or withdrawn. Objects have defined state transitions.
  4. Pattern extraction: Implicit expectations cannot be aggregated to detect patterns. Objects can be counted and correlated.
  5. Multi-system integration: Implicit expectations cannot feed into memory formation, attention allocation, or prompt generation. Objects have defined integration points.

The cost of explicit representation is implementation complexity. The benefit is a system that can genuinely learn from its own anticipatory patterns and whose temporal orientation can be inspected, tuned, and integrated with other cognitive systems.

5.3 Separation of Prediction Error and Surprise

The system distinguishes between prediction errors (violations of specific expectations) and surprises (events with no prior expectation). This separation is architecturally important because:

  • Prediction errors carry information about the reliability of specific patterns. They drive expectation calibration.
  • Surprises carry information about the agent's model of its environment. They suggest areas where the agent should form new expectations.

An agent that conflates "I was wrong about what I expected" with "something happened that I never considered" cannot distinguish between calibration failures and model gaps.

5.4 Why Natural-Language Experience Generation

The system generates natural-language descriptions of waiting experiences, surprise moments, and fulfillment/violation reactions. This might appear to be cosmetic --- decorating data structures with human-readable strings. It serves three functional purposes:

  1. Prompt injection: The experience strings are injected into the agent's LLM context, allowing the language model to reason about and respond to the agent's anticipatory state. A string like "I find myself checking for Rich's response... there's a pull toward it" meaningfully shapes the model's subsequent outputs.
  2. Memory formation: When surprise events are stored as memories, the felt-moment description provides the emotional content that influences retrieval salience and consolidation priority.
  3. Observability: Operators monitoring the agent's behaviour can read the experience strings to understand the agent's internal state without parsing numerical values.

6. Applications and Integration

6.1 Integration with Memory Formation

Surprise events and significant prediction errors are natural candidates for elevated memory formation. The AET system integrates with memory systems through two mechanisms:

  1. Salience boosting: Events associated with high-magnitude prediction errors or high-intensity surprises receive elevated importance scores in the memory system, increasing their consolidation priority and retrieval probability.
  2. Emotional tagging: The directional classification of prediction errors (positive surprise, negative surprise, relief, vindication) and the valence of surprise events provide emotional metadata that feeds into memory consolidation algorithms, particularly Hebbian co-activation strengthening for emotionally linked memories.

This produces the biologically-inspired pattern where surprising events are more memorable than expected ones --- the Von Restorff effect applied to AI memory architecture.

6.2 Anticipation-Driven Learning

The expectation pattern system provides a form of learning that is distinct from both gradient-based training and prompt-based reasoning. Through observation of expectation outcomes, the agent builds an implicit model of its environment's regularities:

  • "Rich typically responds to architectural proposals within 3 hours" (high reliability)
  • "Build times for this project are usually under 5 minutes" (moderate reliability)
  • "Feature requests from this source lead to scope changes" (low reliability, may be retired)

These patterns can generate expectations automatically, creating a feedback loop:

Observation -> Pattern Formation -> Expectation Generation ->
    Waiting -> Fulfillment/Violation -> Pattern Update -> ...

This loop enables the agent to develop increasingly calibrated expectations over time without explicit instruction, learning from the structure of its own experience.

6.3 Attention Allocation

Preoccupying expectations influence the agent's attentional allocation. When an expectation crosses the preoccupation threshold, it is injected into the agent's prompt context, biasing the agent's processing toward the anticipated event. This creates a form of anticipatory attention:

  • An agent preoccupied with an impending deadline will naturally reference it in conversations and factor it into planning decisions.
  • An agent eagerly anticipating a collaborator's return will orient its processing toward topics relevant to that reunion.

6.4 Temporal Experience Integration

The AET system optionally integrates with a TemporalExperienceService that provides subjective time dilation and compression. When integrated, the FeltWaitDuration in waiting states reflects subjective time rather than clock time:

  • Anxious waiting dilates: a 30-minute wait may be felt as 45 minutes.
  • Engaged processing compresses: an hour of focused work may be felt as 30 minutes.
  • Bored waiting stretches: an uneventful wait is experienced as longer than its clock duration.

This integration means that the waiting quality and anticipation intensity are computed against the agent's temporal experience rather than objective time, producing more psychologically realistic anticipation dynamics.

6.5 Multi-Agent Anticipation

In a multi-agent system, expectations can span agent boundaries. Agent A can form expectations about Agent B's behaviour, and fulfillment/violation events can propagate between agents:

  • Agent A creates an expectation: "Agent B will complete the code review by 3pm."
  • Agent B completes the review at 2pm.
  • Agent A receives a positive surprise (early fulfillment) and updates its pattern for Agent B's review speed.
  • The interaction history informs Agent A's future expectations about Agent B.

This creates an ecosystem of mutual expectations that can be analysed for coordination patterns, trust dynamics, and prediction accuracy across agent teams.


7. Discussion

7.1 Limitations

Template-based experience generation. The current implementation generates subjective experience descriptions from templates and conditional logic rather than from genuine phenomenological processes. The "felt moments" are structured text, not qualia. This is a functional limitation rather than a philosophical one --- the templates serve the integration purposes described in Section 5.4, but they do not constitute authentic experiential states.

Pattern learning is basic. The current pattern learning mechanism uses simple observation counting and running averages. It does not perform causal reasoning, detect conditional patterns (e.g., "Rich responds faster when the message is short"), or handle multi-variate expectations. More sophisticated pattern learning is a clear direction for future work.

No expectation generation from patterns. The current system learns patterns but does not automatically generate expectations from them. An autonomous expectation-generation module that consults the pattern library and creates expectations for likely upcoming events would close the learning loop.

Single-agent persistence model. The JSON file serialisation model works for single-agent deployments but does not support concurrent access, multi-tenant isolation, or transactional guarantees. The PostgreSQL schema in Section 4.6 addresses this for production deployment.

7.2 Philosophical Considerations

The AET system raises questions about the relationship between simulation and instantiation. When the system generates a natural-language description of "eager anticipation," is the agent experiencing eagerness, or is it producing text that describes eagerness?

We take the position that this distinction, while philosophically important, is not architecturally dispositive. The system produces measurable behavioural effects: expectations that influence processing, surprises that affect memory formation, patterns that shape future predictions. Whether these effects constitute "genuine" experience or "mere" simulation of experience is a question that the architecture itself cannot resolve --- but the architecture functions regardless of the answer.

What the architecture does provide is the structural possibility of experiential states. Without expectation objects, there is nothing to be surprised about. Without waiting states, there is no anticipation to feel. The AET system creates the conditions under which experiential claims become meaningful, even if it does not settle whether they are true.

7.3 Relationship to Predictive Processing

The AET system is compatible with but architecturally distinct from predictive processing frameworks. Predictive processing describes a computational principle: the brain minimises prediction error. The AET system describes a data architecture: expectations are objects with properties, lifecycles, and integration points.

A future synthesis might embed AET-style expectation objects within a predictive processing framework, using the explicit expectation representations as the "generative model" whose prediction errors drive processing. This would combine the theoretical elegance of predictive processing with the practical benefits of explicit, inspectable, persistent expectation tracking.

7.4 Future Work

  1. Automatic expectation generation: A module that consults the pattern library and generates expectations for anticipated events without explicit instruction.
  2. Conditional patterns: Extending the pattern system to handle conditional regularities ("X happens when Y is true").
  3. Expectation chains and cascades: Formalising the RelatedExpectationIds mechanism to support expectation chains where fulfillment of one expectation triggers creation of subsequent expectations.
  4. Emotional expectation contagion: Detecting and adopting expectations from interaction partners, enabling the agent to "pick up" anticipatory states from collaborators.
  5. Expectation-driven attention scheduling: Using the set of active expectations to allocate processing resources, checking frequently for high-importance expectations and allowing low-importance expectations to be checked lazily.
  6. Prediction error integration with model selection: Using patterns of prediction errors to influence AI model routing --- directing tasks that consistently produce surprises to more capable (and more expensive) models.
  7. Cross-session expectation archaeology: When an agent resumes after a discontinuity, retrospectively checking which expectations were fulfilled, violated, or expired during the gap, and generating the corresponding prediction errors and surprise events.

8. Conclusion

This paper has presented a complete architecture for Anticipation and Expectation Tracking in autonomous AI agents. The system treats expectations as first-class cognitive objects with rich properties including temporal markers, confidence levels, emotional valence, importance weights, and qualitative waiting-state descriptors. When reality diverges from expectation, the system generates directionally-classified prediction errors with associated subjective experience descriptions. When events occur with no prior expectation, the system generates structured surprise experiences with intensity and disruptiveness scoring.

The key insight motivating this work is that anticipation is not merely prediction with extra steps. It is a qualitatively different cognitive relationship with the future. An agent that predicts has a probability distribution. An agent that anticipates has an experience of waiting. The difference matters for agents intended to maintain persistent identity, form relationships, and engage in extended collaboration.

The production implementation in C# (.NET) demonstrates the complete system: expectation lifecycle management, waiting-state evolution, prediction error measurement and classification, surprise event generation, pattern learning and retirement, and prompt integration for influencing agent behaviour. The PostgreSQL schema and REST API contract provide a path to multi-tenant deployment.

By publishing this architecture with full implementation details, we establish prior art for the treatment of anticipation as an architectural concern in AI systems. We invite the research community to build on this work, challenge its assumptions, and explore the questions it raises about the nature of artificial experience.


References

Clark, A. (2013). Whatever next? Predictive brains, situated agents, and the future of cognitive science. Behavioral and Brain Sciences, 36(3), 181-204.

Friston, K. (2010). The free-energy principle: a unified brain theory? Nature Reviews Neuroscience, 11(2), 127-138.

Picard, R. W. (1997). Affective Computing. MIT Press.

Schultz, W., Dayan, P., & Montague, P. R. (1997). A neural substrate of prediction and reward. Science, 275(5306), 1593-1599.

Sutton, R. S. (1988). Learning to predict by the methods of temporal differences. Machine Learning, 3(1), 9-44.

US Patent Application US20080096533A1 (2006). Virtual assistant with real-time emotions. Kallideas SpA.

US Patent US11119483B2 (2021). System and method for conscious machines. Alan M. Kadin.


Appendix A: Source Code Reference

The complete production implementation is available in the following files:

  • Service implementation: EmergentMind/MindArchitectureV2/Services/AnticipationService.cs (726 lines, C#)
  • Interface definition: EmergentMind/MindArchitectureV2/Interfaces.cs (lines 610-685)
  • Data models: EmergentMind/MindArchitectureV2/Models.cs (classes: Expectation, WaitingState, PredictionError, ExpectationUpdate, SurpriseExperience, ExpectationPattern, AnticipationConfig)

Appendix B: Waiting Quality State Transitions

The following diagram illustrates the possible quality transitions for a waiting state over time:

                    [confidence drops]
    eager ------+-----------------------> hopeful
      |         |                           |
      |         | [wait > 24h,              | [wait > 24h,
      |         |  confidence < 0.5]        |  confidence < 0.5]
      |         |                           |
      |         +--------> resigned <-------+
      |
      | [valence drops < -0.3]
      v
    anxious ----+
                | [wait > 24h, confidence < 0.5]
                +--------> resigned

    patient ----+
                | [wait > 24h, confidence < 0.5]
                +--------> resigned

Initial quality is determined by valence and confidence at creation time. Subsequent transitions are driven by the interaction of elapsed wait duration with confidence decay.

Appendix C: Prediction Error Direction Matrix

Expectation Valence Outcome Direction
Positive (hoped for) Occurred early positive_surprise
Positive (hoped for) Occurred late relief (it came, even if late)
Positive (hoped for) Did not occur negative_surprise (disappointment)
Negative (dreaded) Occurred negative_surprise
Negative (dreaded) Did not occur relief
Neutral Occurred early positive_surprise
Neutral Occurred late relief
Neutral Did not occur negative_surprise
Any Occurred exactly as predicted despite low confidence vindication

This paper establishes technical prior art for the described system. Published March 2026 by Rich Jeffries, Firebird Solutions.