Strategic Alignment

​

Overview

The core objective of any startup is to onboard paying users. The related core objective is to provide a product people want and use. At Livepeer, the core products are real-time video and AI pipelines. As a decentralised network, Livepeer competes with both decentralised peers and centralised counterparts. It needs to make its value propositions clear for users coming from diverse backgrounds and for potential partners looking to integrate Livepeer as a solution. The documentation engagement was scoped to serve those product and partnership goals: make Livepeer easy to evaluate, easy to integrate, easy to operate, and easy to participate in as an operator or Delegator.

​

Livepeer objectives

​

Livepeer-wide

• Aim 1: Users paying for services.
• Aim 2: More services.
• Aim 3: More platforms.
• Aim 4: More integrations.

​

Livepeer Docs

• Aim 1: AI first.
• Aim 2: Canonical resource.
• Aim 3: Meets product AND developer needs.
• Aim 4: Future-proof, low-lift maintenance.
• Aim 5: Clear stakeholder ownership.

​

Livepeer-wide aims in detail

​

Aim 1: Users paying for services

Livepeer’s revenue model depends on users paying for transcoding and AI compute through Gateways and through ecosystem products (Studio, Daydream, Embody, Streamplace). For paying use to grow, the documentation needs to make the path from “evaluate” to “first integration call” short and frictionless. Developer onboarding under v2/developers/, Studio integration paths under v2/solutions/livepeer-studio/, and the AI quickstart pages collectively reduce time-to-first-call for new builders. The contracts pipeline keeps the on-chain payment surfaces (ticket redemption, Reward Cut, Fee Cut) verifiably accurate.

​

Aim 2: More services

Beyond transcoding, the network now supports AI pipelines and real-time interactive video. The documentation needs to surface new services as they ship without restructuring core navigation each time. The 10-tab IA, the solutions tab, and the changelog pipeline together let new services land as additive pages rather than IA rewrites. The component library and template system make new service pages fast to author and consistent to read.

​

Aim 3: More platforms

Livepeer’s platform reach grows when SDKs, Gateways, and integrations exist for more languages, frameworks, and environments. The documentation supports this by maintaining language-specific SDK changelogs (Go, JS, Python), an OpenAPI surface for every API the project ships, and platform-specific operator guides (Docker, Linux, Windows) across Gateways and Orchestrators.

​

Aim 4: More integrations

Partners integrating Livepeer as a building block need contractual-grade reference material: addresses, ABIs, version pins, release tags, configuration flags, and quickstart paths. The data integrations layer (contract addresses pipeline, release globals, configuration flags, OpenAPI specs) keeps integration reference data accurate without manual editing. The contracts page is canonical; the Frameworks, Streamplace, and AI SPE solutions pages document partner integrations.

​

Livepeer Docs aims in detail

​

Aim 1: AI first

The documentation is built to be consumed by AI agents as well as humans. The hosted MCP server at docs.livepeer.org/mcp, the llms.txt index, the AI-enriched sitemap, the Mintlify chat assistant, and the six native agent adapters (Claude, Cursor, Windsurf, Augment, Codex, Copilot) collectively make Livepeer documentation queryable as authoritative source material instead of inferred from old model training data. Agents and humans inherit the same governance contracts.

​

Aim 2: Canonical resource

Every governed surface has a single canonical source, a deterministic validator, an exact repair command, and a single gate layer. Generated artefacts are never hand-edited. Drift is detected and named. The locked decisions in docs-guide/decisions/docs-guide-structure.md (D-DG-01 through D-DG-13) establish the canonical structure; the source-of-truth policy under docs-guide/policies/source-of-truth-policy.mdx defines the contract.

​

Aim 3: Meets product AND developer needs

The 10-tab IA serves both product readers (solutions, about, community) and developer readers (developers, Gateways, Orchestrators, Delegators, resources). Personas, content scans, and the locked navigation pattern (D-NAV-01) keep both populations in mind. The internal tab keeps Foundation, Inc, and SPE coordination work separated from public surfaces.

​

Aim 4: Future-proof, low-lift maintenance

The repository is built as a self-remediating operating system, not a folder of pages. 11 active workflows, 253 operations scripts, 49 validators, 29 remediators, 30 generators, 21 audits, and a manifest-driven ownerless governance model mean routine drift is repairable by any contributor or agent without staff context. The contributor toolchain (lpd CLI, scoped Mintlify preview, 4 VS Code extensions, 312 governed snippets) makes the correct workflow the easiest workflow.

​

Aim 5: Clear stakeholder ownership

CODEOWNERS, the section-owners table in Governance, the decisions registry, and the agent governance framework collectively define who owns which surface. Eight surfaces are formally ownerless-ready. Twenty more are in the wider registry awaiting promotion. Policy authorship and destructive operations remain human-only; routine drift is contributor-grade.

​

Strategic alignment with Livepeer objectives in docs

The mapping below shows how delivered documentation work serves each Livepeer-wide aim. Detailed evidence per item lives in Outcomes and v2/internal/rfp/reports/livepeer-docs-v2-report.md. For the matching internal alignment (how delivered work serves Docs aims), see Outcomes and Aims.