The dirty frontier, owned by the library and backed by the reactive_dag_dirty table (created by ReactiveDag.Migration). The host is an Ash/AshPostgres app, so we go through its repo with raw SQL — values always parameterized; the table name (the one identifier SQL cannot parameterize) comes from config and is validated against an identifier grammar at read time, so a typo fails loudly instead of as a syntax error deep in a query. Claim-as-delete is a raw DELETE … RETURNING that Ash actions don't express cleanly.

The host supplies its repo (its AshPostgres repo module) via config, and may override the table name (default reactive_dag_dirty) so a host adopting the library keeps its existing table without a rename:

config :reactive_dag, repo: MyApp.Repo, dirty_table: "my_dirty"

Coalesced by (cell, key); depth-ordered next_cell; claim atomic per cell (DELETE … RETURNING — a key is consumed exactly once). The next_cell-then-claim PAIR is not serialized: concurrent drains can pick the same cell — see the concurrency note on ReactiveDag.Drain. This is the shared substrate both hosts previously hand-rolled (cascade's Cascade.Engine.Frontier, the portal's model_dirty access) — now provided.