Deployment · Workflows
Workflows for forward-deployed work.
The deployment reference explains how the engines sit inside a pipeline. These are the procedures a forward-deployed operator runs inside one: demand ranking, content pipelines with prove gates, traffic diagnosis, corpus integrity, deploy verification. Every workflow is a file you can open, and every phase in every file is a Run block you can execute today with the open catalog.
The ladder comes first
Every workflow carries one of three statuses, and the definitions are strict. Template: designed against documented practice and the engine architecture, not yet executed as written. Validated: executed as written, by the engines, on a real property, with a public run record linked; a manual run a workflow merely describes does not count. Hardened: validated, plus failure modes documented from real incidents. Everything below launches as a template, the statuses on this page read live from the repository's manifest, and the flips happen in public. We think a catalog that shows you its verification ladder is worth more than one that asserts maturity, and this page is built to be checked against.
Statuses read live from the repository manifest, as of 2026-07-11.
Forward-deployed engineer
| Workflow | Status |
|---|---|
| Post-Deploy Live Verification | template |
| Data Surface Integrity | defined, publishing |
| Migration with Verification | defined, publishing |
| CI Prove-Gate Wiring | defined, publishing |
| Warehouse Data Plane Standup | defined, publishing |
Forward-deployed marketer
| Workflow | Status |
|---|---|
| Content Pipeline with Prove Gates | template |
| Corpus Integrity and Correction | template |
| Link Graph and Metadata Parity Audit | defined, publishing |
| Regulated-Content Compliance Gate | defined, publishing |
| Experiment Loop with Pre-Registered Gates | defined, publishing |
Forward-deployed analyst
| Workflow | Status |
|---|---|
| Traffic-Drop Triage | template |
| Conversion-by-Source Diagnosis | template |
| Revenue Tracking Integrity | defined, publishing |
Cross-track
| Workflow | Status |
|---|---|
| Incident Response and Lane Demotion | defined, publishing |
| Autonomy Review | defined, publishing |
One rule, stated with its ceiling
Checks report and fail; they never modify. Engines propose and stop; a human merges. Under template status that rule is absolute, and for judgment-tier gates it is permanent. Below that tier, a lane can earn auto-pass and eventually merge authority through its agreement record: measured false-pass rates against published thresholds, licensed by a review ceremony, revocable the first time a promoted lane regresses. The ceiling and the demotion path are in the files, because a ladder without a stated top rail is indistinguishable from a pricing page.
The connector contract
Workflows declare data access as capability classes, never vendors: warehouse queries with mandatory partition-filter bounds, read-only search and analytics access, and exactly one write mode, write-held, where every change lands as a draft a human promotes. The full contract, including what is deliberately absent (no index-submit class, no analytics-config-write class, no connector class for the agreement log), is CONNECTORS.md in the repository.
Named and not launched
Three items are on this page because honesty about them is cheaper than questions: an AI-surface visibility workflow ships when its measurement capability has real runs behind it; attribution and outcome reporting ships when the agreement log has enough real rows to make it runnable by a stranger; a product-manager track is defined and follows these three. Deliberately excluded and staying that way: paid media (this library is organic-lifecycle) and standalone accessibility workflows (accessibility is a quality dimension inside every gate, not a separate ceremony).
Start here
Open the repository, read GETTING-STARTED, pick the workflow whose "when to use" matches your week. If you deploy the engines behind them, the deployment reference is the parent of this page. Links: github.com/rampstackco/claude-skills and /engines/deployment.
FAQ
Can I run these without RampStack's engines?
Yes. Every phase names catalog skills and carries a capability-class line for substitution; declared gaps include their procedure inline. The operated layer (the agreement log instance, promotion decisions) is ours; the procedures are not.
What does "validated" actually require?
Execution as written, by the engines, on a real property, with a public run record linked from the workflow file. The definition excludes retroactive credit: work a workflow describes but did not govern stays a template receipt.
Why do some workflows say "defined, publishing"?
The set was designed as fifteen; five shipped first and the rest publish incrementally. The manifest in the repository is the canonical list, and this page renders from it.