Blueprint · operating model

JobCache management

JobCache operations turns product and corpus evidence into monitoring, support, recovery, cost, and audit workflows.

Cell 2.4 · operations · governance · evidence
  • JobCache Ops evidence to Monitoring + alerting: observe
  • Monitoring + alerting to Support + recovery: investigate + act
  • Support + recovery to Cost + audit: record outcome
observeinvestigate + actrecord outcome
storemixed

JobCache Ops evidence

Health, corpus, freshness, sources, devices, routing, cost, audit, and recovery projections.

Open layer ↘
processmixed

Monitoring + alerting

Service and corpus signals become owned thresholds, alerts, and investigations.

JobCache Ops
boundarymixed

Support + recovery

Named actions correct product, session, source, or corpus problems at the owning boundary.

JobCache
storemixed

Cost + audit

Usage, charge targets, commercial separation, commands, and recovery retain evidence.

JobCache Management
policy becomes controlsusage, policy, cost, and auditobservations, controls, and recovery
  1. 01 · store · mixed JobCache Ops evidence

    Health, corpus, freshness, sources, devices, routing, cost, audit, and recovery projections.

    Open deeper layer ↘
  2. 02 · process · mixed Monitoring + alerting

    Service and corpus signals become owned thresholds, alerts, and investigations.

    JobCache Ops
  3. 03 · boundary · mixed Support + recovery

    Named actions correct product, session, source, or corpus problems at the owning boundary.

    JobCache
  4. 04 · store · mixed Cost + audit

    Usage, charge targets, commercial separation, commands, and recovery retain evidence.

    JobCache Management

Flows

  • JobCache Ops evidence → Monitoring + alerting observe
  • Monitoring + alerting → Support + recovery investigate + act
  • Support + recovery → Cost + audit record outcome
as built target / open Boundary arrows open the neighbouring module; ports stay machine-only

Management

Outcome

Give humans and agents one explainable way to observe, understand, and intentionally change the system without creating shadow schedulers, hidden database writes, or unaudited control paths.

Full-height Management rail

02 policy · obligations · governance
09 JobCache operation
09 observability · monitoring · Ops · QA · Status · Wiki
09 CareerVector operation
14 change · release · recovery · audit · accountability

Management owns the entire fourth column. It is a federation of operational perspectives and product-owned control boundaries, not a common backend and never a superuser over JobCache, CareerVector, AI providers, user workspaces, or participant devices.

Perspectives

Perspective Role
Ops Authenticated diagnosis and named operator commands
QA Tests, suites, releases, regressions, and evidence
Status Bounded public service truth and incident communication
Wiki Git-backed architecture, decisions, runbooks, code links, and retrieval
Observability Metrics, logs, traces, costs, freshness, drift, and audit events

These perspectives may share schemas, navigation, and knowledge. Their runtime data and authority remain owned by the relevant product.

The internal subdivision and shared envelope are defined in Management Federation. Management is a federation of three product authorities, not a common backend: JobCache Management, Internals Management, and CareerVector Management publish bounded observations into shared perspectives while retaining their own data and execution authority.

CareerVector's terminal TUI and Tauri desktop app add device-side operational boundaries. Management may own release manifests, signed artifacts, connector-version policy, conformance evidence, and content-free error classes. It does not remotely control either client, receive provider credentials, or turn a private device into an operator data source. Device diagnostics cross only when the workspace participant explicitly supplies a bounded support bundle.

Control model

Every state-changing action is a typed command with declared authority, scope, preconditions, expected evidence, and an immutable receipt. Dashboards are projections; they do not acquire write authority merely by displaying state.

The same envelope crosses each product-management seam:

product-owned observation -> Management projection -> investigation
                         -> typed command intent -> product-owned execution
                         -> receipt + verification -> Management projection

The recursive command layer is specified in Management Command Contract.

AI-native operator

The agent operator reads the same architecture and evidence as a human. It must be able to trace an alert to a module, contract, implementation, test, deployment, and permitted action. Unknown authority or missing evidence means explain and escalate, not improvise a write.

Current state

Wiki, QA, Status, CareerVector Ops, JobCache Ops, and the shared Ops aggregation layer are as-built perspectives with different levels of evidence. A single normalized observation envelope, cross-product correlation contract, consistent command/receipt protocol, and complete architecture-drift gate remain target work.

Decisions still required

  • Command and approval model.
  • Unified observation envelope, classification, correlation, and retention.
  • Incident and change-management lifecycle.
  • Cost, quota, budget, and capacity controls.
  • How architecture drift becomes a failing quality signal.
  • TUI and Tauri release/connector supply-chain evidence and participant-controlled diagnostic bundles.

Completion evidence

Run the same proof for JobCache and CareerVector: read-only correlation from a symptom to runtime evidence, followed by a separately authorized, audited, idempotent product-owned action and verified recovery. Removing Management must leave both products able to execute and recover on their own.

Source: architecture/modules/management.md