Guides

TL;DR

This page is a task-based index over the docs — pick the job in front of you and follow the guide that matches it.
The docs are organised by job, not by platform surface. A team integrating a trained model follows a different guide than a team assembling a backend; both rest on the same three foundations.
Foundations are short — components, backends, types. Every guide builds on them.
Reference material (component contract, type catalog, SDK surfaces) is a lookup you reach for after a guide tells you what to check, not before.

Foundations

Read these three once, in any order. Every guide below assumes them.

ComponentsA typed, versioned, containerized capability. BackendsHow component releases compose into a checked graph. TypesThe contracts that make backend connections safe.

Two more are worth a first-pass skim: Solutions (endpoints, applications, what users consume) and Transformations (inlined primitives that reshape streams between vertices).

Pick your guide

Each card is a starting point keyed to what you already have. Open the one that matches; it pulls in the other docs its job needs.

I'm writing Python or C++ codeTurn code into a reusable component, validate it, ship a prerelease, prove it. I'm assembling a backendCompose catalog components into a wired, typed graph and deploy it. I have a trained modelIntegrate the artifact, wire it, prove it, benchmark it for promotion. I'm automating a data pipelineRun CSV, image, audio, JSON, or parquet inputs through a backend, reproducibly. I need proof before shippingProduce reproducible evidence that a candidate does what it claims. I'm operating a deploymentDeploy a checked backend, watch health, debug, redeploy, tear down. I'm binding an applicationTurn a deployed backend into a product surface with a UI. I'm handling secrets or team controlsBind workspace secrets and handle irreversible operations safely.

Each guide names the order to read its supporting docs and the next flow to run, so you can stay on the card you picked.

Driving a guide from an LLM

Pipelogic is built so the ppl CLI is a first-class control surface for LLM-driven workflows. Agent profiles change which commands are visible, switch output to machine-readable shapes, and lock the surface against destructive operations. The docs registry is the agent's map of the platform: discover the available docs as a tree, search when the branch is unclear, fetch the exact flow, then execute the next bounded command.

The hand-off prompt that works well is short:

LLM prompt

Use the ppl CLI in this shell. Start with ppl docs get flows/guides.

I want to build, integrate, test, deploy, debug, or document:

Use ppl docs tree and ppl docs search <query> when the next doc is not obvious. Run only commands available in the current profile. Report created or changed IDs, status, observed output, container logs when relevant, and any human-only decision.

See Quickstart for the full agent-mode setup, The lease lifecycle for the cleanup contract that makes agent experimentation safe, and Agent-mode output for the envelope shapes commands return.

Reference

Reach for these after a guide tells you what to look up.

Component contract — manifest schema.
Type syntax — pipelang grammar.
Type catalog — built-in named types.
File types — accepted file slots.
Python component API — Python SDK surface.
C++ component API — C++ SDK surface.