Forge Platform

Handbook

Governed workflows and rules

Forge Platform is not a generic BPM engine. Conditional behavior is split across human gates, campaign procedures, and LCDL graphs. This page maps where each kind of rule lives and what the platform owns versus…

Three conditional models

Model “If / then” Owner Platform maturity
A — Human / policy ApprovalRequest lifecycle; workcell mode Lenses + approval model Schemas + Self-Host Alpha (local_runner gates on approved action)
B — Campaign procedural Manifest repos, branches, orchestrator states, Fleet poll Forge Campaign, campaign_orchestrator Specified; sample manifests
C — LCDL graph DecisionPack DAG, gate tasks, operators forge-lcdl Implemented in LCDL; platform R3 adds ForgeRun/Lenses visibility 
  [A] Human/policy
        ApprovalRequest approved?  --> runner / Fleet template allowed
        Lenses decision on EvidencePacket

  [B] Campaign / Fleet procedural
        campaign.yaml --> orchestrator --> branch / Fleet / poll / integrate
        (manifest statuses — not DecisionPack)

  [C] LCDL graph (machine)
        plan_decision_pack --> llm_boolean_gate / llm_enum_route
        --> depends_on DAG --> LCDLTraceSummary --> EvidencePacket

A — Approval gates and workcell modes

ApprovalRequest states: requested → approved → executed → decision (see approval model).

Workcell mode on WorkcellRequest constrains what the runner may do before human review:

Mode Behavior
readonly Inspect and report only
proposal Suggest; human approves before apply
operator Coordinate tools within policy
sandboxed_implementation Bounded edit/execute (Fleet workspace, allowlisted local actions)

Self-Host Alpha: only state: approved approvals gate scripts/selfhost_runner.py (see Self-Host local runner).

C — DecisionPack and LCDL graph

DecisionPack is a versioned graph: nodes with depends_on, types such as kernel, rank, invoke_pack, terminal. Conditional routing uses governed tasks including:

  • llm_boolean_gate — binary branch
  • llm_enum_route — single-label route

Execution and parsing live in forge-lcdl (forge_lcdl.graph, plan_decision_pack). Platform does not re-implement the executor.

External references (canonical API):

Example gate → branch (conceptual):

  node "feasible?" (llm_boolean_gate)
        |
        +-- ok:true  --> node "path_a" ...
        +-- ok:false --> node "path_b" ...

LCDL operators vs graph executor

Mechanism Use when
GraphExecutor + DecisionPack Declarative DAG with explicit dependencies and terminal nodes
seq, fallback_chain, until_ok Imperative composition around run_task without a full pack document

Operators do not replace DecisionPack; they complement it for smaller chains. See LCDL operator docs (link above).

Attachment to ForgeRun

Platform owns when artifacts attach:

Artifact Role
LCDLTraceSummary Condensed trace for Lenses and evidence
EvidencePacket Human-reviewable bundle
FleetJobSummary Container outcome summary

Roadmap R3 (product roadmap): map plan_decision_pack, decompose_problem, contradiction_scan into ForgeRun metadata and Lenses trace UI (R3.M1–R3.M6) — visibility, not re-homing LCDL code.

B — Campaign vs graph

Campaign lifecycle states (draft, branched, submitted, running, …) are orchestrator-managed procedural steps tied to campaign.yaml. They are not DecisionPack nodes. A campaign may invoke LCDL tasks inside a workcell, but the campaign manifest does not define the DAG.

For resource and autonomy policy on unattended PDCA-style loops (token budgets, L0–L8 targets), see Respecting resources and autonomy and the Blueprints handbook pages it links.

Blueprint and Versona workflows

Methodology playbooks (roadmap gate, Forge SDLC phases, project setup) live in Blueprints and Cursor Versona rules. They produce process context (BlueprintContextPack), not runtime DecisionPack graphs. Do not treat .mdc workflow rules as the platform workflow engine.

Micro-agent is not a DecisionPack workflow

Forge micro-agent (local_llm_worker) runs one micro-pack and typically one LCDL call per invocation. Multi-node graphs belong in forge-lcdl graph/operator paths, not in the default micro-agent harness.

AutomationFlow (browser ops, separate from DecisionPack)

AutomationFlow (forge.automation.flow/v1, CNCF Serverless Workflow 0.8 subset) is a declarative graph for browser probe/remediation chains. It is not DecisionPack (schema_version: 2 planning DAG).

Spec Executor Typical host
DecisionPack forge_lcdl.graph.GraphExecutor LCDL client, Lenses trace
AutomationFlow forge_lcdl.flow.FlowExecutor forge-cdp-manager POST /v1/flows/run

Platform owns when flow completion attaches to consumer state (opaque CloudEvents + polling); forge-cdp-manager does not import Cockpit SQLite. Spec: forge-cdp-manager docs/AUTOMATION-FLOW-v1.md (sibling product repo).

Harness rules (KS)

AI.* and DET.* rules in the Kitchen Sink UX auditor are quality harness checks. They are not ApprovalRequest, Campaign, or DecisionPack workflows.

Anti-patterns

  • Lenses embedding a hidden rules engine or executing DecisionPack nodes directly.
  • Fleet storing canonical DecisionPack or campaign state instead of summaries for the run spine.
  • forge-workcells owning multi-step DAG orchestration without an explicit workcell design.
  • Confusing Blueprint Versona workflow templates with LCDL graph conditionals.