# Intelligence Center operations

The product remains hidden while `intelligence.enabled=false`, but deterministic
snapshot production is intentionally live. This lets operators validate real
scores and source coverage before the menu or any LLM generation is opened.

## Daily snapshot

- Job: `intelligence.snapshot_daily`
- Schedule: `20 7 * * *`, UTC
- Weight/SLO: heavy gate, daily-digest SLO
- Subject: `platform / platform / business_shared`
- Regional assets: one `domain / assets` snapshot per unique active office set;
  global administrators are excluded and identical office sets share one snapshot
- Side effects: one immutable snapshot only when the versioned facts Hash changes
- Model calls: always zero

The handler must fail on code, privacy-contract, catalogue, or scoring errors.
An expected source outage is different: the source provider returns unavailable,
the snapshot is stored with lower confidence, and the handler records the failed
provider names in its result summary.

Check the scheduled-job run summary for `snapshot_id`, `facts_hash`,
`score_version`, `confidence_score`, `provider_failures`, and `model_calls=0`.
Re-running unchanged facts must return the same snapshot id with `created=false`.

## Weekly AI brief

- Job: `intelligence.analysis_daily` (the stable key retains its run history)
- Schedule: `35 7 * * 1`, UTC (Monday)
- Model calls: one only when facts changed; manual force refresh remains available

The platform snapshot remains daily and deterministic. The AI narrative is a
weekly, concise summary; it must copy figures from cited facts and does not
aggregate or calculate new figures. Invalid model output is discarded rather
than displayed.

## Client-error health telemetry

The crash endpoint first emits the controlled forensic log, then attempts the
PII-free day/surface counter in an independent transaction bounded to 500ms.
Database failure does not hide the crash or fail the endpoint; the log remains
authoritative and the counter is an operational trend, not an audit ledger.

The aggregate stores no person, route, component, message, stack, user-agent, or
derived hash. It grows by at most two rows per UTC day and is retained for the
long-term trend. Scoring reads exactly the latest seven complete UTC calendar
days and warms its confidence over the first seven completed days from the
migration-479 UTC epoch. Same-day re-runs therefore retain the same cutoff.
Reports received today intentionally affect the score after the UTC day closes;
operators must not interpret that one-day boundary as missing telemetry.

## Release boundary

Until final acceptance:

- keep `intelligence.enabled=false`;
- do not expose Intelligence HTTP/MCP reads to users;
- do not enable platform or domain LLM generation;
- use database/admin-only inspection for score validation.

## Access validation

The public read layer must consume `resolve_access_plan`; it must not re-create
role checks in routers or MCP tools. Validate with the request's narrowed role
set, so `X-View-Role` remains a real downgrade. Public payloads use
`SnapshotProjection.public` only. `local_reference_map` stays server-side until
each referenced object passes its existing domain RBAC.

An asset administrator with no active managed office receives no Intelligence
scope. Finance, cloud admin, and global admin may be marked for a separately
cached paid-cost audience; management remains on shared business-basis cost.

Read endpoints are `/api/v1/intelligence/{overview,history}` and
`/api/v1/intelligence/domains/{domain}`. A page load may call only these GETs;
every response reports `model_calls=0`. Treat `status=partial`,
`score_version_mismatch=true`, or non-empty `missing_dimensions` as a visible
data-quality condition, never as a reason to substitute zeros or old audiences.
The exact MCP twins are `intelligence_get_overview`,
`intelligence_get_domain`, and `intelligence_get_history`; they must stay on the
same read service and feature gate as HTTP.