REAL-TIME EVENT MONITORING

This is a standing monitoring/watch subscription on a defined event class, geolocation, or threshold domain: it defines the event-detection criteria/tripwires, the collection and alert cadence, the escalation routes, and the service levels under which we keep the client current over the term. It does NOT cover the one-off baseline threat assessment or geopolitical profile that seeds the event definition (Country Risk Assessment or similar), nor any staffed operational detail (GSOC watch-floor staffing / 24/7 operations center under the staffed retained-service archetype). Prescriptive throughout: this is what events we monitor, how rapidly we detect, and what we do when an event tripwire fires - not an analytic estimate of event probability.

Document Control

FieldValue
Service name[ ]
DIDOSINT-047
Event class / monitoring domain[ ]
Client / sponsor[ ]
Classification & handling[e.g., classification + caveats + dissemination control]
Version[ ]
Author / service owner[ ]
Effective date[ ]
Term / period of performance[e.g., start–end, auto-renew terms]
Seeding product (baseline)[e.g., reference to the Country Risk Assessment or threat assessment that establishes the event definition]

Scope, Authorities & Limitations

State the authorized scope (which event classes, which lawful source lanes, which geographies/thresholds), the engagement authority/consent basis, and what is explicitly out of scope; reproduce the verbatim caveats below; name the sibling products this service routes to.

This is a monitoring/operational service, not an investigation, a guarantee of detection, or legal advice. Collection is limited to lawful, authorized sources within the agreed scope; no unlawful access, intrusion, pretexting, or surveillance of non-consenting third parties is performed. Alerting is best-effort within the stated SLA and does not warrant prevention of any event.

BoundaryStatement
In scope[ ]
Out of scope[ ]
Authority / consent basis[ ]
Routes to (seeding product)[e.g., Country Risk Assessment]
Routes to (staffed services)[e.g., GSOC/watch-floor staffing, protective intelligence team]

1. Scope & Watch Criteria / Tripwires

Enumerate every event-type/threshold monitored; per the load-bearing rule each row MUST bind a tripwire (the observable event or metric threshold that fires it), implicitly a cadence (§2), and an escalation route (§4). Risk-score each watch item with the L×I key reproduced in §4. No row may omit a tripwire or an escalation route.

#Event class / thresholdObservable indicatorTripwire thresholdLikelihood (1–5)Impact (1–5)L×I (1–25)Severity tierEscalation route (→ §4)
[ ][ ][ ][e.g., metric/event condition that fires the alert][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ]

2. Collection Cadence & Sources

Specify each lawful collection lane keyed to the event classes above, its method, its detection/refresh cadence, the expected source grade (Admiralty, see Annex A), and the owning collector. Free/browser-first lanes before escalation-tier platforms; no live tool names here - describe the lane.

Source / laneEvent class(es) servedCollection methodCadenceExpected source grade (Admiralty)Owner
[ ][ ][e.g., description of the lawful collection method][e.g., continuous / real-time / hourly / daily][e.g., A–F × 1–6][ ]
[ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ]

3. Reporting Cadence & Product Format

Define each recurring product the service emits, what triggers it (scheduled cadence or tripwire-driven), its format, recipient, and delivery channel. Distinguish the routine cadence product from the on-tripwire alert product.

ProductTrigger / cadenceFormatRecipientChannel
[e.g., real-time tripwire alert][e.g., on event fire, per §1][ ][ ][ ]
[e.g., routine event summary][ ][ ][ ][ ]
[e.g., periodic service-health / coverage report][ ][ ][ ][ ]

4. Escalation & Notification Triggers

Map severity tiers to trigger conditions, the party notified, the notification method, and the acknowledgement target. Each tier must correspond to severity bands derived from the L×I key below; every §1 event class routes to a tier here.

Risk scoring key (reproduce verbatim): Likelihood (1–5) × Impact (1–5) = 1–25; 1–5 Low · 6–10 Moderate · 11–15 Elevated · 16–20 High · 21–25 Critical.

Severity tierL×I bandTrigger conditionNotifyMethodAcknowledgement target
[e.g., Critical][e.g., 21–25][ ][ ][ ][e.g., time-to-acknowledge target]
[e.g., High][e.g., 16–20][ ][ ][ ][ ]
[e.g., Elevated][e.g., 11–15][ ][ ][ ][ ]
[e.g., Moderate/Low][e.g., 1–10][ ][ ][ ][ ]

5. Service Levels (SLA)

Bind measurable service-level commitments to the cadence (§2/§3) and escalation timing (§4): detection/refresh timeliness, alert-delivery time per tier, product-delivery punctuality, availability, and the remedy when a target is missed. Every target must be measurable and have a measurement method.

MetricTargetMeasurement methodReportedRemedy / credit on miss
[e.g., alert delivery time by tier][ ][ ][ ][ ]
[e.g., event detection latency][ ][ ][ ][ ]
[e.g., monitoring availability / coverage][ ][ ][ ][ ]
[e.g., false-positive / quality bound][ ][ ][ ][ ]

6. Review & Renewal

State the cadence of formal service review, the change-control process for adding/removing event classes or adjusting cadence, and the renewal, re-scoping, and termination terms.

ItemSpecification
Service-review cadence[ ]
Event-class change-control[e.g., process to add/retire an event class per §1]
Cadence / scope adjustment process[ ]
Renewal terms[ ]
Termination / offboarding terms[ ]

Annex A - Source & Watch-List Register (graded)

Register every standing source and event class with its current Admiralty grade. Reproduce the scales verbatim; grade each sourced datum as a two-character code (e.g., B2).

NATO Admiralty source reliability (A–F): A Completely reliable · B Usually reliable · C Fairly reliable · D Not usually reliable · E Unreliable · F Reliability cannot be judged. NATO Admiralty information credibility (1–6): 1 Confirmed by other sources · 2 Probably true · 3 Possibly true · 4 Doubtful · 5 Improbable · 6 Truth cannot be judged.

Source / event classLane (→ §2)Reliability (A–F)Credibility (1–6)GradeLast verifiedNotes
[ ][ ][ ][ ][e.g., B2][ ][ ]
[ ][ ][ ][ ][ ][ ][ ]

Annex B - Onboarding / Offboarding & Data-Handling Checklist

Capture the standing-up and tearing-down steps and the data-handling regime over the term: authorization capture, baseline ingest, collection standup, retention/destruction, and offboarding.

StepPhaseOwnerStatus
[e.g., capture authority/consent + scope sign-off][e.g., onboarding][ ][ ]
[e.g., ingest seeding baseline (Country Risk Assessment or threat assessment)][e.g., onboarding][ ][ ]
[e.g., stand up collection lanes + event tripwires][e.g., onboarding][ ][ ]
[e.g., data retention / destruction schedule][e.g., steady-state][ ][ ]
[e.g., offboarding + data return/purge][e.g., offboarding][ ][ ]

END OF SERVICE PLAYBOOK

Model wiring

Generated from cell frontmatter at publish time.