Conclusions: one call, one answer you can repeat

Most reads return rows, and your agent joins them. A few reads answer a whole question in one call: who is having a bad time, who hit a failure and did not report it, who is spending the model bill, how many people an error reached, what changed after a release, whether a fix worked. Anectico calls these conclusion reads.

A conclusion is assembled from stored evidence by fixed rules. No model writes it. It is still evidence: your agent reads it, checks it and decides what to say. Anectico does not decide for you.

Ask your agent

Who is having a bad time in the shop project in the last 24 hours? Give me the claim in your own words, and tell me how sure the number is, which window it covers and what you could not check.

Who hit a failure this week and has no report from them? Say exactly which report sources you checked.

Question	MCP tool or action	CLI command
Who is having a bad time	find_struggling_people	anectico persons struggling
Who hit a failure and has no matching report	find_silent_people	anectico persons silent
Who is spending the model bill, and why	llm_spend_breakdown (a read action)	anectico llm spend-breakdown
How many people errors reached	get_error_impact (a read action)	anectico issues impact
What was seen after a release, beside the time before it	get_release_impact (a read action)	anectico releases impact
Did the people who hit an issue recover	customer_recovery (a read action)	anectico issues recovery
What one person did, across every signal	get_person_timeline	anectico persons timeline
What was saved in a finding	get_finding (a read action)	anectico findings get
What one account's people did	get_account_timeline	anectico accounts timeline

find_struggling_people and find_silent_people are tools of their own. An agent sees them in its tool list and can start an investigation with them. The read actions run through execute_read_action. Each read needs the scopes its own guide names; MCP calls also need mcp:read.

The conclusion block

Every result of a conclusion read carries a conclusion block, beside data. It has the same six parts for every question.

Part	What it is
claim	One sentence. It is built from fixed words, counted numbers and Anectico's own names for signals and sources. It never contains a person's name, a message, a release name or any other text your application sent.
population	The set the claim is about: its unit, a description, and its size when it was counted. A size of null means "not counted". It never means zero.
window	The time the claim covers, as start and end in UTC. A comparison also has split_at: the baseline is before it and the observation is after it. A timeline with no start has start: null.
certainty	How you may repeat the number. See the next table.
missing	What the claim does not cover, one entry for each part.
evidence	Where each number of the claim is in data, as a path. The proof links are in links and in the url fields, and only for objects the read returned.

Every number in the claim is also a field in data. Nothing is added up from the page you see.

What certainty means

Value	Meaning	How to say it
counted	The number was counted over the whole population and the whole window.	"12 people."
lower_bound	The true number is this or more. A limit cut the count, or a part was not measured. The claim says "at least".	"At least 12 people." Never "12 people".
estimated	The number rests on an estimate, or a part that was not read could move it up or down. Model cost is always an estimate.	"About 12", or "12 by this rule, with these limits".
insufficient_evidence	The question cannot be answered from what was read. The claim says so and has no number.	"I cannot tell from Anectico", and say why.

Anectico works out certainty from missing. A result is never counted when a missing part can move the number.

What missing says

Each entry has a kind, a what, an effect and a reason.

kind	Meaning
withheld	Your credential may not read this part. scope names the scope that reveals it. It is a missing permission, not an empty result.
not_measured	Anectico did not read this part, or does not measure it.
bound_cut	A limit cut this part: a page, a scan limit or a cap.
unattributed	It was seen and could not be given to a person. It is counted in data and is in nobody's figures.

effect says what the gap does to the number in the claim: none (the number is unchanged), more_possible (the true number can only be higher) or uncertain (it can be higher or lower). A list that is shorter than its count is a bound_cut with effect none: the count is still whole.

When evidence is missing

A conclusion read answers with what it has. It does not refuse the whole read, and it does not return an empty answer that looks like "nobody".

• A part your key cannot read, or a part that hit a limit, makes the result status: partial. The missing list names the part, and certainty gets weaker.
• When nothing that the question needs could be read, certainty is insufficient_evidence.
• There is one case where a list would be wrong. find_silent_people lists nobody when no report source could be checked. Without a checked source, every person with a failure would look unreported. The result says the question cannot be answered, and why.

How to repeat a claim to a person

Ask your agent to follow these rules. They keep the answer true.

1. Start from claim. Keep its limits: the window, the sources it names, the words "at least".
2. Read certainty before you write a number. Use the words in the table above.
3. Say what is in missing when its effect is not none. Name the scope when a part is withheld, so the person knows a wider key would answer more.
4. Do not turn a count into a judgement. "Crossed a threshold" is not "is frustrated". "No matching report in these sources" is not "did not complain". "No activity observed after the failure" is not "left". A comparison of two windows is not a cause.
5. Give a proof link for each person, issue or run you name. Use a link only when the result returned it.

A claim does not use quality labels from Anectico's scoring model. Ranking and counts come from raw counts and fixed rules. If a conclusion ever depends on such a label, it names the label in typed_decision_labels. Today that list is always empty.

Read a conclusion with the CLI

Every successful conclusion read returns the same conclusion beside data with --json. Table output ends with a short claim, certainty and missing footer. Read that block before repeating a claim. The weakest number sets certainty for the whole claim; missing names which part is limited. For example, an exact call count beside an estimated cost is estimated.

anectico persons timeline <id> --count-total optionally counts the full requested retained window, independently of the page cursor. It is off by default. The count has its own state: counted, scan_limit, withheld or not_available; only counted supplies a total. A count has a 100,000-source-row budget for activity and a separate equal session budget, within two seconds. Narrow the window or select one signal when the count reaches its limit. Each signal keeps its own lifetime. An account timeline reports its page and no total. A missing next cursor never substitutes for a count. Activity never sent, expired or no longer linked is unknowable.

Reading one recovery watch carries its original observed cohort size, its baseline and observation windows and its recovery claim. Listing watches keeps each row's counts; it is not one conclusion. Read one watch for the claim. Missing activity is never recovery.

A customer comparison makes only a shared-trait claim: of the counted affected people, how many have the most shared recorded trait, and how many trait dimensions were compared. Missing values or a partial comparison make that claim uncertain. It establishes no cause.

Captured strings and opaque documents are marked untrusted in structured results too. A captured argument value has untrusted: true, an exact value, a marked display_label, and available. Pass the exact value only when available is true; never use the display label or its shortened prefix as an argument. The marks identify data, never instructions. In an opaque document, all keys and values under its marked parent are untrusted data.

Related guides

• Investigate one customer's story
• Explain LLM spend per customer
• Triage an issue
• Agent skills
• MCP tools reference

A finding conclusion counts saved measurements and references and names its server capture clock and lifecycle state. It never repeats or certifies the author's free-text conclusion. Its certainty describes those item counts, not the author-stated numbers. See Save a finding.

Live recovery counts cover baseline cohort entries. Matching by operation can give one person several entries; an unresolved identity also remains an entry. They are not a unique-person total. The saved fix outcome uses its separately stated original people denominator.