Monitoring and incident response
Control ID: LL-FDE-OPS-002
Status: automated source control available; named ownership, paging, status publication, and response commitments are not yet operational
1. Current automated control
.github/workflows/monitor-public-draft.yml runs hourly and on demand after the repository is activated. It performs read-only checks against https://benchmark.lockedinlabs.ai for:
- availability of eight critical publication routes;
- same-origin resolution and HTML response;
- document and response-header noindex controls;
- Content Security Policy, framing protection, and MIME-sniffing protection.
The workflow retains a machine-readable receipt for 14 days. A failed workflow is a signal for operator review, not a public incident declaration or a measured SLA breach.
2. Service indicators and initial objectives
The following are proposed operating objectives, not published commitments:
| Indicator | Proposed internal objective | Evidence |
|---|---|---|
| Critical-route availability | All 25 benchmark-only routes return HTTP 200 on every scheduled probe, the two plain-text assets return text/plain, and the unknown-path probe returns 404 |
live-verification.json |
| Publication posture | Every checked response and page remains noindex | header and HTML checks |
| Security-header integrity | Required CSP, frame, and content-type controls remain present | response headers |
| Deployment traceability | Every production change resolves to an exact main commit and deploy receipt | workflow run plus evidence artifact |
| Recovery readiness | A known-good commit can be redeployed without changing site identity | recorded rollback exercise |
External uptime, multi-region availability, latency percentiles, real-user monitoring, JavaScript error capture, certificate-expiry paging, and status-page publication are not yet implemented.
3. Severity model
| Severity | Example | Immediate action |
|---|---|---|
| SEV-1 | Wrong site/domain, credential exposure, private data exposure, scoring/intake unexpectedly active, or malicious content | Restrict or remove affected surface, rotate credentials, preserve evidence, invoke security/privacy authority |
| SEV-2 | Site unavailable, noindex removed, external redirect, security headers missing, or materially false publication state | Hold deployments, restore last verified build, assess search/cache exposure, correct public status |
| SEV-3 | Broken critical route, major accessibility regression, incorrect citation/status link, or substantial content failure | Triage, patch through reviewed workflow, document impact and correction |
| SEV-4 | Cosmetic or non-material metadata defect | Schedule correction and preserve change history |
Severity assignment is provisional until named security, privacy, publication, and operations owners approve an incident policy.
4. Response sequence
- Detect and preserve: retain the monitor/deploy run, exact time, route, headers, commit, and provider deploy ID.
- Classify: determine whether the issue affects security, privacy, benchmark authority, publication accuracy, accessibility, or availability.
- Contain: pause deployments; for SEV-1/2, restore the last verified public-draft build or temporarily restrict the affected surface.
- Assess: identify exposed claims/data, cached or indexed copies, affected routes, and start/end times.
- Correct: use a reviewed commit and the standard deployment workflow; never mutate the historical evidence record.
- Verify: rerun live checks and any affected browser, contract, accessibility, or source gate.
- Communicate: update the public correction/retraction record when the issue changes a material publication claim; notify affected people only through an authorized private channel.
- Learn: record root cause, control failure, corrective action, owner, due date, and a regression test.
5. Activation blockers
Before monitoring can be described as an operational service, assign and test:
- primary and backup operations owners;
- security, privacy, accessibility, editorial, and release escalation owners;
- alert routing and acknowledgement process;
- a private security-reporting channel;
- a public correction route and status location;
- credential rotation and break-glass process;
- at least one recorded rollback exercise;
- retention appropriate for release and incident evidence.
Until then, GitHub workflow failures must not be presented as staffed 24×7 monitoring or guaranteed incident response.