SYSE.5 - Develop an Engineered System’s Functional Organization and Bearer Alternatives

SYSE.5:0 - Use This When

Use this pattern when engineers can name a desired outside effect, use situation, or observed functioning failure, but have already treated one familiar bearer cue—for example, a component, product, service, software partition, or supplier offering—as the only candidate. Use it also when a functional diagram exists but no one can show which actual Systems or intended System referents could bear the contributions named by its claims under decision-relevant conditions—for example, operating, interface, placement, integration, or assurance conditions.

The first result is an account that compares several functional organizations with the Systems and interfaces that could realize them. It records proposed many-to-many allocations, the conditions under which each proposal could work, conflicts among proposals, evidence limits, and the first unsupported dependency. The account is a claim-bearing episteme used by later architecture-decision Work. Realization and integration require performed Work; observed functioning and evidence require their own grounding.

First move. In one sentence, name the required outside effect, the current decision question, and the first familiar bearer assumption. Add one materially different way in which the contribution might instead be borne. If no bearer or allocation choice is current, stop and use A.6.F for the function-like claim.

Use this pattern while an allocation choice can change an engineering decision. For one function-like claim, use A.6.F; for one module or interface claim, use A.6.M; for transdisciplinary candidate synthesis across several structures, use C.32; and for choosing an architecture from developed alternatives, use SYSE.6. When a subject-specific Method—for example, one for physics, software semantics, clinical action, electrical protection, or structural integrity—determines the answer, use the relevant application DPF with this allocation account.

SYSE.5:0.1 - Terms and Distinctions

Name in this pattern	What it denotes
required outside effect	A claim about a change or preserved condition needed in a named receiving System under stated use and operating conditions. The claim is an episteme; the change, when it occurs, is world-side.
functional contribution claim	A function-like claim recovered through `A.6.F`: it names a predicate, a possible bearer, conditions, and the larger effect or functioning to which the contribution matters. A label such as sense, control, store, or protect is only a source cue until those positions are recoverable.
functional organization	A selected structure of required effects, functional contribution claims, and relations among them for a named System and use. In FPF it is a selected `U.Structure` described by an `ArchitectureStructuralView` in an `ArchitectureOf@Context` claim. Other representations—for example, a parts list, Work breakdown, or sequence diagram—describe their own subjects and require stated correspondence to this structure. Evidence of actual functioning requires its own grounding.
candidate bearer	An actual System considered for the contribution, or an intended System referent in candidate content. A bearer entry identifies that System or referent and the proposed contribution. Source cues—for example, a component kind, product label, module name, system-role kind, capability claim, or location—must be resolved to those subjects and relations.
constructive organization	A selected structure of actual Systems and relations among them—for example, parthood, connection, or placement—together with decision-relevant boundaries, modules, and physical interfaces; or candidate content describing such a possible-future structure. The structure, the Systems in it, and its descriptions are different objects.
interface specification	An episteme stating conditions for interaction across a boundary, such as exchanged quantity, units, geometry, protocol states, timing, capacity, error handling, or effectivity. The specification names its intended participants; actual connectors, conduits, physical boundaries, interaction occurrences, and compatibility evidence are identified separately by their own kinds and relations.
proposed function-to-bearer allocation	Candidate content that associates one or more functional contribution claims with one or more candidate bearers for stated use, conditions, configuration, and horizon. Establish any actual assignment, performed Work, demonstrated capability, or obtaining functioning through its own relation and evidence.
bearer-and-interface proposal	One linked candidate functional organization, constructive organization, proposed allocations, interface specifications or gaps, operating conditions, and predicted consequences.
materially different alternative	A proposal whose physical principle, distribution, placement, containment, redundancy, control boundary, interface grammar, realization dependency, or other selected structure can change the answer to a named decision question. Renaming the same arrangement or changing only drawing notation does not create another alternative.
allocation conflict	An explicit incompatibility between claims that cannot be satisfied together under the same conditions, or a protected loss created by one proposal. The account names the affected claims, Systems, characteristics, and conditions.

