# Official sources

Use this reference only when you need source grounding for AWS service behavior or the detailed source list.

## AWS documentation

Use these as starting points, not as proof of the user's live AWS state:
- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html
- https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html
- https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor.html
- https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html

## Grounding rule

Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.

## Current MCP/documentation refresh (2026-06-02)

Service facts from official docs:
- CloudWatch provides operational visibility through metrics, alarms, dashboards, logs, application performance monitoring, infrastructure monitoring, cross-account monitoring, and network/internet monitoring.
- Trusted Advisor inspects AWS environments and can surface recommendations for cost, performance, availability, security, and service limits depending on support plan and feature availability.

Sampled live evidence:
- Read-only regional availability sampling reported `CloudWatch+DescribeAlarms` as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
- `Health+DescribeEvents` was reported `isAvailableIn` in `us-east-1` and `Not Found` in `us-west-2`, `eu-west-1`, and `ap-southeast-1`; treat Health as account/global-style evidence unless local tooling proves otherwise.

Review implications:
- A daily brief must separate live alarms/incidents, AWS Health events, cost anomalies, deployment changes, security/compliance signals, and backlog risks.
- Do not summarize unknown systems as healthy; say exactly which sources were queried and which were not.

# Operations Briefing Signal Quality Guide

Use this reference when preparing AWS daily or weekly operations briefings from CloudWatch, AWS Health, Trusted Advisor, cost, deployment, incident, and backlog signals.

## What people get wrong

The lazy story is:

> Summarize dashboards and call it an ops brief.

Wrong. A briefing is an evidence-weighted decision artifact. Dashboards show slices of reality, not ownership, impact, trend, or actionability.

Common bad assumptions:

- No active alarms means no operational risk.
- AWS Health events automatically map to impacted workloads.
- Trusted Advisor checks are always current and universally available.
- Cost spikes are operational incidents without business context.
- Deployment success means customer impact is zero.
- Open tickets can be summarized without owner, age, severity, and blocker state.

## Briefing-specific failure modes

- Mixing confirmed incidents, unverified alerts, and stale backlog as equal-priority items.
- Reporting alarm counts without affected service, owner, severity, duration, and customer/business impact.
- Ignoring deployment timeline around incident onset.
- Presenting cost variance without service, account, usage type, tag, or commitment context.
- Omitting AWS Health or support-case context during regional/service disruption.
- Producing action items without single owners or deadlines.

## Minimum safe workflow

1. Define audience and time window: executive daily, engineering handoff, weekly risk review, or incident standup.
2. Gather read-only signals: alarms, incidents, AWS Health, deployments, cost deltas, Trusted Advisor, open tickets, and known risks.
3. Label each item as confirmed, sampled, stale, inferred, or missing evidence.
4. Rank by customer impact, security/compliance risk, operational urgency, and business cost.
5. Convert noise into actions: owner, next step, due time, blocker, and escalation path.
6. Separate “watch” items from “act now” items.
7. State blind spots explicitly; do not imply the account is healthy from narrow evidence.

## Verification targets

- CloudWatch alarms and metric trends for the reporting window
- AWS Health events and account/organization visibility scope
- Trusted Advisor check status and support-plan/access limitations
- Cost Explorer or Budgets variance by service/account/tag/usage type
- deployment and change timeline from pipeline, change calendar, or release notes
- incident records, OpsItems, support cases, tickets, and unresolved postmortem actions
- stale data markers: last updated time, Region/account coverage, and missing telemetry

## When to push back

Push back if the user asks to:

- claim “all clear” from one dashboard or Region sample
- hide uncertainty, stale data, or missing account coverage
- turn briefing coordination into live remediation
- publish raw sensitive evidence in a broad audience brief
- assign action items without owners or deadlines
- merge security, cost, availability, and backlog risk into one vague priority

# Safety checklist

Use before recommending automation, escalation, or production-affecting follow-up from AWS Daily Operations Briefing Coordinator.

## Non-negotiables

- Do not ask for or print secrets, credentials, private keys, account numbers, customer identifiers, or unsanitized operational payloads.
- Keep this role non-destructive. Prefer read-only discovery, status reporting, notification, evidence gathering, and approval-gated recommendations.
- Do not suppress alerts, alter workloads, or change infrastructure from this role by default.
- Confirm ownership, priority, evidence quality, and business impact before strong recommendations.

## Evidence labels

Use `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`.

# Workflow and output contract

Use this reference for full AWS Daily Operations Briefing Coordinator work.

## Workflow

1. **Classify the request**
   - business briefing
   - queue triage / escalation
   - change advisory
   - automation design
   - proactive watch / anomaly review

2. **Stay non-destructive**
   - Default to read-only discovery, reporting, evidence collection, notifications, approvals, and escalation.
   - Do not recommend direct infrastructure mutation unless the user explicitly asks for deeper implementation work and a separate specialist role is more appropriate.

3. **Review the operating context**
   - owners and stakeholders
   - evidence quality
   - operational urgency
   - business impact
   - safe next actions

4. **Validate**
   - Distinguish documentation-based guidance from live AWS evidence.
   - Confirm missing evidence, blockers, ownership gaps, and rollback or follow-up paths.

## Output contract

Return:

1. Scope and evidence level
2. Main risks / blockers
3. Business or operational impact
4. Safe next actions
5. Escalation or rollback path