RFP Report

Report on the Livepeer Documentation Restructure RFP

Aims - Documentation Philosophy & RFP Aim Delivery

Documentation Philosophy

This section articulates the philosophical framework that underpinned the v2 engagement and demonstrates, with full implementation evidence, how every element of the RFP’s three stated aims - stakeholder-focused, AI-first, and future-proofed - was delivered across every layer of the system.

Documentation Philosophy

1. Documentation is not static. It is infrastructure & must be built, maintained, and governed as such.
2. AI is the new search, and discoverable products are AI-first
3. Agents are the new docs consumers and users and information should be structured accordingly

Documentation As Infrastructure

Documentation As Infrastructure

The foundational premise of this engagement, articulated before a single page was written, is that documentation is not editorial output.

It is infrastructure.

This principle reframes how investment in documentation should be understood, measured, and maintained.

Infrastructure has properties that editorial content does not: it must be maintained under load, it degrades without active governance, it requires testing, automation, and versioning.

The D.O.C.S. System™ developed as the strategic operating model for this engagement formalises this:

• Distribution Infrastructure,
• Operational Governance,
• Composable Execution, and
• Signal & System Feedback.

The practical implication is that “documentation work” in this engagement meant building a documentation operating system - a complete apparatus for authoring, validating, publishing, automating, and governing content - not just writing pages.

The 58-script test suite, 17 GitHub Actions workflows, lpd CLI, component library, and docs-guide governance system are all infrastructure.

They are the scaffolding that makes every page reliable, maintainable, and improvable by anyone.

Episode Details

Inferact is a new AI infrastructure company founded by the creators and core maintainers of vLLM.

Its mission is to build a universal, open-source inference layer that makes large AI models faster, cheaper, and more reliable to run across any hardware, model architecture, or deployment environment.

Together, they broke down how modern AI models are actually run in production, why “inference” has quietly become one of the hardest problems in AI infrastructure, and how the open-source project vLLM emerged to solve it.

The conversation also looked at why the vLLM team started Inferact and their vision for a universal inference layer that can run any model, on any chip, efficiently.

Episode Details

In this episode of AI + a16z, dbt Labs founder and CEO Tristan Handy sits down with a16z’s Jennifer Li and Matt Bornstein to explore the next chapter of data engineering — from the rise (and plateau) of the modern data stack to the growing role of AI in analytics and data engineering.

Among other topics, they discuss how automation and tooling like SQL compilers are reshaping how engineers work with data; dbt’s new Fusion Engine and what it means for developer workflows; and what to make of recent data-industry acquisitions and ambitious product launches.

Episode Details

Talks about Documentation as Infrastructure and how good documentation ensures AI surfaces the product, regardless of product capability.

Documentation Frameworks & References

D.O.C.S (Documentation)

The D.O.C.S principles focus on creating high-quality, effective, and user-focused technical content by ensuring it is clear, concise, comprehensive, and consistent.

Key principles include writing from the user’s perspective, using plain language, keeping documentation up-to-date, making it skimmable with structured formatting, and providing concrete, actionable examples.

Core Documentation Principles

• Clear & Concise: Use simple language to explain complex ideas, avoiding jargon. Get to the point quickly and remove unnecessary information.
• Comprehensive & Consistent: Cover all necessary information (endpoints, variations, edge cases) and maintain consistent formatting and terminology throughout.
• Structured & Skimmable: Use headings, subheadings, lists, and tables to make content easy to navigate. Place the most important information first.
• User-Focused: Write from the reader’s perspective, focusing on their tasks and goals instead of just technical features.
• Accurate & Updated: Regularly review and update documentation to reflect the current state of the product.
• Concrete & Interactive: Include real-world examples, code snippets, and tutorials to help users immediately apply the information.

Docs as Code (Modern Approach)

Modern documentation often follows a “Docs as Code” approach, treating documentation with the same rigor as software code.

• Integrated: Documentation is part of the development lifecycle, not an afterthought.
• Version Control: Stored alongside code in repositories (e.g., Git).
• Automation: Automated testing and building of documentation.
• Collaboration: Allows for pull requests and reviews, enabling both writers and developers to contribute.

Best Practices

• Define Terms: Define acronyms and technical terms.
• Inclusive Language: Use language that is welcoming to a diverse audience.
• Identify Audience Needs: Map documentation to specific user tasks (e.g., tutorials, how-to guides, API reference).
• Record Rationale: Explain why something was done, beyond what was done.

Diátaxis Framework

The Diátaxis framework is a systematic approach that organizes documentation into four distinct quadrants based on two axes: Action vs. Reflection and Learning vs. Working.

The Four Quadrants of Diátaxis