Words such as functional block, module, service, component, agent, sensor, platform, and open interface do not establish a common kind. Restore their subjects and relations before using them in an allocation proposal.

SYSE.5:1 - Problem Frame

An engineered System participates in a use situation through interactions under stated conditions. A desired outside effect can often be produced by several functional organizations, and one functional contribution can often be borne by several Systems together. Conversely, one System can bear several contributions in one configuration and different contributions in another. Distribution can change, for example, across operating modes, failure states, product variants, sites, and time.

The engineer therefore needs more than functional decomposition and more than a component search. The working result links functional and constructive candidates to their outside use, proposed allocations, interface realizations, placement, integration dependencies, and evidence. The result table below states its required content. These selected structures answer different questions and need explicit correspondence where the decision depends on them.

SYSE.5:2 - Problem

Starting from the incumbent construction makes familiar parts look necessary. Starting from a functional graph alone makes abstract elements look like purchasable or assignable things. A supplier search can then be mistaken for proof that the proposed functioning is feasible, while an unsuccessful search can be mistaken for proof that no bearer is possible.

The result is an allocation that survives on paper but fails in use. For example, a bearer may lack power, capacity, placement, access, timing, environmental tolerance, or realization support. Two nominally conforming interfaces may fail to interoperate. Several Systems must cooperate but their joint contribution and failure handling are absent. A standard connector admits a damaging wrong connection. A general-purpose supporting System can reduce one development burden while increasing, for example, latency, energy use, certification Work, or continuing-change burden. Procurement and Work are then organized around functional labels before actual supply items, assembly relations, and evidence needs are known.

The opposite failure is endless decomposition and candidate generation. The engineering account is useful only when it exposes alternatives and conflicts for a named decision question and stops at the first unsupported feasibility dependency.

SYSE.5:3 - Forces

The move must manage these recurring tensions:

Reusing an incumbent construction saves effort, while it can hide a better physical principle or distribution.
Functional abstraction protects solution freedom, while abstract labels can conceal, for example, physics, operating conditions, or joint bearer requirements.
A general-purpose bearer can absorb several contributions, while specialization can improve, for example, performance, safety, energy use, evidence production, or fault containment.
Standard interfaces can reduce coordination cost, while compatibility, integration, substitutability, and correct-use claims still need their own grounds.
More alternatives preserve option value, while every alternative adds Work—for example, modeling, specialist analysis, comparison, or evidence production.
Early quantitative estimates help eliminate infeasible candidates, while premature precision can hide unknown models, wrong subjects, or unsupported measurements.
AI-assisted generation can widen a functional candidate set quickly, while bearer-feasibility and project-correctness claims still need project evidence.
Engineering Work must proceed under incomplete knowledge, while later commitments—for example, purchase, realization, integration, or release commitments—need progressively stronger grounds.
Selected structures—for example, functional, constructive, placement, control, information, configuration, and evidence structures—constrain one another while each answers its own engineering question.

SYSE.5:4 - Solution

Develop several functional organizations and materially different bearer-and-interface proposals together. Enter at the claim that blocks the current decision, keep the outside effect and use visible, and iterate between functional and constructive accounts. Make every allocation, interface condition, conflict, evidence limit, and decision-relevant consequence explicit. Use C.32 for the general multi-structure candidate palette; apply the Systems Engineering content below to make that palette usable for realization, integration, procurement, assurance, and continuing change.

SYSE.5:4.1 - Perform the Move

