The source package mentions projects only once — as a fork in how jobs should be treated — so this domain is a scoping decision and a discovery specification rather than a mapping exercise.
It is in the job mapping, and it reads: validate whether the source job lifecycle and labor capture align to discrete production orders or require project manufacturing treatment.
The job maps to a production order as a direct mapping with medium confidence. The confidence is medium precisely because of the validation note attached to it.
The fork is decided by commercial characteristics rather than by manufacturing ones, and the test should be run that way.
If the test finds project-shaped work, the next question is where it is currently tracked — and in an estate where the evidence base cannot confirm a project module is in use, the answer is frequently "not in the ERP".
If project scope exists, D365 offers two routes and the choice is a programme-shaping decision.
Because the sources are silent, the discovery has to carry the domain. It is short and specific.
Where project scope is confirmed, the design connects to the rest of the path at four points, and each one is a dependency rather than a nice-to-have.
The evidence base raises projects once, as a fork in how jobs should be treated, and says nothing else. This module resolves that fork rather than filling the silence with generic content.