Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.livepeer.org/llms.txt

Use this file to discover all available pages before exploring further.

Workflow and Pipeline Governance Framework

Canonical reference for the Livepeer Docs workflow and pipeline architecture. 8 decisions locked (D-ACT-01 through D-ACT-08). Full specification: .github/workspace/framework-canonical.md Decisions log: .github/workspace/decisions-log.mdx

Purpose

This repo is ownerless and self-governed. It must self-repair and self-document through automated pipelines. This framework defines how those pipelines are built, what they must do, and how they are governed. What the product needs to do:
  1. Protect itself - detect breaks, auto-fix what it can, raise issues for what it cannot, block bad changes
  2. Keep itself current - pull fresh external data, regenerate derived files, detect drift
  3. Maintain its own standards - enforce voice, grammar, spelling, terminology, visual identity
  4. Make itself findable - keep AI/search surfaces regenerated on every change
  5. Document itself - catalogues, indexes, registries auto-regenerate
  6. Govern itself - rules enforced, issues managed, drift self-healed

Pipeline Architecture (D-ACT-08)

The dispatcher model

All workflow YAML files are dispatchers. They handle when, where, permissions, and orchestration. The typed work lives in scripts. The type classification comes from what the script does, not the workflow.
LayerRoleHas type?
Workflow YAMLDispatcher: trigger, permissions, environment, orchestrationNo (all dispatchers)
ScriptDoes the work: integrates, generates, validates, audits, remediatesYes (7-type taxonomy)

Pipeline patterns

PatternShapeExample
A: IntegrateFetch external data, diff check, commitContract address updates
B: GenerateBuild from internal data, commitdocs-index.json, llms.txt
C: CheckValidate on PR, report pass/failBroken links, content quality
D: Scan, Report, ActScheduled monitoring with response routingContent freshness, asset health
E: RepairFix broken state, commit or PRComponent metadata repair
F: ReactIssue/PR lifecycle events, no file changesLabel, assign, index, close
G: OrchestrateDispatch children, aggregate resultsMulti-script pipelines

Generate/verify pairs

Every generator (Pattern B) must have a matching verifier (Pattern C) that runs on PR with --check flag.

Taxonomy

Types (7 values, D-ACT-01, D-ACT-07)

TypePurpose
integratorPulls external data into the repo
generatorProduces files from internal repo data
validatorEnforces rules with pass/fail gate on PR
auditRead-only scheduled monitoring and reporting
remediatorAuto-fixes broken state with optional commit
dispatchOrchestrates multiple scripts/workflows
interfaceReacts to issue/PR/external events

Concerns (7 values, D-ACT-05)

ConcernWhat it covers
copyWritten text, data standards, spelling, grammar
healthSite integrity, links, rendering, freshness, assets
maintenanceIndexes, catalogues, documentation, registries, changelogs
discoverabilitySEO, AEO, AI indexing, translation
governanceSystem rules, compliance, issue/PR management
brandStyle, formatting, page structure, voice
integrationsExternal data feeds, APIs, structured data pipelines

Pipeline tags (8 values, D-ACT-02)

TagTriggerAuthority
P2PR (required check)Blocks merge
P3PR (non-required)Advisory
P4Push to deploy branchPost-merge auto-commit
P5Schedule (read-only)Advisory, report only
P5-autoSchedule + auto-commitWrites to repo
P6Schedule + auto-fixSelf-heal, may create PR
manualworkflow_dispatch onlyHuman-triggered
event-drivenrepository_dispatch / issuesExternal event

Workflow file naming (D-ACT-04)

Pattern: type-concern-verb-name.yml Example: integrator-maintenance-update-contract-addresses.yml Segments:
  • type: one of the 7 type values
  • concern: one of the 7 concern values
  • function (11 verbs, closed enum): update, generate, check, scan, repair, dispatch, label, index, intake, close, assign
  • name: descriptive kebab-case slug
Naming quality rule: The name must describe what the workflow does, not how it is implemented. If someone unfamiliar with the repo cannot guess the purpose from the filename alone, the name is bad.

Canonical sources

  • Full specification: .github/workspace/framework-canonical.md
  • Decisions: .github/workspace/decisions-log.mdx
  • Per-action docs: .github/workspace/actions-library/
Last modified on April 8, 2026