# Learning Isolation

Give new information a review boundary before relying on it.

Source: https://docs.minds.sh/docs/concepts/learning-isolation



Learning Isolation keeps incoming information separate from knowledge your application is ready to accept. It is useful when an agent reads a new source, receives a correction, or proposes a learned change that should be checked before it influences future work.

Think of a research inbox. A new article can be stored and inspected without immediately becoming an accepted fact in every answer.

## The review workflow [#the-review-workflow]

1. **Inspect the incoming item.** Identify its source, content, and current status.
2. **Evaluate it.** Examine the available tests and policies. A passed check should describe what was tested, not imply universal truth.
3. **Decide.** Approve or reject the item through the registered operation.
4. **Verify the result.** Read its updated state and confirm the intended downstream behavior.

The current API exposes item listing, item detail, approval, rejection, test gates, policies, and statistics. The existence of those routes does not mean every ingestion path automatically enters quarantine; your integration must use the intended review workflow.

## Isolation is not a magic truth filter [#isolation-is-not-a-magic-truth-filter]

A test can check a property, compare evidence, or identify an anomaly. It cannot make an unreliable source reliable merely by producing a score. For consequential conclusions, retain the original evidence and make the review policy explicit.

This is also separate from the Firecracker VM boundary. Runtime isolation protects instance separation; learning isolation controls how information is accepted within the Mind.

[Learning Isolation API](/docs/api/instance/learning-isolation) · [Governance workspace](/docs/workspace/governance) · [Knowledge lineage](/docs/api/instance/lineage)