Atlas / Trust & control
Trust starts with a clear account of what a system can read, what it may do and how the people responsible can check the result.
Define the sources Atlas may use and the people permitted to see them. Customer data and confidential records should not become public just because a system can connect them.
Access and isolation must be checked in the actual deployment. Keep missing or unverified controls visible until that work is complete.
Reading, preparation and execution need separate consideration. Define supported actions, limits, approval requirements and escalation before a connection is enabled.
Money, legal position, payments, sanctions, title, insurance and claims remain with a named person under the Atlas authority policy. Publishing a policy is not proof that every control has been implemented.
Read the authority guide ↗Agree on what is retained, who can access it, how it can be exported and when it can be deleted. These are deployment decisions with real operational consequences.
Do not put passwords, private keys, authenticator secrets or recovery codes into a support request. Use the access and recovery mechanisms provided for your actual instance.
Read the recovery guide ↗A source reference helps you inspect an answer. An execution record helps you understand an action. A verification check establishes whether the intended result actually happened.
Deployment changes should name the previous version, the checks performed and the recovery procedure. Ask to see evidence for the controls that matter to your use case.
Read the deployment guide ↗Start with your world