run-pipeline

Run an analytical workflow

Choose the amount of work that serves the request. A chart, investigation, validation report, and presentation have different completion conditions. Do not add presentation work to an analysis-only or validation-only request.

Inspect and propose

Read plans.md, agents/registry.yaml, and the selected worker contracts. The registry declares coordination; contracts declare input requirements. Do not infer required inputs from whatever happens to exist in global outputs.

Prepare a request JSON under working/requests/ with:

• plan: an existing named plan.
• variables: concrete filename placeholder values.
• bindings: each worker's input values or explicit producer references.
• output_paths: exact paths replacing wildcard/dynamic output declarations.
• external_dependencies: input names replacing omitted producers.
• approval_gates: required approvals with id, after, and before.
• context: the exact analytical question, plus optional worker_questions when a worker needs a narrower framing.

For produced inputs use {"from": "worker.result"}. The first registered output is result; later outputs are artifact_2, etc. Inspect the registry before selecting one. For existing files supply an exact path, computed sha256, and a purpose explaining why the file suits this question. Evaluate dataset, scope and age as well: a hash establishes identity, not analytical suitability.

Never invent missing data, credentials, meaning, or approval. Ask only for inputs that cannot be safely supplied from the request and verified context.

When context.question is present, the controller builds a deterministic manifest and bounded bundle for each worker from the frozen run snapshot. It attaches both as explicit inputs and blocks on trusted-definition conflicts. The bundle records supply. Workers must cite relevant context item IDs, and downstream validation still checks whether the work applied them.

Compile before executing