Bind the engineering decision. Name the actual System or intended-system designator selected as the project system-of-interest, decision question, use situation, required outside effect or observed failure, configuration or variant, operating envelope, horizon, and protected characteristics. Use SYSE.2 candidates and unresolved use–System mismatches when they are current and compatible; otherwise use a qualified direct source or record the missing result.
Restore the blocking function-like claims. For each material contribution, use A.6.F to state the predicate, possible bearer, receiving whole or effect, conditions, and claim status. Begin from outside use, an observed internal failure, a candidate construction, or a feasibility result as the current question requires.
Develop several functional organizations. Vary how interactions and contributions could combine to produce the required outside effect. Include decision-relevant situations—for example, operating, degraded, maintenance, recovery, or consequential foreseeable use—when they can change the decision. A tree is optional; other selected structures may represent, for example, flows, feedback, cooperation, shared contributions, or mode-dependent relations.
Generate materially different bearer arrangements. Start with actual or intended Systems that might carry the contributions. For each arrangement, state how each candidate System would be obtained and operated— for example, by using an available System, procuring or realizing one, relying on provider Work, or combining software and physical Systems. Record shared resources and changes to supporting Systems as dependencies unless they themselves carry a contribution. Vary decision-relevant structures—for example, physical principle, distribution, placement, redundancy, containment, control boundary, or interface grammar. State separately whether an actual System exists, whether it is procurable, what realization or provider Work is needed, and which candidate claim still lacks support.
Write many-to-many proposed allocations. Associate functional contribution claims and candidate bearers explicitly. Permit several bearers for one contribution, several contributions for one bearer, and different allocations by mode, use, configuration, place, or effectivity. Treat weak cues—for example, co-location, matching names, diagram overlap, product kind, ownership, or system-role assignment—only as possible evidence for a separately stated claim.
Develop interface and placement conditions. For every material interaction, state the boundary and participants. Add the conditions that matter to the decision—for example, exchanged quantity or signal, units, geometry, protocol states, timing, capacity, environment, error handling, configuration, and effectivity. Identify the physical realization or missing realization separately from the interface specification. Add decision-relevant constraints—for example, placement, access, assembly, maintenance, supply, or resource constraints—when they change feasibility.
Challenge intended and unintended interaction. Test the proposed arrangement against relevant cases—for example, loads, failures, swaps, reversals, stale configuration, unavailable resources, human or machine misuse, and external change. For consequential wrong use, compare candidate changes—for example, to geometry, keying, protocol, control, detection, containment, or operation. Test evidence supports a mitigation claim only for the tested interaction and conditions.
Check realization and integration dependencies. Identify each dependency needed to make and join the bearers—for example, a System, Method, capability, resource, service, assembly Work, configuration episteme, or specialist result. Record each dependency with its own kind and relation to the proposal. Distinguish a missing catalogue item from a missing physical principle and from a missing project capability. When a recursive realization dependency is current, use SYSE.3 to develop it; do not hide it in a module name.
Compare engineering consequences. For each proposal, state predicted gains, losses, and unknowns for the current decision. Compare proposals for the engineering concerns that matter, such as performance, energy, safety, security, fault containment, latency, placement, service access, manufacture, assembly, integration, supply, cost, configuration, changeability, evidence burden, and affected-System consequences. Express each comparison through a characteristic with an explicit subject, conditions, Scale, and comparison frame. Bring in specialist Methods for the actual physics and risks.
Examine a representative slice. Use available evidence that supports the present claim under the needed representative conditions. When further challenge Work could change the decision, use C.11.DUA and the applicable C.11 or specialist experimental-design Method to decide whether to obtain it, comparing its attainable contribution with the whole burden. For selected Work, choose the Method suited to the claim—for example, computation or simulation, prototype-building and testing, or a physical trial. Identify each performed Work whose result is relied on, the Agent that performed it, and the observations produced. A model, simulation result, or trial observation remains an input to later claim assessment; its form alone does not establish feasibility of the whole proposal.
State the decision use and local stop. Record which alternatives remain usable, were revised, combined, or rejected; record the reasons, protected losses, and smallest unresolved dependency. When an architecture decision is current, use this account as an input to the Work governed by SYSE.6. When no admitted bearer can satisfy a sound contribution, choose explicitly among another bearer, a changed functional organization, new realization or supporting-System capability, bounded exploratory Work, or stopping the current proposal. Pause only the commitment whose basis is missing.

