Constructs the Transaction System Layout (TSL), the blueprint defining how all components in the recovered system connect and communicate.

The TSL solves the coordination problem in distributed systems: without it, individual components exist in isolation unable to find each other. This phase validates component availability, builds the complete topology, and prepares services for the system transaction.

Validation Process

Validates core transaction components:

• Sequencer: Must have valid process ID (exactly one runs cluster-wide)
• Commit Proxies: Must have valid process IDs for all proxies (list cannot be empty)
• Resolvers: Must have valid {start_key, process_id} pairs defining key range responsibilities
• Logs: Must have corresponding service entries with {:up, process_id} status

TSL Construction

Builds the complete TSL data structure containing component process IDs, service mappings, metadata materializer reference, and shard layout.

Service Mapping Algorithm

The services field maps service IDs to descriptors through:

1. Extract all service IDs from logs
2. For each service ID, check existence in context.available_services
3. Build service descriptors containing:
   • kind: Service type (log, etc.)
   • last_seen: Timestamp from service discovery
   • status: Either {:up, process_id} or :down

Selective Service Unlocking

Commit proxies are unlocked via CommitProxy.recover_from/5 with lock token and TSL. Other components (sequencer, resolvers, logs) transition automatically when system transaction completes.

Error Handling

• Validation failures: {:stalled, {:recovery_system_failed, {:invalid_recovery_state, reason}}}
• Construction failures: {:stalled, {:recovery_system_failed, reason}}
• Unlock failures: {:stalled, {:recovery_system_failed, {:unlock_failed, reason}}}

Transitions to PersistencePhase to commit layout through system transaction.