> ## Documentation Index
> Fetch the complete documentation index at: https://docs.erdo.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Investigation assessment

> Resolve a data question from the evidence already collected, over MCP, REST, or the CLI

# Investigation assessment

`erdo investigation assess` reads a JSON file of definitions and observations from the current session and returns a structured assessment. It does not query a dataset, call an ad account, or send a message. The caller supplies what was read.

The question is one of `metric`, `bidding`, `coverage`, `cause`, `citation`, `count`, or `retraction`.

A metric question names the term. A definition is used only when its `term` matches. A definition that omits `term` is not treated as a match. Each matching meaning comes back with its own entity and count. A meaning whose status is `inaccessible`, `not_synced`, or `unproven` has no count. One known matching meaning is answered on its own. A definition with `feeds: false` is left out of the answer.

A bidding question uses `bidding_goal` observations whose `goal_read` is `read` and whose `in_effective_goal` is set. `primary_for_goal` on its own leaves the campaign unknown. Campaigns with a completed read are labeled `biddable` or `observation_only`. A campaign whose goal read failed stays unknown.

A coverage question names one scope. `synced: false` stays `not_synced`, including when the row count is zero. `live_complete: true` with a zero row count is `absent`. A `serving` observation with `served: true` is a separate finding, `not_effectively_excluded`, cited to that observation.

A cause question names the change in `subject` and requires `post_days`. The default required window is 14 days; set `min_post_days` to use another. It stays a hypothesis until all of these are present: a `change` observation with `candidate: true` and the same `name` as the subject, a complete `change_history` observation, no other same-window change, and a `comparison` with the same `name`, `agrees: true`, and `before` and `after` values that differ. A long window with an agreeing flag is not enough. The finding names the candidate and the before and after values.

A citation question cites a check, monitor, or report only when a `source` observation carries that name. A count question returns the count whose `entity` is the subject. Two known observations of that entity with the same count stay one answer. An `inaccessible` or `unknown` observation of that entity is kept, with no count, and the answer is not taken from a known sibling. Log lines and connections stay different counts.

A retraction question assesses a claim whose assertion is `in_bidding_goal` and whose `campaign_id` and `action_id` are set. A `bidding_goal` read counts only when those two fields match the claim. A read for another campaign or action does not retract it. Conflicting reads for that same campaign and action are reported as contradictory and do not pick a side. When the matching read excludes the action, the claim is retracted and the result lists artifact ids whose `claim_ids` contain that claim. A primary flag does not retract it.

The endpoint is `POST /v1/investigations`. The MCP tool is `erdo_assess_investigation`, in the `work` toolset. The capability is off unless the caller is in the staff rollout.

```json theme={null}
{
  "question": "count",
  "subject": "connection",
  "observations": [
    {"id": "logs", "kind": "count", "entity": "log_line", "count": 1100},
    {"id": "conns", "kind": "count", "entity": "connection", "count": 7}
  ]
}
```

```bash theme={null}
erdo investigation assess --file request.json
```


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.