Ops / QA Product Operating Model

Status: working memory Date: 2026-05-24

This note locks the product frame before another UI pass. It is intentionally short and operational: agents should use it to decide what belongs in a tab, what belongs in the API, and what must not become another decorative widget.

Core Rule

CareerVector QA, Ops, and Wiki are three operating views over one shared knowledge spine. A surface is complete only when the same thing exists in this order:

API contract -> MCP tool/readout -> responsive UI projection -> tests/proof

The UI is not the product source of truth. The UI is the human projection over the same objects and actions an agent must be able to use through REST/MCP.

Shared Surface Grammar

Each app should keep a small number of primary tabs. Primary tabs are either a canonical hub object POV or a deliberate joker/action workbench.

QA
  Behaviour   hub POV: promised behaviour
  Investigate joker: changed code/problem -> graph path -> likely proof
  Queue       joker: CI execution now/future/past, capacity, reorder
  Suites      hub POV: proof sets
  Tests       hub POV: executable witnesses

Ops
  Anomalies   hub POV: harmful expectation mismatches
  Events      hub POV: meaningful operational occurrences
  Infra       hub POV: IaC-backed substrate, cost/quota/capacity/service lenses
  Inspector   joker: workspace neighborhood and attached evidence
  Sysadmin    agentic chatbot that can propose and execute Ops API actions

Wiki
  Atlas       graph navigation over all hubs
  Canon       idea/behaviour/architecture/vocabulary POV
  Codebook    implementation/code/source-backed POV
  Journal     hub POV: event interpretation and memory
  Librarian   query/chatbot over the knowledge spine

Queue and Inspector are intentionally different from the object POV tabs. Queue is where the system schedules and observes CI. Inspector is where the system looks at one workspace and composes everything known about it.

The first Sysadmin execution contract is API-first: POST /sysadmin/chat returns allowlisted action proposals, and POST /sysadmin/actions/execute executes one proposal only after re-deriving it from the same prompt. Mutating actions require confirm: true; MCP mirrors this with ask_sysadmin and execute_sysadmin_action.

What Not To Promote

Some nouns are useful but should not become primary tabs:

  • FinOps is an Infra lens for cost, quota, runway, and provider pressure.
  • Analytics is an internal analysis mode or panel, not a product hub.
  • CircleCI is the current CI provider behind QA execution; the product word is CI unless the panel is showing provider-specific details.
  • FalkorDB is the current GraphDB provider; shared UI/API/MCP language should say GraphDB.
  • Raw Axiom, Cloudflare, Pulumi, GitHub, and Google rows are provider observations. They can back events, anomalies, infra nodes, journal notes, and QA evidence, but they do not define the graph.

Done Means Done

Half work is not work. A product slice is shippable only when it has:

  • stable REST routes for the object/action shape
  • MCP parity through the REST contract
  • migrations or data seeding for the durable store
  • tests for the contract and the important renderer branches
  • compact responsive UI that works on mobile and wide screens
  • live/browser verification for user-visible changes
  • deploy/push proof when the user asked for web-visible product work

Compatibility layers are temporary only when they reduce rollout risk. They must not keep old product vocabulary alive after the object model is clear.

UI Shape

Use a dense operator cockpit rather than marketing layout. Grafana is the useful reference pattern: dashboards are made of panels arranged in rows/tabs, with filters and variables controlling what panels show. CareerVector should borrow the density and drill-down shape, not the vendor vocabulary.

Panel rules:

  • every tile answers one operational question
  • summary tiles stay short enough to scan
  • detailed evidence expands in place or opens an object route
  • wide screens tile horizontally, narrow screens stack vertically
  • cards do not nest inside cards
  • empty states explain the missing API/data edge, not the UI feature
  • provider-specific wording appears only where it helps operate that provider

Integration Rule

The API object view is the join point. For any important object, the read model should compose:

domain payload
semantic node and sanctioned edges
backing/evidence rows
provider observations
Git/file references
GraphDB projection status
related QA/Ops/Wiki context
suggested machine actions

MCP tools call those object-view routes. UI pages render those same shapes. This is how a human view and an agent view remain the same product instead of two divergent dashboards.

GET /workspaces/:id/inspector is the first concrete Ops realization of this shape. It currently composes workspace detail, related events, anomalies, journals, and audit rows; semantic edges, provider observations, GraphDB projection status, and suggested machine actions are reserved for follow-up passes.

Source: wiki/content/working-memory/ops-qa-product-operating-model.md