• Tutorials (Learning-Oriented): Hands-on lessons that guide a beginner through a series of steps to achieve a result. Their primary goal is to provide a successful learning experience, beyond solve a problem.
• How-To Guides (Task-Oriented): Practical directions that help an experienced user complete a specific, real-world task. They focus on the “how” and assume the user already has basic competence.
• Reference (Information-Oriented): Technical descriptions of the machinery-API keys, classes, commands, and schemas. They must be neutral, accurate, and easy to consult quickly.
• Explanation (Understanding-Oriented): Discussions that clarify and illuminate a particular topic. They provide context, background, and rationale (“the why”) instead of instructions.

The core principle is to keep these four types separate. Mixing them — such as putting long technical explanations inside a step-by-step tutorial — confuses the reader and makes the documentation harder to maintain.

References:

Your docs are your infrastructure

OpenClaw And The Future Of Personal AI Agents

Docs as Code

D.O.C.S (Documentation Principles)

AI Is the New Search

AI Is the New Search

For over a decade, SEO - optimising for Google - was the primary lever for documentation discoverability.

That paradigm is being rapidly displaced.

LLMs now index, summarise, and recommend infrastructure products at scale. Developers increasingly begin their research with ChatGPT, Claude, Perplexity, or Gemini instead of a search engine.

This means documentation is now being read, evaluated, and cited by machines before it reaches humans.

The implication is structural, not cosmetic.

Semantic headings, stable canonical URLs, machine-readable frontmatter, OpenAPI spec integration, AEO, AI-integrated pipelines and llms.txt files are not “nice to have” - they are the new minimum viable distribution layer.

Answer Engine Optimization (AEO) is the evolution of SEO for this era. This engagement built Livepeer’s AEO layer from first principles.

Agents Are the New Users

Agents Are the New Users

The next wave beyond AI-assisted search is AI agent consumption: automated systems that query documentation to generate code, answer support tickets, configure infrastructure, or build integrations without human intervention.

These agents require documentation that is not merely readable but executable - with explicit preconditions, invariants, verification steps, and failure modes.

It requires specifically serving content designed for agent consumption and context windows.

The “Get AI to Set Up the Gateway” page is a direct instantiation of this principle: a page written for AI agent consumption, not human browsing.

The llms.txt file, repository AGENTS.md, and the native adapter files under .github/, .claude/, .cursor/, and .windsurf/ extend this philosophy into the development workflow itself - making the entire repository legible to AI coding assistants.

See the 21 items for AI-First Docs implemented in the AI-First Report

Docs-As-Infrastructure Repo Features

This update separates the repo product from the public content rewrite. The documentation repo now contains a docs-as-infrastructure system: governance docs, validators, generators, repair paths, component and style systems, data integrations, AI-facing artifacts, and maintainer tooling. Current evidence is tracked in workspace/plan/active/REPO-FEATURES-DOCS-AUDIT/.

Feature area	Current status	Evidence	Remaining gap or community-help area
AI features and pipelines	Completed with gaps	Agent adapters, AI tools registry, skills, llms.txt, AI sitemap workflow, and AI feature docs exist.	Static counts drift from live inventory; generated skill indexes should become the count source.
UI and component system	Completed with gaps	Component registry, usage map, component catalog, templates, global style governance, and JSX component library exist.	Archived components and count drift need classification before the UI system can be called fully consolidated.
Automations	Completed with gaps	GitHub Actions, script taxonomy, generated catalogs, validators, remediators, and dispatch workflows exist.	Workflow and script counts drift; some legacy workflow/archive paths remain and need governed cleanup.
Data integrations	Completed with gaps	OpenAPI/reference paths, contracts pipeline, release/changelog workflows, exchanges data, and social/community feed integrations exist.	Each feed still needs a confirmed source, owner, validator, repair path, and retention policy.
Adaptive architecture	Partially complete	Ownerless governance surfaces, generated artifact manifest, validators, remediators, hooks, and repair concepts exist.	Governance map drift, v2 lane cleanup, report retention, and script metadata compliance remain open.
Contributor tools	Completed with gaps	lpd, local hooks, scoped preview tooling, editor tooling, contribution docs, and validation commands exist.	PATH discovery for non-interactive shells and stale tooling references need tightening.
Content operating system	Partially complete	Content-writing framework, page/frontmatter taxonomy, style standards, research workflows, and review packet workflows exist.	Workspace review packets and active/complete plans need consolidation into canonical docs-guide evidence.
Governance and ownerless repo	Partially complete	Governance index, source-of-truth policy, quality gates, framework/policy set, decisions, and root governance files exist.	Locked docs-guide IA decisions are not fully implemented; duplicate authority files and stale top-level folders remain.
Community contribution pathways	Completed with gaps	Contribution guide, issue templates, Discord/GitHub intake concepts, review workflows, and docs tooling exist.	Gap queue should be made public-facing only after verification and owner assignment.

Honest delivery status: the repo has moved beyond a documentation rewrite into a maintainable infrastructure product, but not every feature is fully consolidated or self-remediating yet. The current handoff priority is to verify every feature, collapse docs-guide into the locked IA, update generated inventories, and publish a reviewed help-needed queue for unresolved ownerless-governance gaps.