Registry Coordinator overview

Registry Coordinator runs a reviewed sequence of calls to other Registry Stack products, and keeps it going across waits of days or weeks, service outages, and restarts. Use it when a sequence such as “ask a reviewer, wait for the decision, then send the applicant a notice” has to continue without a person or a script holding it open.

What you write, and what runs

You write a workflow: a finite graph of steps in YAML, checked offline and packaged into an immutable artifact that an operator pins by digest. Each start of that workflow is a run, which Coordinator keeps in its own PostgreSQL 17 or newer database. A run keeps the definition it was admitted under, so a later upgrade never changes a run in flight.

A workflow is built from five step types: call one product operation, choose the next step, wait-until an instant, wait-for a named result such as a Casework review decision, and finish with a declared outcome.

What stays with each product

Every product a run calls keeps its own authority. Coordinator calls each one over its public HTTP API with a service identity the operator configured, and that product decides, under its current policy, whether to allow the call. Being allowed to start a workflow grants nothing downstream. Coordinator never writes another product’s database, never applies a Base Registry Engine (BReg) Proposal for the applicant, and never reverses an effect a product accepted.

When Coordinator cannot tell whether a call took effect, it holds the run for an operator rather than sending the call again.

When to look elsewhere

Coordinator has no SQL steps, no loops, no number of calls decided at run time, no arbitrary HTTP methods, no automatic compensation, and no distributed rollback. It is an optional service and pre-1.0: use the binaries and documentation of one source version together.

Next

Review an application and send an approval notice runs one workflow through a human review to a delivered notice, on your machine.