Concepts

Intangia projects turn scope into scored opportunities. These names stay separate. An opportunity is not a signal.

Keywords

A keyword is a name in the catalogue: a target, indication, modality, mechanism, or another category. Search returns id, name, type, and synonyms.

The keyword card adds a description, activity counts, and six scores. Activity counts are papers, patents, trials, and assets. Each score has score, raw, label, and description. A missing score is null. scores.as_of is the metric date (YYYY-MM-DD).

Optional sections on the card:

Section	What It Adds
indications	Linked indications, each with a drug-evidence count
pipeline	Asset total, most advanced stage, and max clinical phase
biology	Target tractability, pathways, and tissues, or a disease definition
landscape	Therapeutic-area timelines, cost, and market size
metrics	Momentum averages and risk rates
ontology	Source and code pairs
sponsors	Organisations ranked by trials, papers, and patents

Relations page the same links. Sponsor rows use an organisation id. Indication, asset, and pipeline-target rows use a keyword id.

Scope

Scope keywords are the anchors on a project. Discovery runs around them. They are inputs, not findings.

On the API, you pass scope as watchlist_items when you create a project. Each item has entity_id, entity_type, and optionally entity_name and data.

On the MCP server, you pass the user's brief. The server matches scope. Do not invent keyword ids for that path.

Signals

Signals are Discover candidates: partners that co-occur with a scope keyword. signals_ready means discovery finished. It does not mean every candidate is scored.

A signal row has:

Field	Meaning
keyword_id	The scope keyword the scan ran around
signal_keyword_id	The partner
name	Partner name
type	target, disease, modality, or mechanism
analysed	true when that partner is already scored for the current setup
rank	Rank in the active ranking mode

total is the filtered count. unanalysed_total is how many of those are not scored yet. The MCP tool list_signals can set unanalysed_only to return only those. The REST list does not take that flag.

Ranking modes:

Mode	Label
most_promising	Most promising
novel_signal_scout	Most novel
validated_opportunity	Most validated

When you omit the mode, the list uses the mode saved on the project, or most_promising.

Opportunities

Opportunities are the output of scoring: a verdict, a composite score, and a short rationale. Pillar scores and evidence are not on the scoreboard. They are on one assessment, which the MCP tool get_assessment returns.

The REST opportunities route returns the project payload: keywords, project_analyses, and error. Storage paths are omitted. The MCP tool list_opportunities returns the ranked scoreboard instead.

Analyses

run_analyses scores signals that already exist. It does not discover signals. Pass either selections (specific partners) or top (the first N of one type). At most 100 signals of one type are scored at once.

A request that leaves the saved defaults — a different ranking mode, extra filters, already-scored rows, mixed types, or more than 20 — comes back with needs_confirmation: true and does not start a run until you send it again with confirmed: true.

Scoring setup has to exist first. If it does not, the call fails and tells you to open setup_url. The MCP tool setup_project runs that setup in the conversation. The API does not.

Reports

A report is a PDF built from opportunities that are already scored. Creating a report does not score anything. Reports are MCP tools (create_report, list_reports), not REST routes. generating means the PDF is not ready.

Projects and Roles

A project id is a UUID from list_projects or, on the MCP server, search_projects. A name is not an id.

Role	Can Read	Can Change
viewer	Projects, signals, status, opportunities	No
editor	The same	Scope, scoring, setup, reports
owner	The same	The same, and the project was created by this user

Someone who is not a member gets 403.