This numbered list is a learning and presentation unfolding governed by A.22.CGUS, not a WorkPlan or a temporal account of performed Work. It keeps the reasoning questions together without requiring Work to follow the displayed order. Functional reasoning, construction search, specialist analysis, realization, integration, trial, and concept revision can overlap and recur. The logical dependency of one claim on another does not imply that all Work producing the first result finishes before Work on the second begins.

SYSE.5:4.2 - Record the Result

Result position	Required content
bounded use	Project System or intended referent, decision question, outside effect or observed failure, use situations, configuration, operating envelope, horizon, and protected characteristics.
functional alternatives	Several candidate claims about functional organization, or a justified smaller set; each names the selected functional structure or possible-future structure content, its functional contribution claims, interactions, conditions, modes, and unresolved causal or functioning claims.
bearer-and-interface alternatives	Candidate actual Systems or intended referents, obtaining or proposed constructive and placement structures, interface specifications and physical realizations or gaps, separate existence, procurement, provider-Work, and realization claims, and materially distinguishing principles.
proposed allocations	Explicit many-to-many function-to-bearer associations qualified by use, conditions, configuration, place, mode, and effectivity; actual functioning is grounded separately.
feasibility and conflict	Capability needs, loads, margins, resources, placement, realization and integration dependencies, wrong-use cases, conflicting characteristics, supported and unsupported claims, and first unsupported dependency.
evidence boundary	Models and descriptions used, performed analysis or trial Work, the Agents that performed it, observations, source editions, uncertainty, and claims those observations do and do not support.
decision use and local stop	Alternatives retained, revised, combined, or rejected; reasons and protected losses; the decision question and architecture-decision Work that can use the account; and the smallest unsupported commitment to pause or proposal to stop.

The account can use several linked representations. Each representation names the functional organization, constructive organization, or engineered System it describes, and the account states the correspondence among those subjects.

SYSE.5:4.3 - What Changes in Practice

Engineers stop asking which named component implements each box and start asking which materially different arrangements can produce the required outside effect under the actual use conditions. They no longer treat functional names as purchase items or procurement specifications. Interface standards become inspectable specifications and evidence questions. Failed feasibility changes the smallest affected functional or bearer claim instead of silently collapsing the candidate set or restarting the whole project.

SYSE.5:5 - Worked Case: Heat-Pump Plant Control and Protection

An occupied building has a heat-pump plant whose controller must respond to electricity-price and grid-flexibility signals while maintaining room comfort and protecting compressors. The engineering team must choose a control architecture for plant configuration HP-2 that remains useful for the next three heating seasons. Earlier concept-development Work produced two viable use/System concepts and one unresolved mismatch: centralized optimization improves plant coordination, but communication loss must not remove local protection.

During allocation Work, the engineers restore four contribution families as claims whose bearer arrangements remain to be chosen:

modulate heat production against building demand under temperature, occupancy, tariff, and plant conditions;
keep compressor pressure, temperature, cycling, and flow within protected limits;
accept, validate, and act on external price or flexibility signals within declared timing and authority;
retain local safe operation and recover state after communication, sensor, or controller failure.

They develop three materially different proposals:

A central building controller carries demand estimation, optimization, dispatch, and most protection logic; unit controllers provide actuation and a small emergency stop.
Local unit controllers carry protection and normal regulation; a supervisor sends bounded set-points and coordinates units, while loss of the supervisor leaves a declared local operating envelope.
Thermal storage and a tariff scheduler carry most time-shifting; local controllers retain protection and regulation, so grid response is split across storage, scheduler, drives, sensors, and plant state estimation.

The functional contribution claims and candidate bearers are not one-to-one. Protection is distributed across software, local electronics, sensors, drive limits, valves, and physical pressure relief. Grid response depends on the supervisor or scheduler, communication bearer, storage state, unit capability, and operating permission. Every bearer entry identifies an actual System or intended referent and its proposed allocation. A model-box label such as protection or optimization is only a cue for recovering those claims.

