> For the complete documentation index, see [llms.txt](https://docs.neurolabai.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.neurolabai.io/introduction.md).

# What Does Neurolab Do?

Simply put, Neurolab is an application for structured compound research. The Neurolab application connects a compound or molecular structure to multiple kinds of output: model-ranked hypotheses, retrieved records, mechanism-oriented context, evidence topology, and exploratory brain-system views.

The application is designed around a simple principle: **a prediction, a source-backed record, and an explanatory hypothesis are different kinds of claims**. Neurolab keeps those states visible so that users can investigate relationships without silently upgrading one kind of evidence into another.

## From a question to an investigation

A Neurolab investigation begins with one of three input situations:

1. A **known compound name** that resolves to the governed knowledge graph.
2. A **molecular structure**, supplied as SMILES, that follows the separate structure route.
3. A **structure plus caller-supplied receptor assumptions**, which conditions downstream reasoning on those assumptions.

The application then assembles a structured report and opens coordinated views over the same result:

| Workspace             | Purpose                                                                                                                                                 |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Inference**         | Shows request progress and the transition from input to a finalized report.                                                                             |
| **Section Inspector** | Examines mechanism, cognition, or side-effect rankings together with interpretation, reliability, report evidence, and separately retrieved literature. |
| **Data Explorer**     | Turns bounded natural-language requests into read-only actions over the report: rank, filter, compare, highlight, inspect evidence, or reset.           |
| **Raw Payload**       | Presents formatted sections alongside the exact machine-readable response and JSON exports.                                                             |
| **Chat Report**       | Lets users ask questions with selected report context attached. The assistant explains the report; it does not replace the inference system.            |
| **Knowledge Graph**   | Shows report-local support and context, with source, scope, filter, and export controls.                                                                |
| **Brain Explorer**    | Displays available brain-related channels while preserving their method and validation labels.                                                          |

Neurolab is also developing account-based preferences, reusable workbenches, molecular portfolios, and a Data Studio for deeper comparison and analysis. These surfaces extend the same evidence-aware workflow; their presence in the product direction does not mean that every beta environment exposes every capability today.

## What does a Neurolab inference report contain?

Depending on route and availability, a report can contain ranked mechanism-of-action classes, cognition concepts, reported-usage hypotheses, side-effect signals, ATC classifications, brain-related outputs, reliability and applicability metadata, reference records, and a knowledge-graph support bundle.

Not every field has the same origin. A useful first classification is:

* **Model-ranked prediction:** generated by a learned head or route component.
* **Source-backed record:** retrieved from a named source or governed graph artifact.
* **Composed hypothesis:** assembled from explicit rules, retrieved neighbors, or mechanism layers.
* **Reference context:** relevant background that is not asserted as support for the query-specific prediction.
* **Caller-provided assumption:** supplied by the user and carried into downstream reasoning.
* **Unavailable:** absent, withheld, or not validated for the route.

The [Evidence States](/understand-results/evidence-states.md) page defines these distinctions in detail.

## Why there are two model routes

The known-compound model is transductive: it works with compounds already represented in the release knowledge graph. A new SMILES string cannot simply be inserted into that model at request time. It therefore follows a separate retriever-and-reasoner route that estimates receptor relationships from chemistry, retrieves relevant analog context, and composes downstream hypotheses.

The routes share a governed knowledge lineage, but they do not share one execution path or one validation claim. Results must always be interpreted in the context of the route that produced them.

## What Neurolab is for

Neurolab is intended for research triage, hypothesis generation, evidence organization, exploratory mechanism work, benchmark development, and human-reviewed experiment planning. Example audiences include neuroscience and pharmacology researchers, technically informed compound researchers, model and data evaluators, and collaborators assessing the project’s scientific direction.

The application and inference reports are intended for research only, and they are not intended to determine individual treatment, establish efficacy outside of a clinical context, recommend a dose, certify the safety of novel compounds, prove causality, or substitute for primary-source review.

See [Current Product Surface](/product-overview.md) for the distinction between current capabilities and work that remains in development.

Next: [Current Product Surface](/product-overview.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.neurolabai.io/introduction.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.