SYSE.3:1 - Problem frame

Use this pattern when an engineer has one grounded architecture candidate or project architecture decision, but cannot yet show how existing Systems and feasible Work can bring about or change the proposed System and its selected structures. The architecture may name suitable bearers for required functioning while a realization branch—for example, fabrication, adaptation, integration, configuration, installation, qualification, or build-the-builder Work—remains unsupported.

First useful move: name one unsupported realization branch, the proposed transformer System, the missing enabling condition, and one next planned action or earlier answer to revisit. This is enough to turn a broad claim that the architecture is “buildable” into a specific feasibility question. Expand the description only when several branches interact or the next action itself depends on realizing a transformer System, capability, Method, tool, or platform contribution.

If this move is missed, a project description—for example, a product tree, WBS, schedule, toolchain diagram, or platform name—can look like a realization argument. Engineers can then plan Work for a System that does not exist, assign Work to a label that has no capable holder, or discover late that a selected interface, material, access condition, or integration relation cannot be realized.

The payoff is a bounded realization account. The engineer inspects dependencies only far enough to find the first unsupported one, plans one useful next action, and uses an infeasibility result to reopen only the smallest earlier answer it changes. A build-the-builder branch appears only when changing an enabling System, capability, Method support, tool, or platform changes that next action.

Use this pattern after the architecture has at least one candidate bearer for every required functioning at issue. Otherwise keep the architecture question open with A.6.F, C.30, and C.32. Use A.3.4 for an actual bounded change, the A.15 family for Work and production claims, and E.18 or E.18.NET only when their selected-structure conditions are met. Use Operations Management or project-portfolio practice when the live question is queue, capacity, priority, or shared-resource coordination rather than realization of one architecture candidate.

At the first consequential use of words such as creator, builder, developer, design, production, deployment, platform, toolchain, or baseline, ask: which realization branch is unsupported? Name the intended result or change, the proposed transformer System or unresolved need for one, and the missing enabling condition. Use the local TransformerSystemRole to describe the System’s contribution only when that distinction matters. Treat a source stage name or tool label as a cue; establish the Work order, assignment, capability, and relation that the current branch actually uses.