> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reilabs.org/llms.txt
> Use this file to discover all available pages before exploring further.
# 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](/docs/neuroadapt/choose-a-learning-setup#fix-the-learning-run-boundary-first).
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:
```text theme={null}
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.
```json theme={null}
{
"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:
```bash theme={null}
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:
```json theme={null}
{
"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:
```json theme={null}
{
"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.
```json theme={null}
{
"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
Learning configuration can be updated through the Domain rules route:
```bash theme={null}
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.
| 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.
Discover stable input paths and optional causal bindings.
Discover useful fields, combinations, temporal lags, and predictive rules.
Discover state-dependent action values and delayed credit across episodes.
Run transition, structural, sequential, and mixed workflows.
Map the observable task loop to Discovery paths and compatible evidence relationships.