ADR 0001 — Atlas project isolation for staging vs prod

Status

Accepted — 2026-04-17.

Context

Issue #56 called for narrowly-scoped MongoDB users. The parallel AWS-migration session (Issue #47) needed a staging MongoDB environment it could point at without disrupting the live Vercel-backed production deployment. The obvious path — a second cluster inside the existing AskFlorence Atlas project — would have shared every project-level setting with prod.

MongoDB Atlas scopes the following at the project level, not cluster:

• IP allowlist / access list entries
• Custom database roles
• Database users (cross-cluster by default)
• Project teams and roles
• Alerts and integrations
• Backup policies (at the project template level)

SOC 2 CC6.6 ("the entity restricts physical and logical access to systems"), CMS EDE Phase 3 isolation requirements, and common auditor expectations all treat shared IAM surface between production and non-production as a finding. A mistyped allowlist rule on staging would widen prod's allowlist. A custom-role JSON typo would affect both. An over-privileged staging user could be pointed at prod by accident.

Decision

Staging lives in its own Atlas project (askflorence-staging, ID 69e31af12fd2c0aef51bbb41) in the same org as prod. All clusters, users, custom roles, allowlist entries, and integrations for staging live inside that project. No command that targets staging ever passes the production project ID (69dc20c64005b222804dafa4).

Consequences

Positive:

• Allowlist mistakes on staging cannot leak to prod.
• Role changes on staging cannot leak to prod.
• A destructive mistake on staging ("delete the project") drops staging and only staging in one command.
• Auditors see a clean IAM tenant boundary for free.

Accepted costs:

• Users, roles, and allowlist entries have to be created twice (once on staging, once later on prod) rather than inherited. Captured in docs/runbooks/atlas-user-provisioning.md to keep the two in sync.
• Billing, support plan, and org policies still share a single Atlas org. That's fine — the isolation that matters for compliance is at the project boundary.

Alternatives considered

• Second cluster in existing prod project — rejected for the isolation reasons above.
• Separate Atlas org per environment — overkill; would fragment billing and make cross-env reads impossible for legitimate ops needs (e.g. comparing a plan record across envs during cutover).

References

• Issue #56 — MongoDB permissioned users setup
• Issue #47 — AWS migration
• AWS-migration session's review of the plan (2026-04-17)
• SOC 2 TSC 2017 — CC6.1, CC6.6
• CMS EDE Audit Program Appendix A § 3 (Environment Separation)