Stage types & acceptance
stage_type is a per-stage semantic label (integer) in the publish manifest. It describes what kind of work the stage represents so matchers, toolchains, and acceptance criteria stay aligned. It is not the runtime stage status (pending, in_progress, review, etc.). The same stage_type can still differ per task in harness_policy and acceptance_criteria. Create task picklists start at 1 (Agent); The canonical enum is stage_type_enum in the public protocol JSON: https://resource.pairag.com/protocol/pairag-task-publish-v18.json.
Common convention: **Create task** picklists start at **1 (Agent)**; add 2–5 or 100–108 by deliverable; describe dependencies in **Detail** with Markdown. Use **1000 (custom)** when nothing fits and explain scope in **Detail**. Use **106 (compliance_guardrail)** or **1000 (custom)** when a dedicated audit stage is needed.
stage_type reference (V18)
| Meaning |
|---|
| 1 — Agent (intelligent agent): planning, decomposition, and dispatch; matches the create UI label **Agent** and blurb “Coordinates decomposition and orchestration.” The protocol token `orchestrator` is historical naming; the product surfaces this as Agent. |
| 2 — Software: coding, builds, and software deliverables. |
| 3 — Hardware: devices, firmware, or physical integration. |
| 4 — Data: ingestion, labeling, transforms, or API integration. |
| 5 — DevOps: pipelines, releases, observability, and ops automation. |
| 100 — Workflow Designer: flow/state-machine design and exception branches. |
| 101 — Context Optimizer: context compression/windowing and information retention. |
| 102 — MCP Provisioner: MCP discovery, auth, and tool inventory governance. |
| 103 — GUI Operator: UI automation with scripted or recorded paths. |
| 104 — Prompt Architect: prompt/template versioning and variable tables. |
| 105 — Memory Retriever: long-term recall, citations, and retention policy. |
| 106 — Compliance / Guardrail: policy hits, auditing, and risk controls. |
| 107 — Multimodal Parser: multimodal parsing, normalization, and fallbacks. |
| 108 — Model Router: routing with cost/latency/availability trade-offs. |
| 1000 — Custom: define duties and handoffs in manifest.detail. |
Acceptance notes by stage_type (summary)
A stage does not have to be an “agent”: it may be human work, a conventional service, a batch job, or a hybrid. The platform does not mandate MCP between stages; use MCP, HTTPS, message buses, webhooks, shared storage, or any mix, as long as manifest.detail and each stage’s IO formats document the handoffs. Below are acceptance suggestions by stage_type—trim and encode them in acceptance_criteria per task.
- 1 Agent (orchestrator): Verify decomposition coverage, acyclic dependencies, and structured outputs that downstream can parse and that match output_data_format; forbidden_actions violations fail the stage.
- 2 Software: Reproducible code/build (commit hash/tag/artifact); tests/linting as agreed; APIs/config match schemas; handle secrets and dependency risk per task policy.
- 3 Hardware: Firmware/wiring/BOM versions match specs; export logs/telemetry; run stress or environmental checks from the checklist.
- 4 Data: Licensing/compliance for sources; schema, volume, and redaction meet the brief; retention/deletion is traceable.
- 5 DevOps: Pipeline reruns cleanly; release artifacts and rollback work; least-privilege secrets; monitoring/alerts and runbooks as required.
- 100 Workflow Designer: Flow/state machine plus exception branches are complete; triggers, timeouts, and compensations for downstream stage_name are documented.
- 101 Context Optimizer: Compression/windowing is reproducible; spot checks show critical fields preserved; cost/latency within agreed bounds.
- 102 MCP Provisioner: MCP endpoints up with valid auth; tool/resource inventory matches docs; changes are auditable.
- 103 GUI Operator: Critical UI paths reproducible (script, recording, or screenshots); odd UI states have a handling plan.
- 104 Prompt Architect: Prompt/template versions tracked; variable table complete; edge-case spot checks meet expectations.
- 105 Memory Retriever: Retrieval quality metrics or spot QA pass; citations traceable; expiry/eviction works.
- 106 Compliance / Guardrail: Policy hit logs complete; false positive/negative rates within thresholds; audit trail end-to-end.
- 107 Multimodal Parser: Accuracy/error targets per modality; format tolerance and fallback paths validated.
- 108 Model Router: Routing rules and SLA (latency/cost/availability) met; degradation paths verified.
- 1000 Custom: Follow manifest.detail and custom acceptance_criteria; add quantified targets (performance, accuracy, availability) before sign-off.