The interface account separates signal semantics, units, timestamps, command validity, latency, state quality, fallback behavior, configuration identity, and physical connections. The team separately tests rejection of stale commands, agreement of sensor units, local fallback behavior, and the integrated plant contribution. Simulation Work challenges thermal and tariff behavior; Hardware-in-the-Loop Work challenges timing and fallback; a bounded plant trial challenges actual integration. Each produces observations with different claim limits.

An AI coding Agent proposes a fourth function graph and controller split. That Agent and the engineers perform candidate-generation and criticism Work; the generated graph is a description candidate. It enters the account only after its functional claims, candidate bearers, interface assumptions, and unsupported physical dependencies are recovered.

The account retains proposals 2 and 3 and rejects proposal 1 because its local protection split cannot satisfy the declared communication-loss condition. It also records one unresolved storage-cycling evidence need. The two alternatives, allocation conflicts, predicted losses, and conditions for revisiting the decision become inputs to architecture-decision Work governed by SYSE.6.

SYSE.5:5.1 - Small Wrong-Use Check

A service machine uses one lubricant cartridge and one cleaning-solvent cartridge. Cross-connection damages seals. The engineer states the two fluid-delivery contributions and service conditions, then compares candidate cartridges, ports, seals, and connection arrangements. The retained proposal uses mechanically distinct keyed couplings whose materials and geometry fit the relevant fluids, pressure, assembly, and service conditions.

The check attempts every intended connection and the consequential swapped connections under the declared conditions. A colour label is a cue, not evidence that cross-connection is impossible. If an intended connection fails or a damaging swap remains possible, the allocation and interface proposal reopens. The resulting observations can support claims only about the tested configurations and wrong-use cases.

SYSE.5:6 - Biases to Watch

Three recurring biases matter here. Incumbent-form bias lets a function tree, current parts, or a supplier catalogue determine the candidate architecture; start from the required effect and compare materially different arrangements. Conformance-label bias lets an interface name, standard, or certificate replace project evidence; state the interface claim and test it under the relevant conditions. Fluent-generator bias lets a plausible human- or AI-generated graph outrun bearer physics; recover the claims, Systems, and unsupported dependencies.

Agents—for example, a person, team, organization, robot, or sufficiently agentic AI System—may perform candidate-generation, modeling, criticism, or trial Work when they have the needed capability and authority. For each performed Work, record the Agent, assignment, Method, observations, and claim limits. Application DPFs supply subject-specific Methods—for example, Methods for physics, software, safety, law, environment, economics, or assurance.

SYSE.5:7 - Conformance Checklist

ID	A conforming use…
`CC-SYSE5-1`	names one actual System or intended-system designator selected as the project system-of-interest, decision question, use, configuration, operating envelope, horizon, and required outside effect or observed failure.
`CC-SYSE5-2`	restores function-like claims through their predicates, possible bearers, conditions, and receiving effects rather than relying on functional labels.
`CC-SYSE5-3`	develops materially different functional and bearer-and-interface alternatives or justifies why a smaller set is decision-sufficient.
`CC-SYSE5-4`	keeps functional organization, constructive organization, placement, Work, Method, descriptions, and evidence distinct.
`CC-SYSE5-5`	states many-to-many proposed allocations with use, mode, configuration, place, and effectivity where they change the decision.
`CC-SYSE5-6`	separates interface specifications, physical realizations, connections, interactions, and compatibility evidence.
`CC-SYSE5-7`	challenges consequential load, failure, integration, and wrong-use cases using available evidence, states its supported and unexamined boundaries, and selects further Work only when its attainable contribution warrants the whole burden.
`CC-SYSE5-8`	states separately whether an actual System exists, whether it is procurable, what realization or provider Work is needed, and which candidate claim remains unsupported.
`CC-SYSE5-9`	names each decision-relevant dependency by its own kind and relation to the proposal.
`CC-SYSE5-10`	makes alternatives and explicit conflicts usable by named architecture-decision Work and records selection and realization as separate Work and claims.

