# Read coverage and intake completeness > Tell readable history, intake settlement and upstream capture apart before interpreting an empty result. Canonical page: https://anectico.com/docs/reference/read-coverage/ ## Three separate questions Read coverage says which retained time interval a read covered. Intake accounting describes what happened to submitted positions recorded by Anectico. Neither establishes that every request or event in your application was sent. Keep source availability, sampling, row limits and withheld content beside any conclusion about absence. ## Read coverage Technical searches, aggregates, discovery, service health, metric reads, error lists, model-call cost reads and agent-run lists return a `read_coverage` object (`data.read_coverage` in MCP results; the same object in CLI JSON). It has one entry per source the read used (`errors`, `traces`, `logs`, `metrics`, `product_events` or `agent_runs`), each with: - `requested_interval`: the window you asked for, after defaults and relative windows were resolved. Absent when the operation has no time window, such as an exact lookup or a live tail. - `effective_interval`: the window actually read. Absent when nothing was read. - `retention_floor`: the oldest instant still kept for that source. Product events and technical data have separate floors. Absent when it could not be determined. - `outcome`: `complete` (the whole requested window was read), `partially_covered` (the start was raised to the retention floor or a disclosed read limit; earlier history was not read), `outside_retention` (the whole window is older than the history kept; nothing was read) or `unknown` (see `reason`). - `availability` and `reason`: whether the history bound and the source could be used, and why a window was narrowed or is unknown (`retention_window`, `retention_shortened`, `history_unresolved`, `source_unavailable`, `no_requested_interval` or `read_limit`). A `read_limit` can be a service-map range limit, a forecast history budget or a common readable window for a comparison. Keep the requested interval, effective interval and floor separate. `upstream_completeness` is `unknown`: `complete` means the requested window was readable, not that every event your services emitted arrived; sampling and intake limits can still leave records out. Intervals are `[start, end)`, and times keep full sub-second precision. An absent value means unknown, never zero: an empty result is a measured zero only when its source is `complete` or `partially_covered`. An `outside_retention` or `unknown` source says nothing about whether anything happened. Truncated rows and withheld fields are reported separately and are not part of coverage. MCP results also add one `errors` entry per source that was not completely covered. REST and CLI JSON use enum names such as `READ_COVERAGE_OUTCOME_OUTSIDE_RETENTION`; MCP uses `outside_retention`. CLI tables print a `Coverage:` explanation for incomplete or unknown history and withhold numerical tables when no selected source was read. An expired log-derived metric has no freshness measurement; it is never reported as current. Browser-session evidence reports recording availability independently of trace and error coverage. Its CLI table keeps recording references visible even when both technical sources are expired or unavailable. Exact log, trace and agent-run reads report the floor without inventing a requested interval. When an authorized occurrence clock or explicit trace window proves expiry, they return `outside_retention` with no object content. A missing object whose clock is unknown remains not found; that cannot prove it expired. Increasing retention and previously exported files do not provide an Anectico history-recovery operation. ## Intake accounting Use `anectico usage intake --start-time --end-time `, or MCP `get_intake_ledger`, with `usage:read` and your project. Optional `--source-id` selects a trusted source. The half-open window uses server receipt time; results are grouped by source, signal, UTC day and reason. Accounting is retained for eight days; inspect `accounting_from` before interpreting an older window. Counts describe submitted positions, including SDK retries. Redelivery of the same server-admitted record is counted once. They separate accepted, stored, settled without a new row, sampled, refused and pending positions. Whole undecodable requests have their own count. Stored positions are acknowledged write attempts, not distinct rows currently readable. Do not add derived error projections to their source span and log totals. `billed_units` is `not metered`. `durable_through` and the query visibility watermark are exclusive receipt-time prefixes of the examined journaled population, with `visibility_lag_ms`. They stop before unsettled positions; a later arrival can change a subsequent read. Upstream and accounting completeness remain unknown. An empty bucket list proves no absence of traffic or loss. This read neither changes billing nor configures sampling. ## Intake completeness states Where a measurement returns `intake_completeness`, keep its state, reason, population and observation time. These states describe the examined recorded population: | State | Meaning | | --- | --- | | `settled` | The checked accepted population has settled, without known sampling, refusal or settlement without a row. It does not establish upstream completeness. | | `pending` | Accepted positions have not all become durable. | | `partial` | Known sampling, refusal or settlement without a row prevents a complete measurement. | | `unknown` | Accounting is unavailable, outside its retained window, empty or cannot attribute input to the selection. | Later arrivals can change the next observation. A configured evaluation delay is time allowed for arrival, not proof of settlement. A quiet source, empty ledger or `complete` retained scan cannot replace intake evidence. ## Choose the right follow-up - Use [Coverage map](/docs/investigate/coverage-map) to compare declared services, routes and screens with observations. A declaration is not a capture-completeness certificate. - Use [Usage and history policy](/docs/manage/usage-and-ai-settings) to inspect or change history choices. - Use [Person export](/docs/manage/export-a-person) for an authorized subject archive. Its freshness contract is separate from an ordinary read. - Use [Account request objectives](/docs/respond/account-objectives) for their stricter activation and evidence requirements.