Use Discovery

Let Adapt-1 form learner-facing structure from admitted evidence instead of authoring the task ontology in advance.

Discovery is the primary alternative to authoring a task ontology before use. A Domain still provides the stable public scope and event boundary. Adapt-1 can form much of the learner-facing structure from the evidence that arrives inside that scope.

Use Discovery for a new structured task when the target or measured outcome and the public boundary are clear, while useful inputs, representations, causal bindings, or action values should form from admitted evidence. Keep an authored ontology when reviewed task-facing structure must remain explicit. A mixed setup is supported when only part of the surface should stay authored.

Discovery describes where learner-facing structure comes from. It does not classify how task-specific state was earned relative to an evaluation or operating run. A Discovery setup can start empty and accumulate state across one or many episodes, reset after each independently redrawn task, or form state in a separate acquisition phase before frozen or continued use. State earned earlier inside the same zero-start run remains in-run state. See Choose a learning setup.

Discovery spans several structure-forming paths. Each path forms a different kind of task-facing structure from admitted evidence while the Domain preserves the public interaction boundary.

Adapt-1 exposes three complementary Discovery paths:

Discovery path	Learns	Primary output
Transition Discovery	Stable scalar input paths and optional before/after causal bindings	transition_prediction and learning_state.subsystems.structured_transition
Structure Discovery	Outcome-useful fields, combinations, bounded temporal lags, and predictive rules	induced_structure and learning_state.subsystems.autonomous_structure
Sequential Discovery	State-dependent action values and delayed credit across ordered interaction	Selected policies and episode-aware feedback_policy state

Discovery is LLM-free. It operates on typed structured events and retained learner state. It does not generate a Domain from prose or infer private business intent.

Discovery lifecycle

Discovery is evidence-driven and can begin before an executable projection, active representation, or usable sequential policy exists.

1. Domain created
2. eligible events or feedback arrive
3. projection, representation, or sequential evidence accumulates
4. usable task-facing structure forms
5. eligible earlier evidence contributes under that structure
6. later predictions, hypotheses, or selections can change

This lifecycle can occur inside a zero-start learning run or inside a separate acquisition phase. If it occurs before a declared held-out run, the resulting Discovery state can be frozen or allowed to continue adapting. If it occurs across episodes inside one run that began empty, later episodes use retained in-run state rather than separately acquired state.

See adaptation in the loop

The shortest Discovery example is a later result that changes after an observed consequence:

state A
-> select action X
-> execute action X
-> return the observed next state and reward

state A or a compatible later state
-> retained Discovery state contributes
-> selection can change to action Y

The same loop can instead produce a new transition projection or a new induced rule. Inspect readiness, evidence, learner versions, and selection attribution before relying on the change.

What the application must still declare

Every Discovery Domain needs a small semantic boundary:

1. A stable domain_id and public event or feedback meaning.
2. An observable target, measured outcome, or reward for the applicable Discovery path.
3. The type, meaning, and valid range of each declared target or outcome.
4. A boundary that separates information available before a result from what becomes observable afterward.
5. Episode and reset identifiers when temporal or Sequential Discovery is used.
6. Candidate actions, legal constraints, and safety rules when the application can act.

The Domain can leave supported learner inputs, representations, bindings, and action values for Discovery to form from admitted evidence.

Choose Discovery or authored ontology

Goal	Configuration
Predict an observable target from stable fields in the same event	learning.transition.autonomous_projection.enabled: true with empty input_paths
Discover a categorical or numeric rule over many candidate fields	learning.structure.enabled: true with empty feature_paths
Discover useful feature combinations or temporal lags	Enable learning.structure.representation
Discover state-dependent action values from delayed outcomes	Enable learning.sequential and supply real episode, step, next-state, reward, and terminal fields
Discover before/after causal bindings while controlling learner inputs	Declare input_paths, enable transition projection, and enable causal_graph
Preserve an authored or reviewed ontology	Declare input_paths or feature_paths; explicit paths remain authoritative

Discovery does not make target leakage safe. Never send fields derived from the target as pre-outcome inputs. Review discovered paths before using a Domain for production decisions or an evaluation.

Minimal transition Domain

Leave input_paths empty and declare the target. Adapt-1 can then discover a stable input projection from eligible structured fields in the events you send.

