Read coverage and intake completeness

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 <RFC3339> --end-time <RFC3339>, 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 to compare declared services, routes and screens with observations. A declaration is not a capture-completeness certificate.
• Use Usage and history policy to inspect or change history choices.
• Use Person export for an authorized subject archive. Its freshness contract is separate from an ordinary read.
• Use Account request objectives for their stricter activation and evidence requirements.