| The system is evolvable | No claim kind, subject, change family, scale, horizon, or evidence is named. | Classify the claim, identify its subject, and use C.25 only when several typed quality coordinates are required. |
| Work result becomes System quality | One change duration or defect count is assigned to a platform, family, Method, or team. | Keep the Work occurrence, enacted Method, result/resource coordinate, configuration, and conditions visible; make a separate architecture or capability claim only with its own evidence. |
| Mechanism equals characteristic | The presence of modules, APIs, tests, a digital twin, or AI establishes evolvability. | Assess the declared architecture characteristic or Work result and preserve the mechanism as an explanatory input. |
| Builder mistaken for a system-of-interest part | A factory, test rig, platform, or team is drawn below the project system-of-interest as a holonic level. | Recover the builder, service, dependency, assignment, or Work relation separately; also retain genuine part–whole levels inside the project system-of-interest and builder Systems when they matter. |
| Possible future equals current architecture | Roadmap benefits enter the baseline. | Keep current relations, candidate specifications, implementation Work, and later readings separate. |
| More variants equals improvement | Candidate count rises while admissibility, integration, evidence, and selection degrade. | Preserve archive value, Front basis, guardrails, and finite resource constraints. |
| Platform metric chooses product investment | Deployment or test speed improves locally, but consequences for the project system-of-interest and provider burden are absent. | Compare changes to the project system-of-interest and builder arrangement on one shared basis and expose displaced burden. |
| Project choice equals cultural selection | A local change is called a new engineering culture. | Use SYSE.21 and later population evidence for transmission, recognition, selection, retention, and loss. |