Skip to content

E2: Read federation #20

Description

@gnanirahulnutakki

Goal. assemble a tenant-scoped, normalized fleet model from OCM-brokered reads and make cross-cluster correlation a first-class query — answering fleet-wide questions single-cluster tools structurally cannot. The read source is abstracted: facts come from a local kubeconfig context (day-0 local mode, E11) or an OCM-brokered spoke (day-N hub mode), behind one common source interface — so the local client and the hub are one code path above the source. F2.1 defines both source adapters.

Phase / depends. P1 · Depends on: E0 (connectivity), E1 (tenancy). Reads never require the write path and have their own blast radius and rate limits. Least privilege is by construction: the hub reads only what spoke agents report and only within the scope of the projected MSA token.

Capabilities: the source-abstract fleet model (local kubeconfig OR OCM spoke) — the shared engine behind the day-0 local wedge (E11) and the hub.

Features

  • F2.1 — spoke read collection and normalization
  • F2.2 — fleet model store with freshness and source stamping
  • F2.3 — cross-cluster correlation query
  • F2.4 — image/CVE fact ingestion and fleet-wide CVE search
  • F2.5 — staleness surfacing and abstention inputs

Tracked issues (already filed)

Exit criteria

  • A normalized, tenant-scoped fleet model is populated from ≥ 2 spokes, every record stamped with freshness and source.
  • A single cross-cluster correlation query returns a correct answer over ≥ 2 spokes with stale clusters flagged.
  • Fleet-wide image/CVE search works across the workspace.
  • Per-cluster staleness is surfaced in results and exported as an abstention input.
  • Reads never touch the write path and are bounded by MSA token scope.

Source: docs/EPICS.md, docs/SITH-NOTION.md · part of the Sith implementation backlog (see the master roadmap issue).

Child issues (filed for immediate build — Phase L)


2026-07 research addendum (market research T1 · T5; E2 spec PR #43)

Four-lens operational graph — new features (E2 spec §2, PR #43). The normalized fleet model grows from a flat fact list into a four-lens graph (LIVE / DESIRED / TIMELINE / TELEMETRY) correlated by OTel-semconv identity keys — the substrate the Investigation Brain (E14 #46) reasons over. Two features added:

  • F2.6 — four-lens operational graph (live/desired/timeline/telemetry per entity; TIMELINE = bounded ring of change events, TELEMETRY = query-through, never a telemetry store — SCOPE holds).
  • F2.7 — correlation keys / EntityRef on OpenTelemetry Kubernetes semantic conventions (k8s.cluster.name, k8s.namespace.name, k8s.pod.name, k8s.node.name, stable container.image.repo_digests as the only safe fleet-wide join input (normalize exactly one immutable sha256: value)). Facts with no resolvable EntityRef go to an unattached bucket, never mis-joined; joins are cluster+namespace-scoped by default.

T5 (standards). Pin the exact OTel semconv attribute names as the join keys in the F2.x contracts (spec §2.3) — connectors and OTel traces then align for free. standards-alignment.

Reasoning spun out. Root-cause reasoning over this graph is now E14 (#46), not folded into E2 — E2 owns the substrate (F2.6/F2.7), E14 owns the reasoning. Exit criteria for the graph substrate: E2 spec §6.1.

Metadata

Metadata

Assignees

No one assigned

    Labels

    epicEpic tracking issuephase-1Phase 1: read-only federationread-federationNormalized fleet model / cross-cluster readsstandards-alignmentMCP / OTel semconv / SLSA / client-go standards gate

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions