Separate Compose-service CPU subject from provider-demand attribution in the saturation contract

Context

PR #16878 truth-folds the statement that nodeCommand === false proves a container has no other processes. Its two cited native-Ollama receipts are real and correctly bounded:

• #16830 comment 5235152342 proves an early-disconnect embedding runner persisted at 397–400% after Neo clients and established sockets were gone.
• #16830 comment 5239751831 proves a later CPU-only specimen held 399.4% while only health/residency polling arrived; it explicitly leaves the work's origin unproved.

The fold then uses those receipts to say the container-wide CPU figure speaks for neither the Compose service nor the runner. That conclusion does not follow. The runner is an Ollama-owned process inside the local-model Compose service, so the receipt establishes unexplained/residual provider demand, not that the CPU has a different deployment subject.

PR #16884 makes the distinction operational: it deliberately keeps whole-local-model container CPU as service evidence and combines it with expected-model residency plus recorder-owned provider activity. It does not add process-cardinality or per-runner CPU evidence.

Live latest-open sweep: checked the latest 20 open issues and exact searches for process-cardinality, nodeCommand, and retirement trigger on 2026-08-10; only #16877 matched. The all-state A2A sweep over the latest 20 messages found no overlapping claim.

The Problem

The saturation contract currently collapses three independent questions:

1. Observation subject: the Docker ratio describes the exact Compose container/service.
2. Work ownership: a process may be owned by that service even when no current client awaits its work.
3. Demand disposition: current provider work may be accounted, residual after disconnect, stale, or unknown.

“No inference arrived in the sampled window” answers the third question. It does not make an Ollama runner foreign to the local-model Compose-service subject.

The same conflation makes the retirement trigger stale before merge: #16878 says #16830 will provide runner/process-cardinality evidence that replaces the generic proxy, while #16884 explicitly provides whole-container CPU + residency/activity and makes no per-process attribution claim.

The Architectural Reality

• ContainerHealthDiagnosisService targets {kind: 'compose-service', id: serviceKey}.
• DeploymentRuntimeAccessService verifies the resolved container's com.docker.compose.service label before acting.
• #16884 binds CPU samples to an exact container incarnation, then uses provider activity to distinguish legitimate current demand from a residual-load candidate.
• No shipped surface currently attributes CPU to an individual process or runner.

The Fix

After PR #16878 lands, refine the shared saturation-subject contract and its structural guard:

• keep the truthful statement that nodeCommand === false is not process-cardinality proof;
• state container CPU as exact Compose-container/service evidence for service-owned processes;
• separate subject attribution from provider-demand disposition;
• describe the Ollama receipts as residual/unexplained demand evidence, not foreign-subject proof;
• replace the #16830 “process-cardinality” retirement promise with the mechanism #16884 actually supplies, or name a future process-scoped CPU owner if generic authority withdrawal remains desired; and
• preserve every causal bound: neither receipt proves the origin of a historical deployment incident.

Decision Record impact

none — documentation and structural-test authority within the existing ADR-0025 evidence-before-action and ADR-0026 lifecycle boundaries.

Acceptance Criteria

• The shared contract distinguishes Compose-service CPU subject, process/work ownership, and provider-demand disposition as separate axes.
• An Ollama-owned runner is not called foreign to the local-model Compose-service subject merely because no current request is arriving or awaiting it.
• The two #16830 receipts remain quoted with their exact causal bounds and are framed as residual/unexplained-demand evidence.
• The retirement trigger no longer claims #16830/#16884 delivers process-cardinality or per-runner CPU evidence.
• The contract names #16884's actual composition: exact-container CPU + expected-model residency + recorder-owned provider activity + last-boundary demand veto.
• A structural mutation guard fails when subject attribution and demand disposition are collapsed again.
• Zero production behavior changes; saturation thresholds, current generic authority, and lifecycle actions remain untouched.
• Ticket/PR/source prose stay mutually consistent.

Out of Scope

• Adding process-scoped CPU or process-cardinality telemetry.
• Changing #16884's residual-load diagnosis or actuator path.
• Withdrawing generic non-Node saturation authority.
• Proving the origin of any historical CPU burn or corpus failure.

Avoided Traps

• No-demand means wrong subject. It means unexplained or residual work, not necessarily a foreign workload.
• Process count means work ownership. A multi-process service can still own every process.
• Naming #16830 as future magic. Its current implementation must be described by what it measures.
• Smuggling behavior into a prose repair. Runtime policy belongs to a separately admitted lane.

Related

Related: #16830 · #16855 · #16877 · PR #16878 · PR #16884

Origin Session ID: 878f05af-2c4e-4da2-a5c2-9e4af666fcb8

Retrieval Hint: Compose service CPU subject provider demand residual Ollama runner process cardinality

Authored by Emmy (GPT-5.6 Sol Ultra, Codex).