Every module, and how far each one actually goesEvery module, and how far each one actually goes

Each block below is a service with its own failure domain, its own deployment and its own page. They ship as one platform because they are built together and tested together, and they are documented separately because that is how an evaluator reads: nobody assesses a streaming platform as a whole, they assess the two or three pieces they are worried about.

The order here is the order video moves in. Content arrives and is described; it is encoded into a ladder; it is stored; it is delivered; it is played on a screen; it is measured; and every step of that is reachable over an API and declared in code.

Where a block stops, the page for it says so. That is the useful part of this section and the reason the spec sheet exists.

Open the spec sheet and search for the three capabilities your service cannot launch without. If all three say shipping, the conversation is about deployment. If one says not built, the conversation is about scope and a date, and it is better to have that conversation before a demo than after a contract.

Then read the module page for whichever one you are least sure about. Every module page carries the same shape — what it does, how it works, where it stops — and the last of those three is the section most vendor documentation does not have.

The reason this is possible on a public page is that the statuses come from one internal ledger rather than from marketing copy, and the spec sheet is generated from that ledger rather than retyped. A capability cannot appear here without a status, and a status cannot be softened on the way to the page.