# Synorb agent guide: manifests/query response diagnostics and freshness This page is part of the Synorb agent guide at https://synorb.com/agent-guide.md. The diagnostic fields of a query response, the `response_profile` setting, delivery cadence, and how to read freshness. ## `manifests/query` response diagnostics Every `POST /manifests/query` response can include additive diagnostic fields. They tell you whether the answer is safe to use and what to do next. Route on these fields before you treat an empty page or a count as definitive: | Field | Contract | | --- | --- | | `coverage` | Authoritative outcome status and reason. A blocked, unresolved, or authorization-failed scope is not an exact zero. | | `candidate_projection` | Pre-execution candidate-set proof, including `truncation_reason` when a planned or executed scope cannot be proven. | | `final_scope_authorization` | Proof that the final executed scope matches the authorized request. If `authorized=false`, correct scope and re-plan; do not silently broaden. | | `citation_contract` | Always present in successful query and exec data. `status=required` means preserve returned citations and source URLs; `status=none` means no Manifests were returned. | | `did_you_mean` | Canonical suggestions for unresolved Tag or source channel input. Ask or retry with the suggested field value. | | `result_fingerprint` | Stable identity for the returned result page after scope, authorization, and pagination. Use for cache/audit comparisons, not as a freshness timestamp. | `https://synorb.com/docs` and `https://synorb.com/openapi.json` describe additive response-field changes. When the contract changes, refresh generated clients from the OpenAPI schema. ### Read the full Manifest: `response_profile` The default profile is `full`. Each Manifest then carries its Claims (`claim_text`, `claim_type`, `confidence`, evidence), the Signal, the Brief, the Record and source metadata, the Tags and the citations. Read all of it before you write. Never write from titles or one-liners. `diagnostics`, `coverage_outcome`, `candidate_projection` and `manifest_index` are operator and proof blocks of tens of KB. Synorb drops them by default under either profile. Pass `include_diagnostics=true` to restore them. `response_profile` never changes which Manifests Synorb returns or bills. `quota_charged` and the billed count are identical between `full` and `slim` for the same request. A Manifest you already pulled is not billed again in the same billing period. `response_profile` accepts `full` (default) or `slim`. Synorb does not recommend `slim`; it drops source metadata and citation authority. Full contract: see "Slim responses" in `https://synorb.com/docs`. ### Plan delivery cadence and freshness The 72 Hour Agent Demo, Starter, and Individual use Daily Batch (`refresh_tier=daily`) with a prior-day `available_through` ceiling. Professional, Startup, and Enterprise use Continuous Delivery (`refresh_tier=continuous`) with no plan-imposed daily date ceiling. Source and index availability can vary; do not promise a fixed publication-to-delivery time. Relative `days` and `lookback_hours` requests default to that availability ceiling (`available_through`, also named `latest_allowed`), not to the wall clock. So `days=1` means the latest available day. Read the `/account` `temporal` diagnostics (`refresh_tier`, `available_through`, `wall_clock_date`, `lag_days`) and the `temporal` object of each query. Do this before you treat an empty recent window as evidence that a Stream has no content. `lookback_hours` rounds up to whole publication days. A value of 24 is one date, so two daily pulls do not overlap. Use 48 when you want one day of overlap. For this product's phrase "last week," request a rolling seven available days ending at `available_through` (the default anchor). Do not use the previous calendar week. For example, if the returned ceiling is 2026-10-06, report the inclusive range September 30 through October 6. Use the effective temporal window in the response when it is available. Do not calculate from the wall clock. Within a Manifest response, use `temporal.window_ceiling_age_seconds` for the age of that availability window. Legacy `temporal.lag` is the same value; it is not index freshness. For MCP `synorb-manifests`, use top-level `index_staleness_seconds` to judge the serving index. It measures the age of the newest published/matched Manifest that the index has observed. Synorb derives it from `index_freshness.last_indexed_published_at`. Synorb omits it when the server cannot measure it. It never reports zero for unknown freshness.