Design subscriber.yml Schema and Notification Granularity (Phase 2 pre-A)

Phase: 2 (design, blocks Phase 2 A)
Labels: quartz, phase-2, design, discussion

Context

Before implementing notify-downstream.yml and notify_subscribers.py, the schema
of config/subscriber.yml must be designed. The notification granularity is already
defined at the level of build/test × pipeline (rocm / pytorch / jax) x arch. The design
work is about how to express this in a subscriber declaration that is easy to extend
as the system grows.

Reference: RFC-0011 (ROCm/TheRock#3728 / docs/rfcs/RFC0011-Quartz-CICD-Datahub.md in ROCm/TheRock once merged) — Phase 2, Section A.

Design Considerations

Extensibility

The schema must be designed so that adding the following later does not require
restructuring existing subscriber entries:

• New pipelines added to TheRock (beyond rocm / pytorch / jax)
• Downstream projects reporting results back to Quartz (Phase 3) triggering
  notifications to other subscribers
• Additional TheRock workflow types (Phase 4: all workflows, not just nightly/prerelease)

Multi-arch workflow

TheRock's primary workflow is multi-arch: a single nightly or prerelease run covers
multiple architectures in parallel. The schema must model this correctly — a subscriber
declaration referencing a specific architecture must work within the context of a
multi-arch run, and the notification logic must account for whether it fires per-arch
completion or on overall run completion.

Filtering

Subscribers need to be able to declare which subset of events they react to:

• Which workflow type: nightly, prerelease, branch, PR (Phase 4+)
• Which pipeline(s): rocm / pytorch / jax
• Which architecture(s), within a multi-arch run
• Which signal: build, test, or both
• Result filter: any completion, or only on passing

Secrets for hidden subscriptions

Downstream projects that do not want to appear publicly in subscriber.yml must be
supported via GitHub secrets. The schema must have a clear convention for referencing
secrets so that notify_subscribers.py can resolve them at runtime. This also needs
to be documented in docs/push-subscription.md (Phase 2 A documentation issue).

Tasks

• Design subscriber.yml schema with the extensibility considerations above in mind
• Define the convention for secret-based subscriber entries
• Define the payload sent to a downstream workflow on dispatch

Start with the issue's references to config/subscriber.yml, notify_subscribers.py, notify-downstream.yml, and docs/push-subscription.md, then read RFC-0011 Section A. Done means the extensible subscriber schema, secret-entry convention, and downstream dispatch payload are documented well enough to unblock Phase 2 A.