Purpose: obtain an official Railway/provider capability statement before any custodian implementation. This is not a request for Railway to provision, mutate, deploy, inspect customer data, access our application targets or troubleshoot application code.

Please answer each item with YES / NO / NOT AVAILABLE / CONDITIONAL, and cite the exact Railway platform behavior or limitation. Where CONDITIONAL, state the exact prerequisite.

1. SERVICE_STORAGE_ISOLATION — Can a dedicated Railway service with an attached volume be isolated such that other project services (including root inside their containers) cannot mount, enter, access, attach or obtain writable access to that volume or the custodian service's mount/PID namespace? Please include relevant privilege, host/device/socket and cross-container boundaries.

2. EXCLUSIVE_VOLUME_ATTACHMENT — Can the volume be attached only to the custodian service, with ordinary API-service credentials/processes unable to attach, remount or enter it? What Railway-level permissions or control-plane identities can attach/detach a volume?

3. AFFIRMATIVE_OLD_OWNER_REVOCATION — Before a volume is reassigned/redeployed, can Railway provide or expose an affirmative platform signal/evidence that all old container/process holders are terminated, outstanding I/O is disposed of, and the old volume attachment is detached before a new owner becomes active? A configured replica count or sent SIGTERM/SIGKILL alone is insufficient for this requirement.

4. STABLE_PROVIDER_VOLUME_IDENTITY — What immutable/stable identifiers exist for a Railway volume/storage incarnation, and how do backup restore, clone, replacement, redeploy and recovery affect those identifiers? Can a workload distinguish the same original volume incarnation from a restored/replaced clone?

5. RUNTIME_STORAGE_OBSERVABILITY — Which of these identities/observations are available to a workload or read-only provider API: deployment ID, replica/container/process identity, boot identity, mount namespace identity, mount ID, filesystem ID/fsid, device identity, volume ID, attachment generation, parent/root device+inode? Please mark unavailable fields explicitly rather than omitting them.

6. PRIVATE_TMP_MAPPING_FEASIBILITY — Can a Railway volume be mounted at a private path used only inside the custodian service (including a dedicated /tmp-style mapping) without sharing the API service's /tmp or host filesystem, while keeping a control journal and governed targets on the same durable filesystem?

7. DURABILITY_SEMANTICS — What guarantees apply to file fsync and directory fsync on Railway volumes? What happens to acknowledged writes across container crash, host failure, redeploy, volume detach/reattach and power-loss-equivalent events? Are these semantics documented/testable, and are there cases where fsync success does not imply persistence through those events?

8. PRIVATE_AUTHENTICATED_PROTOCOL_IDENTITY — Railway private networking provides transport isolation, but can the platform support a separate custodian service identity/credential boundary such that API services can call a bounded private protocol without receiving storage/attach/admin credentials? Please distinguish network membership from application authentication/authorization.

Already documented separately: Railway volume services do not use replicas and multiple active deployments are prevented from being mounted to the same service/volume. We treat that only as NO_OVERLAPPING_VOLUME_OWNERS; it does not by itself satisfy old-owner revocation.

This is a general platform-capability question for a future architecture. No access to our project, services, data, or credentials is required.

We would especially appreciate confirmation from Railway staff or links to official Railway documentation for each answer.

No provider mutation or customer-data inspection is requested.