Control Tower Monitoring, Detection, and Response
Connect inventory, authority, health, quality, safety, cost, drift, incidents, response, and verified closure in one operating view.
A focused view of boundaries, contracts, state, authority, failure paths, and tradeoffs drawn from this chapter.
4. Control-tower subject model
Every view starts with a FactorySystemRecord and links current lifecycle,
risk, autonomy ceiling, owners, releases, workflows, capabilities, models,
tools, data, policy decisions, denials, exceptions, evidence freshness,
dependencies, incidents, cost, performance, and outcomes. The current response
records owner, severity, state, deadline, action, acknowledgement, verification,
and escalation.
7. Response actions and authority
- Continue with observation: variation is explained and within policy.
- Pause: hold new steps at a safe checkpoint while preserving state.
- Cancel: end work and reconcile partial effects.
- Retry: repeat only under the operation's idempotency contract.
- Fallback: select a prequalified alternative with explicit changed limits.
- Reconfigure: follow change control; never silently mutate live policy or prompts from an anomaly.
- Rollback: restore a known version and verify data/outcomes.
- Quarantine: block selection and isolate the affected subject.
- Retire: remove authority and traffic, retain evidence, and delete by policy.
Each action displays requested effect, subject, authority, risk, evidence, deadline, expected acknowledgement, recovery implication, and alternate action.
8. Detection-to-closure contract
finding:
id: finding-811
subject: factory-system:payments-delivery@7
rule: behavior-drift/tool-sequence@3
baseline: baseline:bounded-change@12
observed_window: 2026-08-30T17:00:00Z/2026-08-30T18:00:00Z
evidence_refs: [trace-query:91, evaluation:44]
severity: high
owner: role:runtime-oncall
deadline: 2026-08-30T18:15:00Z
response: quarantine-capability-version
control_ref: control-command:204
state: verifying
recovery_evidence: evaluation:49
residual_risk: "Affected prior releases under review"
A finding progresses through new, triaged, responding, contained,
recovering, verifying, closed, or escalated. Closure records detection
quality, response, affected scope, verified recovery, residual risk,
notifications, postmortem, and improvement disposition.
9. Failure modes
| Failure | Protection |
|---|---|
| Dashboard stale during incident | Show last-updated and authoritative links; use control APIs directly |
| Duplicate alerts | Subject/rule/window deduplication and incident grouping |
| Missing telemetry | Coverage alarm and explicit uncertainty; do not infer normal |
| Automated response loops | Bounded actions, cooldowns, durable state, human escalation |
| Compromised signal source | Cross-source corroboration and evidence integrity |
| Response command not enforced | Separate acknowledgement and observed verification deadlines |
| Recovery causes regression | Independent post-recovery quality and outcome checks |
11. Tradeoffs and nonclaims
A unified view improves coordination but can become a dangerous administrative super-console. Keep it a least-privilege projection with narrow control APIs, step-up authorization, dual control where required, and full audit. This review-ready design does not prove detection quality, response time, closure effectiveness, or production accessibility.
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence