Streamwake + AWS MediaTailor.
Documented SSAI signal and correlation scope alongside AWS MediaTailor; MediaTailor remains the system performing SSAI.
The documented scope is MediaTailor SSAI signals correlated against CDN signals and AWS-side control-plane signals. MediaTailor remains the system performing server-side ad insertion; this page does not claim a customer connection, live telemetry result, verified setup, or production operation.
AWS MediaTailor server-side ad insertion — ad-beacon drops / session-init failures / late scte-35 responses. The AWS MediaTailor-owned surfaces are source-inspected; the Streamwake workflow on this page is conceptual and not a demonstrated live integration.
Verification evidence
- Public capability claim
The published AWS MediaTailor detail page states the capability Streamwake offers alongside AWS MediaTailor.
- Basis
- The page copy is explicitly presented as a capability claim, separate from implementation and test evidence.
- Scope
- Public capability claim on this integration detail page.
- Reference
- /integrations/mediatailor
- Source-inspected implementation
The AWS MediaTailor detail page is backed by a checked-out static integration configuration and page implementation.
- Basis
- The checked-out page and its shared IntegrationPage configuration were inspected for this surface.
- Scope
- Static source implementation represented by the public detail page.
- Reference
- src/app/(custom)/integrations/mediatailor/page.tsx
What AWS MediaTailor owns. What Streamwake runs on top.
The AWS MediaTailor surfaces below are based on source-inspected research. The proposed Streamwake layer is conceptual; live compatibility, operation, and remediation remain unverified.
Claim status labels: see definitions.
Server-side ad insertion (SSAI) at the CDN edge
SSAI telemetry surface (per-configuration, per-session)
Proposed correlation on the ad-decision-system side
SSA cross-vendor anomaly alignment
A proposed operating loop
for AWS MediaTailor signals.
Four conceptual steps from a AWS MediaTailor signal to an operator-reviewed next action. This is not a controlled test or production demonstration.
- 1
Propose an operator-managed relay path
A future customer-approved evaluation could assess an EventBridge / Lambda relay for the documented MediaTailor signal vocabulary. No relay, customer connection, or end-to-end event path is verified here.
- 2
Keep the documented SSAI kinds distinct
The reviewed scope names adBeaconDrop, sessionInit, and scte35LateResponse as distinct SSAI signals. Local contracts and fixtures do not establish customer delivery or a live investigation timeline.
- 3
Discuss correlation against documented adjacent signals
The reviewed scope supports discussing MediaTailor SSAI observations alongside CDN and AWS-side control-plane signals. Bitmovin and Conviva compatibility are not established, and no live correlator result or persisted customer candidate is claimed.
- 4
Keep unverified vendors out of the claim
A future evaluation could compare MediaTailor SSAI signals with separately verified viewer-side or AWS-side evidence. The reviewed report does not establish Bitmovin, Conviva, or a live multi-vendor pairing, so no combined classification or remediation is promised.
No verified AWS MediaTailor setup is
published yet.
A verified AWS MediaTailor connection path, live telemetry ingestion, and setup instructions are not available on this page. The conceptual workflow above must not be read as operational guidance.
Conceptual AWS MediaTailor scenarios
for investigation, not verified operation.
These scenarios use source-inspected AWS MediaTailor-owned surfaces to illustrate what a future workflow could evaluate. They are proposed examples, not results from a live account.
Claim status labels: see definitions.
Ssai_ad_beacon_drop (ad-tracking Outage)
Conceptual scenario: a documented adBeaconDrop signal could be reviewed as an SSAI-side hypothesis within a future evaluation. No live event, Streamwake classification, or remediation is claimed.
Ssai_session_init_failure (configuration Entitlement Outage)
Conceptual scenario: a documented sessionInit failure could be reviewed as an SSAI configuration hypothesis. No customer event, compatibility result, or entitlement remediation is claimed.
Ssai_scte35_late_response (ad-decision-system Stall)
Conceptual scenario: a documented scte35LateResponse signal could be reviewed alongside separately supplied delivery context. No live event, root-cause classification, or ad-decision remediation is claimed.
SCTE-35 Ad-marker Loss Storm (live-to-VOD Handoff Pairing)
Conceptual scenario: a future evaluation could compare a late SCTE-35 response with separately supplied AWS-side context while keeping the two scopes distinct. No live pairing, Bitmovin evidence, Conviva evidence, or remediation is claimed.
Discuss the documented AWS MediaTailor scope.
Next to AWS MediaTailor.
Discuss the documented AWS MediaTailor SSAI and correlation scope with engineering. Any customer connection, relay, telemetry delivery, and production evaluation would need separate attributable evidence.
Claim status labels: see definitions.
MediaTailor SSAI signals kept within the documented correlation boundary.
MediaTailor SSAI signal may include adBeaconDrop, sessionInit, or scte35LateResponse in a future evaluation. No customer account, event count, or live result is asserted.
The reviewed scope supports keeping the SSAI signal distinct from delivery and AWS-side control-plane evidence. It does not establish a verified relay, end-to-end event path, automatic remediation, or production operation.
This example is a framing aid for an evidence-bounded evaluation, not a postmortem or a report of a completed MediaTailor incident.
Exercise the local source shape,
without implying a live vendor connection.
The in-page setup island mounts the local MediaTailorSourceCard and a companion inbound webhook card. It can exercise a proposed source shape and synthetic fixture; it does not establish a customer connection. Any per-tenant routerToken, an operator-managed SSAI relay, or a POST path would be an evaluation seam, not verified setup guidance. A test event only exercises local code; it does not prove that a MediaTailor event lands on a live investigation timeline.
Wire your operator-managed AWS MediaTailor relay so a vendor-side HTTP transport POSTs one record per adBeaconDrop / sessionInit / scte35LateResponse event to the Streamwake endpoint. The webhook shares the per-source routerToken, so the inbound route resolves your tenant from ?token=<routerToken> first and drops the SSAI event onto the same investigation timeline the merged panel reads.
(empty)(not configured)(empty)(unset)(no events yet)routerToken from that row.curl -X POST '?token=<routerToken>' \
-H 'content-type: application/json' \
-d '{"as":"__test_fixture__","sourceToken":"<routerToken>","envelope":{"kind":"scte35LateResponse","upstreamId":"smoke-1","eventTime":"2026-10-25T08:22:21.046Z","sessionId":"smoke-session-1","adAvailId":"smoke-avail-1","expectedPtsMs":3600000,"actualPtsMs":3614200,"latencyMs":14200,"region":"us-east-1"}}'Recent SSAI events
Loading…
What a bounded evaluation would need on the AWS side before any relay is assessed.
The reviewed MediaTailor scope names the AWS configuration and SSAI signal vocabulary. The cards below describe a possible evaluation boundary; they do not document a customer connection or verified relay.
MediaTailor configuration + AWS region
A future evaluation could identify the MediaTailor configuration and AWS region under review. The source-card fields are local evaluation inputs, not evidence that a customer configuration has been connected.
Any relay or token used for an approved evaluation would remain operator-managed. No credential, customer account, or production relay is represented by this public page.
Proposed relay boundary
A customer-approved evaluation could use an operator-managed relay and the typed adBeaconDrop, sessionInit, and scte35LateResponse vocabulary. This describes a proposed transport boundary, not a verified end-to-end path.
The authenticated setup surface may be used to exercise local parsing and routing behavior with synthetic fixtures. Fixture success is not MediaTailor telemetry or production evidence.
These are the documented SSAI signal names used to define the proposed evaluation scope. Their presence in a typed contract does not establish customer delivery or a live correlation result.
| Kind | Covers |
|---|---|
| adBeaconDrop | A tracking/beacon event drop within the expected delivery window. Probe: `dropCount >= 2` (the contract-layer default threshold; tunable on the source card) within `expectedWindowMs`. Surfaces as `ssai_ad_beacon_drop` (score +30). A single dropped beacon is normal; ≥2 across the session indicates a session-level ad-tracking outage that the next ad break will inherit. |
| sessionInit | A MediaTailor `session.create()` outcome carrying `status: 'success' | 'failure'`. Probe: `status === 'failure'`. Surfaces as `ssai_session_init_failure` (score +40) — the highest weight in the heuristic set, because a session.init failure isolates the entire viewing session, not a single ad break. The correlator pairs it against the AWS MediaLive channel-state stream so the player-side retry is the typed remediation, not a CDN retune that wouldn't have helped. |
| scte35LateResponse | A SCTE-35 marker arrived late downstream. Probe: `actualPtsMs > expectedPtsMs` OR `latencyMs > 8000` (the contract-layer default; tunable on the source card). Surfaces as `ssai_scte35_late_response` (score +35). Either signal alone is enough to qualify — late PTS above the pre-calculated reference AND raw latency above the threshold both indicate a downstream ad-decision system stall. |
Five steps from documented scope
to a bounded evaluation proposal.
This is an evaluation outline, not verified setup guidance. Any customer-specific connection path, telemetry delivery, and result would require separate evidence.
- 1
Define the documented MediaTailor scope
The reviewed scope names MediaTailor SSAI signals alongside CDN and AWS-side control-plane observations. A customer account, configuration, or successful connection is not established by this page.
- 2
Keep any evaluation thresholds explicit
The repository contains typed SSAI event and threshold shapes for a bounded evaluation. Those shapes are not evidence of a live MediaTailor connection, a customer outcome, or production behavior.
- 3
Propose a relay path for evaluation
A future customer-approved evaluation could use an operator-managed EventBridge / Lambda relay for the documented `adBeaconDrop`, `sessionInit`, and `scte35LateResponse` signal vocabulary. No relay or end-to-end event path is verified here.
- 4
Keep setup separate from verification
The authenticated setup surface can hold a proposed source configuration and a scoped token for evaluation. Saving a row does not establish vendor compatibility, telemetry delivery, or production readiness.
- 5
Use fixtures only as implementation checks
A synthetic test fixture can exercise local parsing and routing code, but it is not a MediaTailor account event, live telemetry, verified compatibility result, or production evidence.
No customer credentials or verified relay are represented here. A source row or synthetic token used during an evaluation would remain separate from evidence of a live MediaTailor connection.
What could be evaluated
if attributable SSAI evidence is supplied.
These cards describe proposed analysis outcomes within the documented SSAI/correlation scope. They are not claims that a MediaTailor event, customer incident, or cross-vendor result has been received.
Ranked SSAI hypothesis + confidence
A future evaluation could compare a supplied MediaTailor signal with CDN and AWS-side context and keep the three documented SSAI kinds distinct. No live ranking or confidence result is claimed.
InvestigationCorrelationsPanel MediaTailor SSAI row
A future customer-evidence view could place a MediaTailor observation beside separately verified CDN or AWS-side evidence. No captured customer candidate, Bitmovin row, Conviva row, or live timeline is established here.
Cross-vendor alignment ±30s of CloudWatch evidence
A bounded evaluation could compare event timestamps against supplied AWS-side evidence while preserving the SSAI boundary. No cross-vendor timing result is published.
Same-frame AWS-tier vs SSAI-layer pairing
A remediation event or write-back would require a separately verified customer workflow. This page does not claim that a MediaTailor dashboard, CloudFront, CloudWatch, Bitmovin, or Conviva surface receives a Streamwake result.
Discuss the documented MediaTailor scope with an evidence-bounded evaluation in mind.
Share the MediaTailor SSAI surface and evidence scope you want to assess. The contact form is a real next action, but it does not imply that compatibility, a relay, or production operation has already been verified.