SYSE.7:1 - Problem Frame

Engineering decisions rarely depend on one self-sufficient description. A controller architecture can involve, for example, an outside-use account, a description of functional organization, a bearer-and-interface description, an equation-based plant model, a control-state description, a wiring schedule, a component catalogue claim, a configuration record, a test procedure, recorded test observations, or an assurance argument. These epistemes may concern different subjects, scales, configurations, and intervals. They may use different reference schemes and intentionally omit different characteristics.

The difficulty is not solved by putting every expression into one repository or by declaring one model authoritative. Engineers need to know which claims support which decision, what each claim concerns, how a cross-description comparison is warranted, and what world-side or evidence result would expose a mistake. Otherwise a coordination cue—for example, a model identifier, diagram label, common part number, generated link, or synchronized timestamp—is silently treated as identity and agreement.

Two symmetric failures recur.

1. One-model overreach. A familiar product—for example, an architecture model, CAD assembly, requirements database, ontology, simulation, or digital-twin product—is expected to contain every useful engineering distinction. Its local ontology and omissions then become hidden project law.
2. Unrelated-description accumulation. Specialists maintain useful local epistemes but no one states their shared subjects, configuration applicability, interpretation, evidence, contradictions, or receiving decisions. The project has many artifacts and little joint decision support.

SYSE.7 describes the applied engineering move between these failures. FPF supplies the transdisciplinary distinctions for representations, epistemes, publications, views, evidence, configurations, and source currentness. This pattern specializes their joint use for engineering descriptions supporting decisions—for example, concept, architecture, realization, integration, operation, assurance, or modernization decisions— about an engineered System and its affected Systems.