The Adopt flow

ADOPT GUARANTEE:
  Zero cloud-side mutation during adoption
  Existing scaling continues as before
  ZopNight observes; doesn't act
  Customer can audit before / after; state unchanged

ADOPT WORKFLOW:

1. Customer picks Adopt in the Create wizard
2. ZopNight calls cloud API to fetch current scaling configuration
3. Full raw config (scalable_target, policies, scheduled_actions)
   is captured as the policy's previousConfig
4. ZopNight creates a tracking record with:
   source = adopted
   target = the cloud-side target
   min, max, target, cooldown = current values
   mode = monitor (default for adopted)
5. NO cloud API mutations. Cloud-side state unchanged.
6. Customer sees the policy in the Autoscaler page

ADOPTED POLICY: stripe-payments-asg-1
─────────────────────────────────────────────────────────
Source:        adopted
Cloud target:  stripe-payments-asg-1 (ASG)
Last seen:     2026-05-20T08:00:00Z
Mode:          monitor (default for adopted)

CURRENT CLOUD-SIDE CONFIG:
  Scalable target: min 4, max 12, desired 6

  Scaling policies:
    "scale-out-cpu": Target tracking, CPU 60%
    "scale-out-step-1": Step scaling, alarm thresholds
    "scheduled-action-1": Scheduled action, weekday 8 AM

  PREVIOUS CONFIG (rawSpec):
    {... full provider-specific JSON ...}

AUTOSCALER PAGE: stripe-payments-asg-1
─────────────────────────────────────────────────────────
  Provider:           aws
  Target:             ASG: stripe-payments-asg-1
  Status:             Active (managed by cloud)
  Source:             adopted     ← key indicator
  Mode:               monitor

  ZopNight knows this policy exists but does not modify it.

RECOMMENDATIONS for stripe-payments-asg-1 (adopted)
─────────────────────────────────────────────────────────
RC-ASC-004 Scaling target too high (>90%)
  Current target: 90%
  Suggested target: 70%

  Why: scaling triggers at saturation; latency suffers

[Apply]  (would auto-promote to recommended)
[Dismiss]
[Snooze]

SCENARIO                                  USE ADOPT?
─────────────────────────────────────────────────────────
Existing config from Terraform/CFN          YES (preserve IaC)

Existing config from console                YES (preserve manual setup)

Config from other FinOps tool (Spot/etc)   YES (don't disrupt them)

Config seems well-tuned                     YES (don't second-guess)

New workload; no existing config            NO (skip adopt; create direct)

Recently-changed config; team uncertain     YES (observe before acting)

Config seems broken or outdated             Maybe (consider Replace instead)

REMOVE on adopted policy = effectively no-op:

  1. Customer clicks Remove on an adopted policy
  2. ZopNight has nothing to undo (no cloud mutations performed)
  3. Tracking record deleted from ZopNight
  4. Cloud-side state remains exactly as it was

EFFECTIVELY: "stop tracking this"
  Cloud-side scaling continues as before
  ZopNight no longer shows the policy
  Reversible: re-adopt anytime

Editing adopted policy:

  T+0      Adopted: target 60%
  T+5s     User clicks Edit; changes target to 65%
  T+5s     ZopNight prompts: "Source will change adopted → recommended"
  T+5s     User confirms
  T+5s     Source promoted; policy now recommended
  T+5s     UI prompts: "Re-apply to push new value to cloud?"
  T+15s    User clicks Re-apply
  T+30s    Cloud-side updated to target 65%

ONE-WAY TRANSITION:
  Once recommended, stays recommended
  Don't accidentally edit adopted policies you want to keep as adopted

COST IMPACT for adopted policy (analytical view):

  Estimated cost from current config:    $1,200/mo
  Estimated cost if target were 65%:     $920/mo
  Potential savings:                       $280/mo

  Scaling pattern analysis:
    47 scaling actions in past month (high; due to aggressive target)
    Average instances: 5.8 (vs theoretical optimal 4.2)
    Latency impact: minimal (target is high; not at saturation often)

  Recommendation: tune target to 65% for cost savings + lower churn

T+0      Team has 47 ASGs across prod and non-prod
         Each with existing cloud-side scaling from CloudFormation

T+5 min  Team's onboarding playbook: adopt all existing configurations
         For each ASG:
           Create policy → wizard detects existing config → Adopt

         ZopNight tracks 47 policies, all source=adopted
         Zero cloud-side mutations

T+1 MONTH:
  Team reviews recommendations:
    12 ASGs have target too high (>90%)
    8 have cooldown too short
    5 have step scaling that's poorly tuned
    The rest: configured well

T+2 MONTHS:
  Team works through recommendations
  For each, editing an adopted policy auto-promotes to recommended
  Tests the change in staging first; then production

T+3 MONTHS:
  32 ASGs now ZopNight-recommended (managed)
  15 still adopted (no recommendations; well-tuned originally)

RESULTS:
  Cost savings: ~$8K/mo across the optimized 32 policies
  Latency: improved (less scaling churn)
  Trust built: zero incidents from auto-management
  Team comfortable with ZopNight ownership

□ STEP 1: Adopt one policy
  Trigger Create on a target with existing scaling
  Pick Adopt
  Confirm

□ STEP 2: Verify zero cloud-side change
  Compare cloud-side config before and after
  Should be identical (byte-accurate)

□ STEP 3: Check the policy detail
  Source: __________  (should be "adopted")
  Mode: __________
  Previous config visible: □ Yes □ No

□ STEP 4: Review recommendations (if any)
  Recommendations for this policy: _____
  Action available: __________

□ STEP 5: Plan future transition
  Will you re-evaluate in 30 days? □ Yes
  Edit policy to take ownership? __________ (when)