Hello Railway team,

We are preparing a controlled precheck deployment with automatic retries disabled. Before executing it, we need clarification of the public API contract:

1. For serviceInstanceDeploy, at what point are startCommand, restartPolicy, healthcheck settings, ordinary service variables and reference variables bound to that deployment? If the request was accepted but its response was lost, can subsequent serviceInstanceUpdate / variable updates change the settings used by that already accepted deployment at build or startup?

2. If serviceInstanceDeploy was accepted but the caller did not receive a deployment id, is there a documented maximum delay before it becomes visible in the service/environment deployments query? If no bound exists, what read-only reconciliation mechanism can establish whether the request was accepted, so we can avoid both a duplicate deployment and prematurely restoring service configuration?

3. Deployment Actions says restarting a crashed deployment restores its original image and configuration. Does the same binding apply to automatic crash restarts and platform-initiated restarts, including runtime/reference variables, even if service settings have changed since the original deployment?

We understand that GraphQL errors/HTTP status do not provide exactly-once guarantees. We are asking about the platform contract, not asking you to trigger or change any deployment. Please point us to a documented guarantee or confirm where the outcome must remain unknown.

Thank you.