DAG Handbook¶
bijux-dag v0.4.1 is a local-first DAG runtime for reproducible workflows
with explicit graph contracts, deterministic execution records, verified
artifacts, cache explanation, and replayable run bundles.
The Replay Contract defines the replay authority.
Inside bijux-core, that promise covers graph validation, execution planning,
local run orchestration, replay, artifact identity, evidence inspection, cache
reasoning, and changed-run comparison.
The product boundary covers DAG behavior itself: what is admitted, what is executed, which evidence is retained, and which crate owns each decision.
v0.4.0 Surface Truth Table¶
The supported operator boundary is the visible bijux-dag --help surface for
local DAG work:
validate,plan,run,replayruns,artifact,artifact-inspect,diff,explainverify,doctor,cache,version,commands,completions
That stable lane is intentionally local-first. Repository-owned experimental, simulated, and maintainer-only routes still exist, but they are deliberate opt-in lanes rather than the default product story.
Use Release Boundary for the exact lane classification, Generated CLI Reference for the stable command surface generated from the live binary, and Gated Command Inventory when you deliberately need the experimental, simulated, or internal route inventory.
flowchart LR
source["Workflow source"]
canonical_graph["Validated canonical graph"]
plan["Deterministic execution plan"]
run["Backend execution"]
evidence["Retained run evidence"]
inspect["Verify, explain, diff, or replay"]
source --> canonical_graph --> plan --> run --> evidence --> inspect
evidence -. replay input .-> plan
The retained evidence is part of the product result, not incidental logging. Validation can stop before execution; execution is not accepted as reproducible until its artifacts and identity-bearing records can be verified.
Result Acceptance¶
| Boundary | Accepted when | Refused when |
|---|---|---|
| graph | schema, identifiers, dependencies, and declared contracts validate | the source is ambiguous, cyclic, invalid, or incompatible |
| plan | canonical graph meaning and execution identity are derivable | planning cannot preserve declared dependency or policy meaning |
| node attempt | the adapter result reaches a valid terminal transition | launch, timeout, cancellation, retry, or lifecycle rules fail |
| output | every required declaration, path, hash, and proof is satisfied | output is missing, undeclared, escaped, incomplete, or corrupt |
| cache entry | reusable evidence matches active identities and integrity rules | lookup reports an explainable miss or invalid proof |
| run | terminal counts, manifest, traces, output index, and run identity agree | retained evidence is incomplete or internally inconsistent |
| replay or comparison | the selected evidence is complete and compatible for the requested operation | identity or evidence gaps prevent a defensible result |
This acceptance chain is why a process exit code alone is not a DAG result.
Controller And Substrate¶
flowchart TB
graph_policy["validated graph and policy"]
controller["bijux-dag controller"]
schedule["ready frontier and resource admission"]
backend["local, container, SLURM, or Kubernetes substrate"]
observation["status, streams, outputs, backend identity"]
acceptance["lifecycle, output, and integrity acceptance"]
run["retained run truth"]
graph_policy --> controller --> schedule --> backend --> observation --> acceptance --> run
acceptance -->|"retry or refuse"| schedule
The controller owns graph meaning, scheduling, lifecycle transitions, and accepted run state. A backend owns substrate-specific preparation, launch, observation, finalization, and cleanup. Scheduler or container status remains provisional until the controller validates it against node, output, and evidence contracts.
Start Here¶
| If you want to... | Open this page |
|---|---|
| get a working DAG run as fast as possible | First-Run Tutorial |
| browse real workflows with expected outputs | Executable Examples |
| check whether a command or backend is part of the shipped boundary | Release Boundary |
| understand retained run evidence on disk | Run Evidence Layout |
| understand graph, plan, execution, cache, and replay identity | Reproducibility Model |
| find the owning crate before reading code | DAG Packages |
Product Proof Map¶
The public product sentence is only useful if a reader can trace each claim to one concrete proof surface:
| Product claim | Where this handbook proves it |
|---|---|
| explicit graph contracts | Graph Schema Reference and First-Run Tutorial |
| deterministic execution records | Run Evidence Layout and Operator Workflows |
| verified artifacts | Artifact Contracts and First-Run Tutorial |
| cache explanation | Cache Behavior Workflow and CLI Surface |
| replayable run bundles | Reproducibility Model, Failure Recovery, and Replay Contract |
Packages In This Product¶
The current public DAG crate family is:
bijux-dag-corefor graph truth and planner inputsbijux-dag-artifactsfor run evidence, integrity, and lifecycle helpersbijux-dag-runtimefor execution policy, replay, cache, and diagnosticsbijux-dag-appfor command orchestration and response shapingbijux-dag-clifor the thinbijux-dagexecutable wrapper
bijux-dag-testkit remains repository-internal support for deterministic DAG
fixtures and shared assertions.
For the public-versus-private crate boundary behind that split, use
../bijux-core/foundation/package-boundary.md.
Honest Boundary Notes¶
run --backend slurmis part of the current release line for shared-filesystem environments where scheduled workers can reopen the retained run directory.run --backend kubernetesis part of the current release line for container-node execution through Kubernetes Jobs with shared persistent storage.- Experimental routes remain callable by explicit path and are visible through
bijux-dag commands --lane experimental. - Simulated and maintainer namespaces require explicit opt-in through
BIJUX_DAG_ENABLE_SIMULATED=1orBIJUX_DAG_ENABLE_INTERNAL=1together with deliberate lane inventory. - If the next question sounds like a security claim rather than a workflow claim, route it to Execution Security And Isolation before treating a flag or backend as an enforced boundary.
Operate The Product¶
- CLI Surface for the operator contract
- Graph Schema Reference for authoring truth
- Cache Behavior Workflow for reuse, verification, and refusal behavior
- Container Packaging Workflow for container-backed execution
- Branching Bulletin Workflow for branch decisions, skipped lanes, and join behavior
- Failure Recovery for preserving and verifying an interrupted or failed run
Adjacent Authorities¶
- Repository Handbook — publication rules, shared release policy, and cross-product ownership.
- Maintainer Handbook — governance suites, release proof, and repository gates.
- Future Direction — non-binding capability
direction beyond shipped
v0.4.0behavior.