Use temporal context projection

Temporal Context Projection (TCP) adds bounded recent history to the context used by Adapt-1. Enable it when earlier observations can affect the current choice, and preserve stable episode and step ordering. TCP projects history before contextual memory lookup, model inference, posterior selection, out-of-distribution checks, and latent-regime tracking. Sequential learning assigns delayed credit when an action changes later state and reward belongs to an earlier decision.

The Domain declares the permitted history bound. TCP supplies values from that history to learning and selection. Keep future observations, expert actions, labels, and post-outcome values outside the temporal input paths.

When TCP fits

Enable TCP when all of these conditions are true:

observations belong to a real episode, run, case, or trajectory;
steps have a stable numeric order inside that boundary;
one or more scalar inputs have useful recent history;
the current decision can depend on an earlier input value;
the application can preserve the same episode_id and advance step monotonically.

Typical uses include sensor streams, event classification, control state, user interaction sequences, anomaly detection, operations telemetry, and partially observable environments. Ordinary contextual learning handles independent rows with immediate outcomes. TCP can coexist with sequential learning when the task requires history for state reconstruction and delayed credit for actions.

Add TCP to the Domain

The fragment below uses example parameters. Replace the input path and choose a history bound that matches the application.

{
  "learning": {
    "enabled": true,
    "context": {
      "feature_paths": ["values.observation"],
      "event_types": [],
      "max_samples": 4096
    },
    "temporal_context": {
      "enabled": true,
      "episode_path": "metadata.episode_id",
      "step_path": "metadata.step",
      "input_paths": ["values.observation"],
      "maximum_lag": 16
    }
  }
}

Field	Function
`enabled`	Enables temporal projection for this Domain.
`episode_path`	Finds the boundary that owns one ordered history.
`step_path`	Finds the numeric position inside that history.
`input_paths`	Selects the scalar pre-decision values that TCP may lag.
`maximum_lag`	Caps the available lookback supplied to learning and selection.

Start with the smallest credible maximum_lag. A larger bound increases input geometry, retained history, and the amount of evidence needed to distinguish useful lags.

TCP input paths must resolve to numeric scalar values. Keep arrays, objects, free text, IDs, post-outcome fields, labels, and future observations outside input_paths.

Send ordered context on every decision

The episode and step belong in the same context envelope as the current observation.

{
  "session_id": "ignored",
  "question": "Select one legal output value.",
  "relation": "selects_output",
  "top_k": 4,
  "selection_mode": "auto",
  "allow_exploration": true,
  "return_fields": [
    "selection",
    "decision_id",
    "ranked_hypotheses",
    "learning_state"
  ],
  "context": {
    "values": {
      "observation": 2
    },
    "metadata": {
      "episode_id": "episode-0007",
      "step": 42
    }
  }
}

Use these lifecycle rules:

Keep episode_id stable while observations share one history.
Use a finite numeric step and increase it monotonically.
Start a new episode ID at the real boundary.
Do not reuse one (episode_id, step) for a different observation. TCP deduplicates that pair.
Keep path names and value types stable between query and feedback.
Keep the same authenticated owner and domain_id when learned state must carry across episodes. The hosted service resolves session identity from the bearer token.

TCP constructs its historical view from observations already received in the same episode.

Bind the observed outcome

Submit the measured consequence after the selected policy is committed. Reuse the decision-time context and identifiers.

{
  "session_id": "ignored",
  "outcome": "correct",
  "feedback_kind": "execution",
  "decision_id": "DECISION_FROM_QUERY",
  "relation": "selects_output",
  "policy": "emit_2",
  "context": {
    "values": {
      "observation": 2
    },
    "metadata": {
      "episode_id": "episode-0007",
      "step": 42
    }
  },
  "values": {
    "correct": 1.0
  },
  "metadata": {
    "episode_id": "episode-0007",
    "step": 42
  }
}

The reward declaration must map values.correct, or another measured field, into [0,1]. TCP supplies temporal context to the applicable learning paths. Feedback still supplies the observed value of the committed decision.

What TCP changes

The projected temporal view can affect:

contextual-memory matching;
retained training snapshots;
learned-model predictions;
adaptive posterior source estimates;
out-of-distribution detection;
latent-belief state when that mechanism is enabled.

The existing learning and selection paths consume the projected state representation.

Inspect TCP in the response

Request ranked_hypotheses and learning_state while validating the integration. Preserve the full response before feedback. Keep an application trace with these fields for every decision:

{
  "episode_id": "episode-0007",
  "step": 42,
  "input_values": {
    "observation": 2
  },
  "selected_policy": "emit_2",
  "decision_id": "DECISION_FROM_QUERY",
  "learner_version": 128,
  "model_version": 96,
  "feedback_applied": true
}

Record the exact values available before selection. Keep the executed policy, measured outcome, feedback response, and applicable learner versions beside that decision.

Verify TCP in your integration

Use a short controlled stream before production use:

Start with fresh Domain and session state.
Send one episode with monotonic steps and known scalar inputs.
Confirm that every query uses the intended episode and step paths.
Submit one attributable outcome for each committed decision.
Check that applicable sample counts and learner versions advance.
Start a new episode and confirm that its history is isolated.
Repeat selected queries with feedback disabled and confirm that learner-state fingerprints remain unchanged.

Failure checks

Before trusting TCP behavior, verify all of the following:

the resolved Domain retains temporal_context.enabled: true and the intended paths;
each input path resolves before the decision;
steps are numeric and monotonic inside each episode;
episode IDs change only at real boundaries;
the retained sample budget covers representative histories;
the feedback response confirms admission by the policy learner;
a paired memoryless condition receives the same observations and outcomes;
frozen evaluation sends no feedback and leaves learner-state fingerprints unchanged.

If TCP does not help, first inspect episode boundaries, duplicated steps, path resolution, input types, history length, and sample retention. Compare performance with a memoryless condition to check whether history helps the task.

Choose how a Domain learns

Separate temporal state, immediate feedback, transition prediction, and delayed credit.

Sequential learning

Configure episode-aware action credit when outcomes belong to earlier decisions.

Use CUP

Learn which posterior sources and source pairs add predictive utility.

Verify adaptation

Compare cold, adaptive, and frozen behavior with state fingerprints.

Get started

Concepts

Guides

Discovery

Operations

API reference

When TCP fits

Add TCP to the Domain

Send ordered context on every decision

Bind the observed outcome

What TCP changes

Inspect TCP in the response

Verify TCP in your integration

Failure checks

Choose how a Domain learns

Sequential learning

Use CUP

Verify adaptation

​When TCP fits

​Add TCP to the Domain

​Send ordered context on every decision

​Bind the observed outcome

​What TCP changes

​Inspect TCP in the response

​Verify TCP in your integration

​Failure checks

Choose how a Domain learns

Sequential learning

Use CUP

Verify adaptation

When TCP fits

Add TCP to the Domain

Send ordered context on every decision

Bind the observed outcome

What TCP changes

Inspect TCP in the response

Verify TCP in your integration

Failure checks