A draft is validated against the live fleet before it can go out. Every check must pass — that gate is what §11.3 calls “what prevents a single admin mistake from destroying your business”.
Health, slot saturation, priority and tier. Quarantining an instance takes it out of rotation without deleting it — §18.4 says add capacity once saturation passes 0.70.
§5.4 needs one distinct account per Comet instance. Keys are never shown here — the console lists the Vault path they live behind.
Paths, sizes, who references them, when they were last rotated. No endpoint in this service can return a secret’s value, and there is a test that fails the build if one is ever added.
A plan is what grants playback: capabilities are resolved from it at token mint (§10.1). Vouchers, resellers and payment collection are Phase 4.
§23 decision 4 makes vouchers the primary channel — no processor, no chargebacks, no compliance team that can switch them off. Codes are shown once: only a peppered hash is stored, so a lost response means voiding the batch and minting again.
Every admin action and every config diff. Rows outlive the accounts that made them.
§13 lists thirteen pages. These five describe subsystems that do not exist, so they are not here. An empty table would read as “the feature works and nobody has used it”; the truth is that it is not built.
| Live TV | M3U/Xtream ingest, EPG pipeline, channel curation | Phase 5 |
| OBS Channels | MediaMTX ingest, stream keys, LL-HLS packaging | Phase 5 |
| Resellers | balances, wholesale tiers, minting caps, statements — §14.5 calls it a third front-end | Phase 4 |
| Ads | provider waterfall, placements, caps, revenue | Phase 4 |
| Payments | Stripe / NowPayments / BTCPay. Each needs a merchant account and, for BTCPay, a node. §14.6 calls Stripe "the fragile leg — an optimization, not a dependency"; vouchers are the channel that works today | Phase 4 |
The schema for all five already exists (migrations 0003–0005), so each is a service and a page, not a migration.