Variable: SETUP_STEP_IDS

const SETUP_STEP_IDS: readonly ["identity-provider", "organizations", "accounts", "key-store", "identifiers", "anchor", "configuration"]

Defined in: packages/contracts/src/setup.ts:79

The engine's steps, in the order they are applied. A step is added by the slice that builds it, after the steps it depends on and before configuration (accounts came with the wizard's step W1b, identifiers with slice 3's step 3.14, key-store with the wizard's step W6b). A step already in the list moves only by a dated ruling that says why, and has moved twice:

• key-store sits before identifiers although it came after it (W6b), because every key made from identifiers on is generated in the security module: a module that is not the one procured, found by key-store, costs minutes, and found by a step that needs a key it stops that step.
• anchor sits after identifiers (slice 3, the ruling on the engine's order after T2c, 2026-10-14). A version 2 framework is identified by the anchor's own did:webvh, whose SCID cannot be known before the identifier's log exists, so the framework must be published after the identifier is. The identifier needs nothing of the admission: it is the anchor organisation's, which organizations created.

These are the engine's steps, not the screens': the console maps its numbered screens onto them. configuration is the last, and applying it is what records the stored answers as the deployment's applied configuration. Reordering this list changes no code a console holds (each is a name, not a position), which is why a move is a ruling and not a new version.