> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bijection.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Orchestrate pipelines with Dagster

> Generate typed bindings, materialize complete accepted results, and check orchestration mappings before deployment.

Dagster schedules computations and tracks assets. Bijection fixes each admitted
input cut, hands execution to your compute resource, and verifies the complete
output group. `bijection-dagster` connects these through the shared
`bijection.orchestration` Python SDK.

Install the application Python SDK and `packages/dagster` from your Bijection
source distribution into your code-location environment. The adapter supports
Dagster `>=1.13.26,<1.14`.

```mermaid theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}}
flowchart LR
  Definition[Pipeline declaration] --> Analysis[Native analysis]
  Analysis --> Python[Generated Python contracts]
  Python --> Dagster[Dagster bindings]
  Dagster --> Admission[Immutable evaluation]
  Admission --> Compute[Customer compute]
  Compute --> Accepted[Accepted output group]
  Accepted --> Assets[Dagster materializations]
```

Your pipeline needs typed dataset ports, an immutable program pin and an installed
execution handoff. Generate its Python client and adapter bindings:

```bash theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}}
bijection codegen
bijection orchestration codegen --python-package acme_bijection \
  --out orchestration/generated --adapter dagster
```

For an unpartitioned pipeline exported as `revenue:refresh` with one `revenue`
output and an `orders` input:

```python theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}}
import dagster as dg
import bijection_dagster as bd
from acme_bijection import datasets
from acme_bijection.dagster import revenue_refresh as revenue

orders = bd.dataset_asset(datasets.orders, key=dg.AssetKey("orders"))
refresh = revenue.bind(
    binding_id="finance.revenue",
    parameters=revenue.Parameters(),
    inputs=revenue.Inputs(orders=bd.selected_at_admission(orders)),
    outputs=revenue.Outputs(revenue=dg.AssetKey("customer_revenue")),
    completion="accepted",
)

defs = dg.Definitions(
    assets=[orders, bd.pipeline_assets(refresh)],
    resources={
        "bijection": bd.BijectionResource(
            credential_file=dg.EnvVar("BIJECTION_SERVICE_CREDENTIAL"),
            installation="finance-production",
        ),
        "bijection_io": bd.ResultRefIOManager(
            handles_uri=dg.EnvVar("BIJECTION_RESULT_HANDLES_URI"),
        ),
    },
)
```

Put the generated package on the Python import path. Reference storage must be
durable and shared by your workers. Local directories and S3 are supported;
install `bijection[orchestration-s3]` for S3. Other storage drivers are refused.
It stores exact result handles, while Bijection's existing storage owners retain
the data. Handles and materialization metadata contain no credentials.

An accepted materialization identifies one member of a complete verified result.
All outputs of a pipeline materialize together as one non-subsettable multi-asset.
`completion="selected"` and `"served"` observe subsequent selection and serving;
these waits do not make a selection decision. Native verification appears in
asset metadata. Framework-reported checks retain their own meaning.
Serving waits require a native proof of the exact output group; merely opening
a retained lease does not establish serving.

Use `bd.upstream_result(upstream_asset)` for exact accepted upstream versions.
Recovery occurs before resolving newer materializations. Step retries retain the
original evaluation, parameters, program and input cut. New materialization runs
get a new occurrence. The `bijection/invocation` run tag explicitly preserves an
occurrence across recovery runs. Changed parameters under the same occurrence
are refused. Observation timeouts detach without cancelling computation.

Daily partition bindings require a matching pipeline `partitioning` declaration
with UTC half-open bounds mapped to two int64 parameters. They use
`bd.partition.window_start_ms()` and `window_end_ms()`. Each evaluation covers one
partition. Partition results stay separate from application selection; complete
dataset assembly and explicit selection are separate computations or decisions.
The partition label does not establish source completeness or historical input
retention. Other partition mappings and continuous jobs are unsupported.

Validate and export the code location, then check it against the analyzed app:

```bash theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}}
bijection orchestration export --adapter dagster --entrypoint orchestration.definitions:defs \
  --python .venv/bin/python --out build/orchestration-bindings.json
bijection orchestration check --bindings build/orchestration-bindings.json --offline
```

Select that manifest in `bijection.json` so ordinary deploy preparation checks and
captures its exact bytes:

```json theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}}
{"orchestration":{"bindings":"build/orchestration-bindings.json","release":"build/orchestration-release.json"}}
```

An installed preflight uses the scheduler's own credential:

```bash theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}}
bijection orchestration check --bindings build/orchestration-bindings.json \
  --target https://your-deployment.example \
  --credential /run/secrets/bijection-service.json --python .venv/bin/python
```

`--target` must match the credential's deployment URL. Checks report `ok`,
`refused`, or `unverified`; preflight executes no job. Parameter-dependent
authority and actual computation remain enforced when work is admitted and run.
Deploy the application, preflight the matching code-location artifact, then
activate its schedules. Admission checks the expected contract again.

Capture a coordinated release after building the Dagster image:

```bash theme={"theme":{"light":"github-light-default","dark":"github-dark-default"}}
bijection orchestration release --bindings build/orchestration-bindings.json \
  --generated-package orchestration/generated/acme_bijection \
  --runtime-image "$DAGSTER_IMAGE_DIGEST" --python .venv/bin/python \
  --out build/orchestration-release.json
bijection orchestration check --bindings build/orchestration-bindings.json \
  --release build/orchestration-release.json \
  --generated-package orchestration/generated/acme_bijection \
  --runtime-image "$DAGSTER_IMAGE_DIGEST" --python .venv/bin/python --offline
```

The image variable names an immutable `sha256:…` digest. The release separately
records logical contracts, installed definitions, program pins, binding digests,
generated package file hashes and SDK/adapter versions. Native preparation
captures and checks it. Missing release evidence stays unverified.

Configure `BijectionResource(release_file=..., generated_package=...,
runtime_image_digest=...)` to check the actual loaded binding, package bytes
and versions before admission. Image identity is a deployment claim; these checks
do not attest execution. Private program configuration and credentials remain
outside generated contracts.

Native admission bounds each pipeline to sixteen open evaluations. Use a binding's
`concurrency_pool` with a configured Dagster instance limit to bound scheduling;
customer compute owns execution limits. Daily definitions require midnight UTC
windows and `YYYY-MM-DD` keys without exclusions. `bd.run_config` generates typed
Dagster fields and validates their native values before dispatch.

Optional `BijectionResource.lineage_namespace` reports accepted result identities
through the existing authenticated OpenLineage `/api/lineage` owner. Install its
reporting source and grant the scheduler namespace. The custom correlation facet
is opaque reported evidence, carrying no native acceptance or selection authority.
Set `lineage_required=True` to make reporting failure fail projection; retries
still observe the existing evaluation.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.