Notification Delivery Semantics／Alert Fatigue × Agent

AI/Agentの異常検出と人への通知を分離します。alert identity、dedup/grouping、persistence、severity、routing、suppression、resolutionを明示し、pageはactionableかつ緊急な影響へ限定します。

dedup・suppression・recovery smoothingはノイズ低減策であり、障害不存在や復旧完了の証明ではありません。

signal → alert instance → incident/group → route/suppress → notification/page → acknowledge/escalate → resolve/readback を別状態として記録します。

安定した故障単位をlabels/dedup keyへ使います。request ID、trace ID、raw prompt、retrieval query等の高cardinalityまたはsensitive値をalert identityへ直接使いません。

identity変更はdedup fragmentation、粗すぎるidentityは独立障害のcollisionを起こすため、rule revisionと共に監査します。

Prometheus型のforは条件が一定時間継続した後にfiringさせるためtransient noiseを減らせますが、重大な短時間障害まで一律に遅延させないようseverity別に設計します。

keep_firing_for等のrecovery smoothingはflappingや一時的なdata lossによるfalse resolutionを抑え得ますが、実サービスの復旧証明ではありません。

dedupは同一alert identityの反復eventをまとめます。groupingは複数alertをincident/context単位へ束ねます。suppressionはnotification/incident creationを止め得ます。

三者を同義にせず、suppressed eventもcoverage/forensics上必要なら保存し、suppressed count/rateを監査します。

pageへ昇格する条件は少なくとも user/business impact、urgency、明確なowner、実行可能なrunbook/escalationです。

情報提供のみ、単発trace failure、既知の非緊急degradationはdashboard、ticket、digest等へ分流します。

LLM/provider error・latency、tool/MCP failure、retrieval empty/stale/permission denial、queue backlog、identity failure、policy block、retry/duplicate side effect、model/provider failoverを候補signalとし、service SLIやtask-level invariantと相関させます。

単一Agent traceの失敗だけをpage条件にしません。

routing/suppression/dedupは後続automationのtrigger条件へ影響します。suppressed alertやdeduplicated eventが「新規alert追加」を条件とするautomationを発火させない製品挙動があり得るため��routing ruleとremediation triggerを組で試験します。

alert/incidentがresolvedになったことだけで復旧完了としません。service SLI、dependency health、queue/backlog、tool side effect、Agent task-level invariantをreadbackします。

GenAI telemetryのretrieval query、system instruction、input等はsensitiveになり得ます。notification payloadは最小化し、詳細は権限制御されたtrace/logへリンクします。

notification volume、dedup ratio、suppressed ratio、actionable/page ratio、repeat page、acknowledgement/escalation latency、false resolution、critical missを追跡します。

Prometheus alerting ruleはalert条件とfor/keep_firing_forを定義し、summarization、rate limiting、silencing、alert dependency等はAlertmanager等の別層へ委ねます。

PagerDutyではmatching dedup_key、suppression、Event Orchestrationの意味とservice/integration境界を固定し、plan/tenant固有挙動を一般化しません。

OpenTelemetry GenAI semantic conventionsはprovider識別やGenAI属性を標準化しますが、sensitive属性を通知へ無制限に複製する根拠にはしません。

dedup collision/fragmentation、groupingによる独立障害隠蔽、high-cardinality explosion、flapping、false recovery、delayed page、critical suppression、missing owner、broken runbook、notification outage、escalation誤設定、automation suppression、retry alert storm、telemetry loss、sensitive content leakage、severity/SLO driftを想定します。

2026-10-06時点のPrometheus/Alertmanager、PagerDuty、OpenTelemetry公開資料に基づく監査前candidateです。organization環境へのlive notification/suppression testは未実施です。

AI/Agentの異常検出と人への通知を分離します。alert identity、dedup/grouping、persistence、severity、routing、suppression、resolutionを明示し、pageはactionableかつ緊急な影響へ限定します。dedup・suppression・recovery smoothingはノイズ低減策であり、障害不存在や復旧完了の証明ではありません。GenAIのprompt/query等を通知本文やalert identityへ無制限に載せず、必要な詳細は権限制御されたtelemetryへリンクします。

organization SLO/severity、incident platform/plan、on-call/escalation、dedup/group key、suppression policy、quiet hours、notification reliability、telemetry retention/access、sensitive-data classification、Agent/provider/tool ownership、remediation automation、acceptable page volume、tenant realized behaviorは未確認です。

--- MANIFEST CANDIDATE --- {"candidate_id":"CANDIDATE-EA269-FIRST-20261006-C1","ea_id":"EA-269","revision_id":"EA-269-FIRST-20261006","target_path":"content/staging/EA-269.md","precondition":{"mode":"PATH_GUARDED","expected_before":"ABSENT","live_main_sha":"7e9370928c0d365961f7c0b5580b352d5916581e"},"payload_sha256":"dd74d47edeae15a843d46ea7bd4e4a8abfdf85af1fbbfacbcf2e286ced41c3e4","evidence_sha256":"09613c36a2c5a00a55930b2493bea5c40a2f5f930d60e5397f454e249d331abc","manifest_sha256":"96e2482291df6c8baf1e475a34589abdedfc272a5bb1a1799b00d1255df43229","tests":"13/13 PASS","ready":false,"audit_pass":false}