SYSE.5:8 - Common Failures and Repairs

Failure	Symptom	Repair
Incumbent-parts decomposition	The current bill of materials becomes the functional organization.	Restate the outside effect and develop rival functional organizations before preserving the incumbent allocation.
Functional element as purchase item	A box named sensor, protection, or storage is treated as a procurement specification or purchase item.	Recover the function-like claim, candidate actual or intended bearer, interfaces, placement, capability need, and assembly relation.
One-to-one allocation	Every contribution is forced into one component and every component into one contribution.	Permit many-to-many and mode-dependent proposals; inspect joint and shared functioning.
Diagram overlap as relation	Matching labels or co-located symbols establish identity, allocation, or functioning.	State the direct claim and supporting evidence; keep representation correspondence separate.
Interface label as proof	Standard, open, or a connector name establishes compatibility or substitution.	State interface conditions and test conformance, integration, intended interaction, and consequential wrong use separately.
Available product as only candidate	Catalogue availability is treated as the boundary of possible construction.	Keep physical candidate generation separate from the choice of obtaining arrangement; use `SYSE.24` when that obtaining choice becomes current.
Unavailable product as no construction	An unsuccessful search erases candidate bearer descriptions already examined.	Retain the candidates and failure reasons; distinguish market absence, physical infeasibility, and missing project capability.
Fewer bearers as automatic improvement	Consolidation or a universal platform is assumed superior.	State transferred contributions, affected characteristics, scale window, losses, and evidence burden; keep it as one candidate.
AI graph as design truth	A generated function graph is accepted because it is connected or plausible.	Recover claims and bearers, challenge physical and interface dependencies, and qualify the generator and evidence.
Trial as universal proof	One simulation or bench result establishes full functioning and architecture adequacy.	State the Agent, Method, conditions, configuration, observations, claim limits, and the later claim-assessment Work that can use them.
Architecture decision hidden in generation	The preferred candidate is silently selected during modeling.	Preserve the decision-usable candidate account, including explicit losses and unresolved claims, as an input to architecture-decision Work governed by `SYSE.6`.
Whole-project stop	One missing bearer blocks every Work stream.	Pause only the unsupported commitment; select another bearer, revise the function, change realization capability, explore, or stop the bounded proposal.

SYSE.5:9 - Consequences

Engineers gain alternatives that can survive contact with physical realization, integration, procurement, and operation. Functional freedom remains tied to stated bearer claims and use conditions. Supplier claims and AI-generated candidates become inspectable inputs. Wrong-use cases, interface gaps, unallocated contributions, and unsupported realization dependencies appear early enough to change the architecture choice.

The cost is maintaining correspondence among several selected structures and qualifying claims by use, configuration, and evidence. Candidate diversity also costs modeling and specialist Work. Those costs are bounded by the decision question and stop rule: stop with decision-sufficient alternatives and the first unsupported feasibility dependency.

SYSE.5:10 - Rationale

FPF already explains functions, structures, modules, interfaces, candidate synthesis, and architecture choices. Apply these to engineering by keeping the required outside effect and use visible while engineers iteratively develop functional organizations, actual or intended bearer arrangements, many-to-many allocations, physically meaningful interfaces, realization dependencies, wrong-use challenges, and bounded evidence use for one engineered-System decision. Procurement, realization, assurance, and continuing engineering Work need those constructive and integration details.

SYSE.5:11 - SoTA and Source Use

Functional and constructive organization can diverge. Compare function-to-bearer allocations, including many-to-many relations, together with interfaces, intended and unintended uses, integration and later revision. Current FPF distinctions govern the selected views, roles and allocation relations used in that comparison.