{
  "domain_id": "process-output-demo",
  "session_id": "ignored",
  "description": "Predict an observed process output from available measurements.",
  "schema": {
    "event_types": ["observation"]
  },
  "learning": {
    "enabled": true,
    "transition": {
      "enabled": true,
      "event_types": ["observation"],
      "targets": [
        {
          "path": "values.process.output",
          "type": "number"
        }
      ],
      "required_support": 3,
      "numeric_model": "auto",
      "autonomous_projection": {
        "enabled": true,
        "minimum_observations": 3,
        "minimum_availability": 0.8,
        "maximum_input_paths": 8
      }
    }
  }
}

Create it with the production API:

curl -sS -X POST \
  "https://rei-neuroadapt-api.reilabs.org/api/v1/domains" \
  -H "Authorization: Bearer $ADAPT1_API_KEY" \
  -H "Content-Type: application/json" \
  --data @examples/domains/transition-numeric.domain.json

The hosted API derives tenant and session ownership from the bearer token. The session_id field remains present for request compatibility and can be set to ignored.

Inspect transition readiness

For transition projection, inspect every event response:

{
  "learner_eligibility": {
    "accepted": false,
    "rejection_reason": "projection_accumulating",
    "sample_count": 0,
    "autonomous_projection": {
      "status": "accumulating",
      "buffered_events": 2,
      "input_paths": []
    }
  }
}

When discovery becomes ready, the buffered events are reconsidered under the discovered path set:

{
  "learner_eligibility": {
    "accepted": true,
    "sample_count": 3,
    "sample_count_delta": 3,
    "autonomous_projection": {
      "status": "ready",
      "schema_changed": true,
      "revision": 1,
      "input_source": "discovered",
      "input_paths": [
        "values.process.pressure",
        "values.process.temperature"
      ]
    }
  }
}

sample_count_delta can be greater than one on the discovery event because previously buffered events are rebuilt into eligible samples.

Query with current context

Once the projection is ready, pass the current observable fields through context. Do not include the withheld target.

{
  "session_id": "ignored",
  "question": "Predict the process output.",
  "context": {
    "values": {
      "process": {
        "temperature": 30,
        "pressure": 1.2
      }
    }
  },
  "return_fields": [
    "transition_prediction",
    "learning_state"
  ],
  "update_memory_state": false,
  "allow_exploration": false
}

Read the prediction only when transition_prediction.status is predicted. Preserve the abstention reason, support, evidence IDs, model version, and discovered path set with the result.

Extend the configuration

Enable discovery on an existing Domain

Learning configuration can be updated through the Domain rules route:

curl -sS -X POST \
  "https://rei-neuroadapt-api.reilabs.org/api/v1/domains/YOUR_DOMAIN_ID/rules" \
  -H "Authorization: Bearer $ADAPT1_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "session_id": "ignored",
    "learning": {
      "enabled": true,
      "transition": {
        "enabled": true,
        "event_types": ["observation"],
        "targets": [
          {
            "path": "values.process.output",
            "type": "number"
          }
        ],
        "autonomous_projection": {
          "enabled": true
        }
      }
    }
  }'

Send a complete learning declaration, not a partial nested patch. For a controlled migration, create a new Domain, replay only approved training events, inspect the discovered state, and move application traffic after validation.

Explicit, automatic, and mixed contracts

Mode	Input declaration	Behavior
Automatic	Empty input_paths or feature_paths	Core discovers eligible structure from events
Explicit	Non-empty paths	Declared paths remain authoritative
Mixed	Explicit transition inputs plus autonomous causal binding, or explicit base fields plus representation discovery	Core discovers only the undeclared portion

This lets an application explore with automatic discovery, review the resulting structure, and then pin approved paths without changing routes or event shapes.

Production checklist

1. Declare the complete learning-run boundary and starting state before collecting results. Use empty state for a zero-start run and fresh acquisition state when building a separate checkpoint.
2. Preserve a holdout period, entity split, or episode split that did not form the discovered state.
3. Confirm every accepted event or feedback record changes the intended learner count.
4. Inspect discovered paths, active representations, sequential model state, evidence IDs, learner versions, and selection attribution where applicable.
5. Verify the learner view contains no target-derived value, correct action, private evaluator output, or post-outcome leakage.
6. Freeze configuration and updates before held-out evaluation.
7. Compare the applicable Discovery path against a simple baseline or disabled-path ablation under identical data and scoring.
8. Pin reviewed paths and public boundaries when production requires stable semantics.

Transition Discovery

Discover stable input paths and optional causal bindings.

Structure Discovery

Discover useful fields, combinations, temporal lags, and predictive rules.

Sequential Discovery

Discover state-dependent action values and delayed credit across episodes.

Complete examples

Run transition, structural, sequential, and mixed workflows.

Choose how a Domain learns

Map the observable task loop to Discovery paths and compatible evidence relationships.