Common Workflows¶
Every operator workflow must connect a declared graph to retained evidence and a bounded decision. Choose the workflow by the proof required, not merely by the command that initiates it.
Normal Operator Loop¶
flowchart LR
define["prepare graph and inputs"] --> validate["validate"]
validate --> run["run"]
run --> inspect["inspect evidence"]
inspect --> reproduce["replay or compare"]
reproduce --> decide["promote or investigate"]
The minimum responsible sequence is:
- validate the graph and resolve required inputs
- execute into a deliberate artifact root
- inspect run state and required artifacts
- replay when reproducibility matters, or compare when attribution matters
- promote only after the required evidence verifies
The First-Run Tutorial executes this loop against a checked-in graph. The Operator Workflows documents individual inspection, replay, comparison, scheduling, and backfill operations.
Choose A Workflow¶
| Question | Workflow | Proof produced |
|---|---|---|
| which checked-in example demonstrates a capability? | Executable Examples | tested commands and declared expected outputs |
| can a local file workflow run, cache, replay, and promote? | File Processing Workflow | rendered report, warm reuse, focused replay, promotion evidence |
| which nodes changed after an input changed? | Data Pipeline Workflow | structured comparison and affected-stage attribution |
| why was cached work reused or refused? | Cache Behavior Workflow | hit evidence, selective invalidation, corruption refusal, miss reason |
| which conditional lane ran? | Branching Bulletin Workflow | selected branch, retained skip, join trigger, replay stability |
| can a failed tail be repaired without hiding the root failure? | Compliance-Gated Bulletin Workflow | retry attempts, approval failure, propagated fallout, repaired verification |
| can a node execute in a real container boundary? | Container Packaging Workflow | mounted inputs, retained outputs, image and engine identity |
| how are scheduled submissions linked to runs? | Scheduled Catalog Refresh Workflow | cron preview, slot suppression, queue dispatch, ledger-to-run identity |
| how are failed historical partitions retried? | Historical Catalog Backfill Workflow | partition fanout, retry selection, aggregate state |
The schedule and backfill guides describe proof-backed internal surfaces in v0.4.x, not stable scheduler APIs. Read Known Limitations before depending on them.
Stop A Live Run¶
Request a cooperative stop when an active run should stop dispatching more nodes:
Use --json when automation needs the recorded request path and current stop
state. A stop request is evidence of intent, not proof that already-dispatched
work was terminated; inspect the retained run state before deciding what to do
next.
Promotion Criteria¶
Promote an output only when:
- the run reached the expected final state
- required artifacts exist and pass the applicable verification
- replay or comparison evidence exists when reproducibility or attribution is part of the claim
- drift and exceptions are absent or explicitly approved
Code Anchors¶
crates/bijux-dag-app/src/routes/run_routes.rscrates/bijux-dag-app/src/routes/inspect_routes.rscrates/bijux-dag-app/src/routes/replay_routes.rs