Migration impact map across services

The decision tree

6 typed decisions, each with an action for every answer

At fixed moments in a run, the engine puts one narrow question to a decision model. The decision model never writes text: it answers yes or no with a probability, picks from listed options, or gives a score, about a small slice of the material. The engine then does exactly what this tree says, which is what makes the run auditable. The thresholds are the template's design values, not measured results.

1. 1

   Planner, while planning

   Split or keep serialYes or no, with a probability

   While planning

   Does this service contain enough separately owned modules importing the shared client that scanning them in parallel beats one pass over the service?

   Sees only: The service's module list with owners and import counts for the shared client

   Why: Avoids paying coordination cost on small services that one worker can read whole.

   00.30 and 0.601

   • Yes: 0.60 or higher→thenSplit the work
   • Unsure: 0.30 up to 0.60→thenKeep serial
   • No: below 0.30→thenKeep serial
2. 2

   Scope checkYes or no, with a probability

   Before work starts on a unit

   Does this module import or re-export the library being migrated, directly or through an internal wrapper named on the wrapper list?

   Sees only: The module's import statements and the list of internal wrappers

   Why: Most modules never touch the library; skipping them is where the width becomes affordable.

   00.20 and 0.601

   • Yes: 0.60 or higher→thenAccept
   • Unsure: 0.20 up to 0.60→thenAccept
   • No: below 0.20→thenSkip this unit
3. 3

   After workers, the judge checks

   Evidence checkYes or no, with a probability

   After a worker answers

   Does the cited line call the changed function in the way the breaking-change entry describes, for example passing the removed argument or reading the old return shape?

   Sees only: The cited lines with a little surrounding code, and one breaking-change entry

   Why: A false hit wastes an owner's time; a loose match hides the real work.

   00.50 and 0.851

   • Yes: 0.85 or higher→thenAccept
   • Unsure: 0.50 up to 0.85→thenEscalate to a strong model
   • No: below 0.50→thenReject and retry
4. 4

   Run control, between rounds

   Retry or stopYes or no, with a probability

   After a rejection or low confidence

   The first scan called this module clean but the sampled re-check found a usage: do the two results truly disagree about the same file?

   Sees only: The two scan results for the module and the file paths each one read

   Why: One overturned clean result means the cheap scan is missing a usage style, so the service is re-read properly.

   00.30 and 0.601

   • Yes: 0.60 or higher→thenEscalate to a strong model
   • Unsure: 0.30 up to 0.60→thenEscalate to a strong model
   • No: below 0.30→thenContinue
5. 5

   Another round?Yes or no, with a probability

   Between rounds

   Is every module of this service either resolved with cited lines or listed as a blind spot, so the service can roll up?

   Sees only: The service's module status table

   Why: Stops a half-scanned service from entering the migration order as if it were known.

   00.50 and 0.851

   • Yes: 0.85 or higher→thenStop
   • Unsure: 0.50 up to 0.85→thenContinue
   • No: below 0.50→thenContinue
6. 6

   Accountable person, before anything is settled

   Person decidesYes or no, with a probability

   Before anything is reported as settled

   Does this service's change list include a change to a public interface, a data schema or a module with no listed owner?

   Sees only: The service's rolled-up change list and its ownership map row

   Why: Order, freeze windows and unowned code are the platform lead's calls.

   Accountable: The platform lead owns the order, the freeze windows and the decision to start; each owner confirms their service's list.

   00.15 and 0.401

   • Yes: 0.40 or higher→thenAsk a person
   • Unsure: 0.15 up to 0.40→thenAsk a person
   • No: below 0.15→thenAccept