The router's resolved configuration: the host's repo, where this package's tables live in it, the bindings events are routed by, the module each delivery is handed to, and what that module needs to reach statifier_persistence.

new/1 takes a keyword list and returns {:ok, config} or {:error, reason}:

StatifierRouter documents what a delivery module must answer, and StatifierRouter.Delivery what the four options it requires must be. A configuration that names another delivery module may leave those four out; one it gives is checked all the same. :persistence_options is never required: a configuration that omits it carries no snapshot, which is what statifier_persistence reads as "the built-in set only".

The route registry, and the two routes on this struct

:route_adapters is ADR-0005 decision 2's registry: the named outbound destinations a chart reaches with <send target="...">, each mapped to the module that serves it. It is deliberately not spelled :routes. :routes already means something else here - it is one of :persistence_options, where it is Statifier.Send.Routes, the engine's point-in-time claim about which <send> routes are live - and ADR-0005 decision 6 closed that ambiguity by vocabulary rather than by renaming the engine's. route/3 resolves a name in a scope.

:send_type is the one type string StatifierRouter.SendHandler is registered under. Giving it is what puts send_types: into :persistence_options, as the Statifier.Send.Types snapshot built from that type string and that handler (ADR-0005, decision 6); the registry cannot supply it, because a registry maps a route name to an adapter and holds no type string. A configuration that gives both :send_type and a :send_types of its own is refused with {:declared_send_types, send_type} rather than one silently winning.

:on_complete names one route in that same registry, and a name absent from :route_adapters is refused with {:unregistered_on_complete, name} rather than missed on the one delivery that would have used it. It is what StatifierRouter.Delivery hands an execution's donedata to on the delivery that finishes the execution; the README's "A finished execution reaches a sink" says what that delivery does and what it cannot do.

What the checks here do and do not catch

:store must be built over this configuration's own :repo, so that StatifierPersistence.Executions.create/4 and StatifierPersistence.Executions.step/5 write through the delivery's transaction rather than opening their own (ADR-0003, section 1). A store over another repo writes outside that transaction, and the delivery's rollback then leaves the execution behind. new/1 catches the case it can see: a store whose resolved adapter options carry a :repo that is not this configuration's is refused with {:error, {:invalid_value, :store, store}}. Those options are statifier_persistence's own, and only its Ecto storage resolves a :repo into them, so a store built on any other adapter passes this check without being checked. On such a store the rule is the host's to keep, and keeping it is not optional.

:resolver and :executor are checked to different depths, on purpose. StatifierRouter.Resolver is this package's own behaviour, so a resolver module is held to it: loadable and exporting resolve/2 (StatifierRouter.Resolver.valid?/1). StatifierPersistence.Executor is the dependency's, normalized per effect by StatifierPersistence.Executor.run/3, so an executor is checked for the shape that option takes - a module name or an arity-2 fun - and the dependency's own dispatch rule is left to it. A host that wants the deeper check on its executor gets it from statifier_persistence, not from here.

Each binding is built with StatifierRouter.Binding.new/1, in the order given, and the resolved configuration keeps that order: it is the order StatifierRouter.route/3 returns its outcomes in. A duplicate binding id is a fault of the list rather than of any one binding, so it is refused here, naming the duplicated id, before any event is routed (ADR-0001, section 1).

The four tables are the address table of ADR-0002 (addresses), the dedupe table of ADR-0003 (dedupe), the ledger of ADR-0004 (routing_ledger) and the subscription table of ADR-0007 (subscriptions); table/2 names each one under a configuration. StatifierRouter.Migrations creates them from the same two storage options, and put_meta/2 and queryable/2 point the schemas in StatifierRouter.Schema at them, so the DDL and the rows cannot disagree on a name.

iex> {:ok, config} =
...>   StatifierRouter.Config.new(
...>     repo: MyApp.Repo,
...>     delivery: MyApp.Delivery,
...>     prefix: "routing"
...>   )
iex> StatifierRouter.Config.table(config, :addresses)
"statifier_router_addresses"
iex> config.prefix
"routing"