Use temporal context projection

Use bounded episode history when the current observation alone is insufficient.

Use this when the current observation needs bounded episode history. Start with a working Domain and stable episode/step ordering.

Temporal Context Projection (TCP) adds bounded recent history to the context used by Adapt-1. Use it when the current observation is insufficient and recent values can change the correct policy.

TCP projects history before contextual memory lookup, model inference, posterior selection, out-of-distribution checks, and latent-regime tracking. It does not assign delayed action credit. Use sequential learning when an action changes later state and reward belongs to an earlier decision.

A Domain declares the available history bound. It does not declare the answer or the predictive lag. 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.

Use ordinary contextual learning for independent rows with immediate outcomes. Use sequential learning for delayed return across state-changing actions. TCP and sequential learning can coexist when the task needs both temporal state reconstruction and delayed credit.

Add TCP to the Domain

Use this TCP fragment as a starting point. 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. It does not identify which lag is useful.

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:

1. Keep episode_id stable while observations share one history.
2. Use a finite numeric step and increase it monotonically.
3. Start a new episode ID at the real boundary.
4. Do not reuse one (episode_id, step) for a different observation. TCP deduplicates that pair.
5. Keep path names and value types stable between query and feedback.
6. 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 needs no target action, future value, or answer in the query. It constructs a bounded 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.

TCP does not create a second policy learner. It changes the state representation available to the existing learning and selection paths.

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:

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

This check validates the integration contract. Application-level evaluation should remain separate from the usage guide.

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;
• feedback is admitted by the policy learner, not only accepted by HTTP;
• 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. A task can also be genuinely memoryless.

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.