WatchCrux Findings in WebCrux

WebCrux v1.0 budgets an optional Findings surface so everyone can see the latest WatchCrux PASS/WARN/FAIL status alongside answers (§Trust & Integration, §UI Surface, §Week 5 milestones). This page explains how those audits arrive, what each severity means, and how the UI reacts without derailing the core “Ask → Inspect → Save” flow.

When Findings Appear

  • Answer view: A slim banner under the summary shows the most recent WatchCrux verdict for Engine + WebCrux. Audit IDs, timestamps, and affected subsystems sit behind an expand toggle.
  • History & Saved: Rows inherit the verdict that was current when the answer was generated. If WatchCrux later downgrades a subsystem, the row shows a badge so reviewers know to re-run in a stricter mode.
  • Trust status panel: Teams with Governance or Enterprise plans can open a full Findings drawer with drill-down links to operator artefacts (Grafana panels, receipts, SBOM hashes).

The surface is read-only-WebCrux never edits or hides WatchCrux output. If the Findings API is not enabled for a tenant, the UI quietly omits the banner.

Severity Reference

StateMeaningTypical Action
PASS (green)WatchCrux sampled /healthz, /metrics, and receipts without detecting drift.Proceed normally; proofs remain valid.
WARN (amber)Minor drift (version lag, queue back-pressure, partial receipt replay).WebCrux shows context guidance (e.g., “Expect slower answers-Engine p95 > 2 s”). Users can keep working but should re-run critical answers in audit mode.
FAIL (red)Material gap (missing receipts, incompatible SDK, audit failure).Ask + Save stay read-only for affected modes; WebCrux prompts users to subscribe for incident updates or switch to cached history until ops clears the finding.

Severity is always accompanied by source plane, detected_at, and evidence hash so operators can prove the state change.

Delivery Path

sequenceDiagram
    participant W as WatchCrux Auditor
    participant O as OpsCrux API
    participant B as WebCrux BFF
    participant U as Web UI

    W->>O: Publish Findings payload (PASS/WARN/FAIL + artefacts)
    O-->>B: Signed webhook + cache entry
    B-->>U: Inject findings() into `/api/answers` response + SSE channel
    U->>U: Render banner, badges, and drill-down drawer

sequenceDiagram
    participant W as WatchCrux Auditor
    participant O as OpsCrux API
    participant B as WebCrux BFF
    participant U as Web UI

    W->>O: Publish Findings payload (PASS/WARN/FAIL + artefacts)
    O-->>B: Signed webhook + cache entry
    B-->>U: Inject findings() into `/api/answers` response + SSE channel
    U->>U: Render banner, badges, and drill-down drawer

The BFF keeps a short-lived cache (≤60 s) so every answer sees consistent state even if multiple browser tabs request data in parallel. Tenants that opt out of Findings never receive the webhook and therefore render no banner-no branching logic in the UI.

How Users Should Respond

  1. Read the summary: Every banner starts with “WatchCrux: PASS/WARN/FAIL” plus a plain-language note (“Verified mode receipts replaying cleanly”).
  2. Inspect artefacts: Clicking the chevron reveals the Operator ID, SBOM digest, and the latest /healthz snapshot hash.
  3. Decide:
    • Pass → keep working.
    • Warn → consider switching to audit mode or re-running once the warning clears.
    • Fail → rely on history/saved answers, export receipts you already trust, and subscribe to status updates.

This rhythm keeps the experience upbeat-users still have a clear path forward-even when the platform is under heightened scrutiny.

Operator Duties

  • WatchCrux: Runs scheduled audits, signs findings, and keeps immutable receipts.
  • OpsCrux: Distributes findings through the tenant graph, enforces entitlements, and records acknowledgement events.
  • WebCrux: Presents the data exactly as supplied, enforces degradations (e.g., read-only Ask), and links back to OpsCrux for incident details.

Together they deliver the transparent, receipt-backed trust surface promised in the master plan without adding manual burden to end users.

Table of Contents