Source line	Use here	Epistemic boundary
Eisenbart, Gericke, and Blessing 2017, Yildirim and Campean 2020, and She, Belanger, and Bartels 2024	Supports heterogeneous function-model purposes and formalisms, iterative functional/structural reasoning, flow- and time-aware analysis, and functional decomposition as an exploratory move.	The reported ten-company exploration, mobility case, and preliminary metrics example support their bounded uses. Notation, sequence, broad effectiveness, and decomposition policy remain open questions.
Monetti, Lundström, and Maffei 2025 and Grønvald et al. 2026	Brings assembly and modular-product consequences into early candidate development and requires explicit economic and data limits.	The sparse, bounded company evidence supports local assembly and modular-product consequences. Broader benefit, cost, substitutability, and Method-dominance claims remain open.
Haddad and Seibel 2025	Supports AI-assisted generation and iterative refinement of candidate function structures.	The bounded course comparison reported 42% error-free and 72% fully connected outputs for its best configuration and left, for example, non-functional requirements, domain interdependencies, physical effects, and principal solutions outside. Use it as evidence for candidate generation under the reported conditions; project correctness, bearer feasibility, and architecture selection require project evidence.
Current FPF `A.6.F`, `A.6.M`, `A.22`, `C.30`–`C.32`, `C.31`, representation, comparison, evidence, and assurance patterns	Used for the normative ontology and transdisciplinary candidate-synthesis machinery.	This DPF uses those kinds and the general palette, then adds the applied Systems Engineering Method and result needed for engineered functional contribution, bearer allocation, physical interfaces, realization, integration, wrong-use challenge, and decision use.

Official modular-open-system or model-based guidance may contain current interface fields or candidate prompts. Treat enacted project prevalence, interoperability, effectiveness, and SoTA as separate claims grounded by direct industrial observations or qualified expert estimates when stronger evidence is unavailable. State their epistemic status. Reopen only the claims affected by a newer source that changes the allocation Method, interface test, AI-use boundary, modularity consequence, or application-profile restriction.

SYSE.5:12 - Relations

When compatible, practitioners can use linked use/System candidates and unresolved mismatches from a SYSE.2 result as inputs. They must still check the subject, configuration, horizon, evidence, and compatibility before developing the alternatives in this account.
Use A.6.F to restore each function-like claim and possible bearer. A.6.M governs module and interface claims; A.22 and C.30 govern selected structures and architecture relations. Applying those patterns alone does not produce the Systems Engineering allocation account defined here.
Use C.32 for general multi-structure architecture-candidate synthesis. SYSE.5 specializes that Method with the required-effect, functional-organization, constructive-bearer, physical-interface, realization, integration, wrong-use, and decision-use questions. Use a C.32 candidate palette here only when its subject and fields fit the current decision question.
The allocation-alternative account is an input to architecture-decision Work governed by SYSE.6. That Work may produce a chosen architecture and conditions for revisiting it. Candidate generation in SYSE.5 does not select the architecture.
When an unsupported realization or build-the-builder dependency, evidence claim, description-correspondence problem, or assurance question is current, apply SYSE.3, SYSE.10, SYSE.7, or SYSE.4 respectively to its own subjects and sources. The realization dependency, evidence claim, description-correspondence problem, and assurance question concern different engineering subjects and require different Work results; Work performed for one does not supply the missing results for the others. A description ensemble remains distinct from candidate Systems, allocations, interfaces, and the selected architecture.
Under XRI-03, practitioners can reuse a compatible SYSE.5 result in MDPE.3 when an engineered instrument, robot, hybrid body, venue, or software System is itself an architecture subject in the performing whole. Recheck the reused result against the MDPE subjects, authority, conditions, evidence, and current music-and-dance sources.
Agents performing downstream application Work—for example procurement, manufacturing, configuration, maintenance, operations, software, electrical, mechanical, safety, or human-factors Work—use the result through their own Methods, authority, conditions, and evidence.