Thank you, Quinn. I understand that the exact mechanism associating an app with its container is an implementation detail and may change. To clarify my purpose: I am considering a dedicated macOS .app, with protecting existing application data and settings as the priority. Before allowing the proposed app to run or perform application-managed storage, I need to assess whether OS-managed initial container creation can be treated as a narrowly bounded exception to a restriction on writes. Running the app and allowing application-managed storage remain on hold. The distinction I need to establish is between items created by macOS during initial container creation and subsequent writes by the app or frameworks it uses. Could you clarify the following, or point me to public documentation? What guarantees, if any, are documented about initial container creation: its triggers, mandatory or conditional items, locations, contents, size bounds, and lifetime? Which of these are implementation details? Beyond the exact association mechanism, are any supported guarantees documented about how an app’s identity or signing determines which container it can access? Is there a public, supported way to permit OS-managed initial container creation while preventing subsequent writes by the app and its frameworks within that container? I have not specified the target macOS version, bundle identifier, signing configuration, or entitlements in this thread. Please let me know which details are needed, including whether App Sandbox configuration affects the answer. If public guarantees are insufficient to establish this boundary, clarification of that limitation would also be helpful. Thank you.