# Framework-Smoke Test Pipeline vs Production Pipelines in OpenMontage

> Understand framework smoke test pipelines vs production pipelines in OpenMontage. Learn how minimal validation differs from full eight-stage video generation workflows.

- Repository: [Calesthio/OpenMontage](https://github.com/calesthio/OpenMontage)
- Tags: deep-dive
- Published: 2026-08-30

---

**The `framework-smoke` test pipeline is a minimal two-stage validation harness used by OpenMontage's CI system to verify core framework contracts, while production pipelines execute full eight-stage video generation workflows with external providers, governance rules, and rendering capabilities.**

OpenMontage orchestrates video creation through declarative pipeline manifests that define execution stages, available tools, and governance constraints. Understanding the distinction between the lightweight validation harness and full-featured production workflows is essential for developers extending the framework or troubleshooting deployment issues. The **`framework-smoke` test pipeline** serves as the minimal contract validator, whereas production pipelines like `animated-explainer` deliver publish-ready video content.

## Pipeline Structure and Stage Progression

The fundamental distinction lies in the number of execution stages and their complexity.

### The Framework-Smoke Test Pipeline

Located at [`pipeline_defs/framework-smoke.yaml`](https://github.com/calesthio/OpenMontage/blob/main/pipeline_defs/framework-smoke.yaml), this pipeline contains only two stages: **research** and **script**. Each stage declares empty `tools_available` lists and minimal checkpoint requirements, ensuring the agent can move from a research brief to a script artifact without invoking external providers or asset generation services.

### Production Pipeline Architecture

Production pipelines follow the canonical eight-stage flow defined in [`docs/ARCHITECTURE.md`](https://github.com/calesthio/OpenMontage/blob/main/docs/ARCHITECTURE.md): *research → proposal → script → scene_plan → assets → edit → compose → publish*. These manifests, such as [`pipeline_defs/animated-explainer.yaml`](https://github.com/calesthio/OpenMontage/blob/main/pipeline_defs/animated-explainer.yaml), specify detailed stage-director skills, required tools, human-approval defaults, and success criteria for each phase of video production.

## Execution Scope and Governance

Beyond structure, the pipelines differ radically in operational constraints and resource requirements.

**External Provider Integration**
The `framework-smoke` pipeline runs with no external providers or assets, functioning purely as a schema validation exercise. Production pipelines invoke dozens of providers including video generation, image synthesis, TTS, and music services, while enforcing budget, quality, and *silent-swap* prohibitions.

**Rendering and Runtime Constraints**
Production pipelines lock the `render_runtime` (Remotion vs HyperFrames) and enforce runtime-specific rules during the `compose` stage review. The smoke pipeline does not involve rendering, making these governance rules and runtime constraints irrelevant.

## CI Integration and Contract Validation

The `framework-smoke` pipeline serves as the primary validation mechanism in OpenMontage's continuous integration system.

Referenced in [`PROJECT_CONTEXT.md`](https://github.com/calesthio/OpenMontage/blob/main/PROJECT_CONTEXT.md) as the *test harness*, this pipeline is executed by [`.github/workflows/ci.yml`](https://github.com/calesthio/OpenMontage/blob/main/.github/workflows/ci.yml) to confirm that framework contracts remain stable after code changes. The `make test-contracts` command internally invokes the loader to verify that stage-director skills, checkpoint protocols, and reviewer logic are wired correctly without incurring external API costs.

## Loading and Executing Pipeline Manifests

Both pipeline types are loaded through the same interface in [`lib/pipeline_loader.py`](https://github.com/calesthio/OpenMontage/blob/main/lib/pipeline_loader.py), allowing consistent execution semantics despite differing complexity.

```python

# Loading the smoke pipeline for CI validation

from lib.pipeline_loader import load_pipeline

smoke = load_pipeline("framework-smoke")   # loads pipeline_defs/framework-smoke.yaml

print(smoke.stages)                        # → ['research', 'script']

```

```python

# Loading a production pipeline with full capabilities

explainer = load_pipeline("animated-explainer")
print(explainer.stages)

# → ['research', 'proposal', 'script', 'scene_plan',

#    'assets', 'edit', 'compose', 'publish']

```

```bash

# CI invocation via Makefile

make test-contracts

# Internally executes:

python -c "from lib.pipeline_loader import load_pipeline; p=load_pipeline('framework-smoke'); p.run()"

```

## Summary

- **The `framework-smoke` test pipeline** is a minimal two-stage YAML manifest located in [`pipeline_defs/framework-smoke.yaml`](https://github.com/calesthio/OpenMontage/blob/main/pipeline_defs/framework-smoke.yaml) that validates core framework contracts without external dependencies or rendering.
- **Production pipelines** implement the full eight-stage video generation workflow with external providers, rendering constraints, and governance rules like runtime locking and silent-swap prohibitions.
- **CI integration** relies on the smoke pipeline to verify stability through `make test-contracts` and [`.github/workflows/ci.yml`](https://github.com/calesthio/OpenMontage/blob/main/.github/workflows/ci.yml) without incurring production costs.
- **Both pipeline types** are instantiated via `lib/pipeline_loader.load_pipeline()`, ensuring consistent execution interfaces regardless of stage complexity.

## Frequently Asked Questions

### What file defines the framework-smoke test pipeline?

The `framework-smoke` pipeline is defined in [`pipeline_defs/framework-smoke.yaml`](https://github.com/calesthio/OpenMontage/blob/main/pipeline_defs/framework-smoke.yaml) at the repository root. This manifest declares only the **research** and **script** stages with empty tool lists, making it suitable for rapid validation without external API calls or asset generation.

### How does the CI system use the framework-smoke pipeline?

OpenMontage's GitHub Actions workflow ([`.github/workflows/ci.yml`](https://github.com/calesthio/OpenMontage/blob/main/.github/workflows/ci.yml)) invokes the smoke pipeline through `make test-contracts` to verify that framework contracts remain intact after code changes. This validates the stage-director skills, checkpoint protocols, and reviewer logic without incurring costs from external video generation providers.

### Why does the framework-smoke pipeline have only two stages?

The two-stage structure (research → script) represents the minimal viable path for an agent to progress from input brief to artifact generation. This reduced scope allows the test harness to validate schema compliance and execution wiring without the complexity of asset generation, editing, or rendering stages required by production workflows.

### Can production pipelines skip stages defined in the standard eight-stage flow?

While production pipelines typically follow the canonical eight-stage progression documented in [`docs/ARCHITECTURE.md`](https://github.com/calesthio/OpenMontage/blob/main/docs/ARCHITECTURE.md), individual manifests like [`animated-explainer.yaml`](https://github.com/calesthio/OpenMontage/blob/main/animated-explainer.yaml) can customize stage requirements and tool configurations. However, they maintain the full structural envelope to ensure compatibility with governance checks and rendering runtime constraints that the `framework-smoke` pipeline explicitly excludes.