SYSE.3 - Plan the Next System-Realization Action (Recursive Realization Network)

SYSE.3:0 - Use This When

Use this pattern when one grounded engineering architecture candidate or decision exists, but no current account shows which actual Systems, capabilities, Methods, resources, interfaces, and Work could bring about the proposed System or change.

The first useful move is to name one unsupported realization branch, its proposed transformer System or the need to find one, the missing enabling condition, and one next planned action or earlier answer to revisit. Expand only when another build-the-builder branch changes that next action.

The result is a RecursiveRealizationArrangementResult@Project, a project-local U.Episteme containing a provisional realization-network description plus a distinct U.WorkPlan. It identifies the first unsupported branch, proposed transformer and enabling Systems, identified gaps, result dependencies, and the earlier answers that each gap can reopen. The description and WorkPlan are epistemes for analysis and planning. Establish performed Work, actual change, an obtaining network, and feasibility through their direct evidence and patterns.

Use current FPF architecture patterns when the architecture or bearer choice is still open. Use the relevant specialist pattern when the question has left this realization account—for example, a question about performed Work, transformation, production, capability, platform engineering, operations, organization change, configuration, or assurance.

SYSE.3:0.1 - Terms and Distinctions

An engineer is an admitted System classified by and assigned to an engineering SystemRole for the Work. The performer System, SystemRole, assignment, Method, capability, WorkPlan, Work, transformation, result episteme, and engineered System remain distinct.

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.

SYSE.3:2 - Problem

An architecture candidate proposes an organization of the System, but it does not make that organization exist. For example, a selected module, interface, placement, control relation, or configuration may depend on changes to pre-existing materials and Systems, first constitution of new Systems, integration Work, and Systems capable of performing that Work. Those transformer Systems can themselves need new capabilities, tools, Methods, resources, configuration, or prior change.

A single decomposition rarely exposes all of these dependencies. A component tree follows the proposed System; a WBS follows intended Work; an organization chart follows one organization; a platform inventory or diagram follows selected technical means. None alone answers which actual Systems can perform the needed Work under the stated conditions. The engineering difficulty is to connect these descriptions without merging architecture, intended change, transformer capability, WorkPlan, performed Work, and evidence into one diagram.

SYSE.3:3 - Forces

SYSE.3:4 - Solution

SYSE.3:4.1 - Start from one named architecture result

Start with one current architecture result for one described holon:

1. the current C.30 architecture question and claim;
2. one C.32 candidate configuration or one C.32.PAD project architecture decision;
3. the selected structures, constraints, assumptions, and expected architecture gain that matter to realization; and
4. the next use for which feasibility must be known.

The input may remain modal. A candidate structure is not an obtaining ArchitectureRelation, and a project decision does not make the decided structure actual. Keep the architecture result and the realization account as separate claims. When provider capability, continuing provision, access, custody, responsibility, or recovery can change realization, use only the supported claims and design constraints from a compatible SYSE.8 provider-arrangement account for the same subject, configuration, use, horizon, decision, and evidence window. Without a compatible current account, use a qualified direct source for the claim needed by this branch or record the missing result. The account supplies supported provider claims and design constraints. Establish the provider arrangement, provider Systems, performed Work, responsibility, and authority separately when the branch uses them.

Check the architecture boundary before proceeding. If the candidate lacks a bearer for required functioning, reopen the bearer question under A.6.F and C.32. Continue here when the candidate has a proposed functional and structural answer but the Systems and Work needed to constitute, change, integrate, or qualify it remain uncertain.

SYSE.3:4.2 - Describe one realization branch

Write one branch in ordinary language. Include only the distinctions that change the feasibility question:

• the architecture result to be realized;
• the pre-existing System, material, assembly, description, or other referent that would be changed, or the identity and completion conditions for a System that does not yet exist;
• the intended change, production result, interface state, integration state, or configuration relation;
• the proposed transformer System or unresolved need for one and the local TransformerSystemRole condition it would meet for this Work;
• the needed Method, capability envelope, resource, tool or platform contribution, access condition, interface, integration, and configuration relation; and
• the fact or specialist result that would make the branch usable, require its repair, or reopen an earlier answer.

Keep modal and actual claims apart. An intended change belongs in a plan or description until an actual continuing referent, boundary, conditions, and before/during/after facts satisfy A.3.4. When the proposed System does not yet exist, describe changes to pre-existing materials or assemblies and use A.15.PROD later for independently grounded identity inception and production completion. Do not describe transformation of a future System before it exists.

The claim that a candidate transformer will perform the Work is also modal. Name the candidate holder System, or the unresolved need for one, and the local TransformerSystemRole condition in the WorkPlan. Use A.2.1 only when an assignment occurrence actually obtains, and use A.2.2 only when the holder’s capability has a recoverable Work family, envelope, measures, qualification window, and currentness condition. Treat a job title, supplier category, tool list, past success, or Method description as possible evidence inputs; establish the capability claim through its Work family, envelope, measures, qualification window, and currentness.

SYSE.3:4.3 - Find the first unsupported answer

Use the A.1.STM long mantra to keep the architecture result, intended outside use, and builder dependencies in attention. Read the logical dependency backward and find the first unsupported answer that prevents one credible next realization action. First means logically first for this dependency, not earliest in a calendar or prescribed process. Use these six working questions to classify the first gap:

Record the first gap even when later gaps are already suspected. Use it to choose the next action.

SYSE.3:4.4 - Recurse only when the next action depends on it

Open another branch when the current transformer System, capability, Method, tool, or platform contribution must itself be brought about or changed before the current branch can proceed. Apply the same questions to that branch. Do not introduce fixed builder levels: a transformer System can serve several branches or projects, and evidence from a later branch can change an earlier branch claim.

When several branches must be considered together, begin with a Plain provisional realization-network description. Name the proposed members and the missing cross-branch relation or binding. Use E.18 only for one selected transformation-flow structure whose identity is established. Use E.18.NET only after at least two independent member structures, the obtaining cross-flow relation occurrences, the endpoint bindings, applied constraints, and the current use frame are recoverable. Until then, the episteme describes a proposed realization network; it is not the selected network itself. When a cross-branch arrow uses a generic cue—for example creates, builds, uses, supplies, or depends on—replace it with the actual production, participation, use, evidence, integration, configuration, supply, or other relation through the pattern that defines it. If the relation kind or case facts are not yet available, keep the dependency as a provisional claim and name what must be established.

Keep each DesignRunTag local to one leaf-position binding. Represent any wider dependency or Work order through the direct relations that establish it.

SYSE.3:4.5 - Plan the next Work separately

Create or amend one A.15.2 WorkPlan after the first unsupported answer is visible. The smallest useful WorkPlan needs one substantive PlanItem that states:

• the present EntityOfConcern and planning horizon;
• the intended Work or investigation;
• the candidate performer System and local SystemRole-kind conditions;
• the Method, capability threshold, resources, tools, access, and dependencies needed for that Work; and
• the result or evidence that will update the branch or reopen an earlier answer.

The next Work can take different forms—for example, investigating a supplier, qualifying a capability, developing a fixture, changing a transformer System, obtaining a specialist result, integrating a bounded slice, or revising the architecture candidate. Select the action that resolves the first unsupported answer; do not schedule every visible branch.

The WorkPlan states intended Work and its conditions. Establish every later assignment, capability, resource availability, relation, Work occurrence, transformation, and result through its direct evidence and pattern. When Work is later performed, use A.15.1 and F.6 for its performer and attribution, A.3.4 for actual changes, and A.15.PROD for production, identity-inception, or completion claims. Compare the resulting facts with the plan only when that separate question is current.

SYSE.3:4.6 - Obtain specialist results without absorbing their Methods

Keep the realization branch connected while leaving specialist decisions with the practice that can make them. Examples include:

Name the contribution that an enabling arrangement actually makes. For example, identify the bounded contribution of a platform, team, supplier, administrative service, or configuration repository. When no maintained receiving pattern exists, retain the unresolved specialist need and the decision it blocks.

SYSE.3:4.7 - Stop at one actionable gap and name the affected earlier answer

The first result can be stated in five lines:

1. Architecture input: the named candidate or decision and the selected structures at issue.
2. Unsupported branch: the intended result or change whose realization is not yet supported.
3. Missing support: the proposed transformer System or unresolved need for one and the capability, Method, resource, platform contribution, interface, integration, or configuration result still needed.
4. Next Work: one WorkPlan item that can resolve that gap.
5. Affected earlier answer: the branch, architecture answer, linked concept, or project-focus claim to reopen if the result defeats it.

Stop when these five lines make the next action and affected earlier answer clear. Expand only when interacting branches or build-the-builder recursion changes that next action.

When feasibility evidence arrives, update the branch description and WorkPlan. If one branch fails but another admissible branch remains, repair or replace that branch. If no admissible realization remains, reopen the architecture candidate or decision. Reassess the linked use-and-system concept under SYSE.2 only when its use or concept claim must change, and reassess the project-system choice under SYSE.1 only when the project focus or boundary must change. Cost already incurred supplies no reason to preserve an unsupported answer.

SYSE.3:5 - Archetypal Grounding

Pumping station under flood risk

FloodPumpStation-7 : U.System exists at configuration FPS7-C18. SYSE.2 supplies a compatible station concept for changing that station so it can move water under the selected flood load without unacceptable downstream harm. StationArchitectureDecision-7, a compatible SYSE.6 result, selects StationArchitectureCandidate-7 with a changed discharge assembly, interfaces, placement, and control relations. The architecture has proposed bearers for the required station functioning; the open question is how to realize the changed assembly. Station7ProviderArrangementAccount-R1, a compatible SYSE.8 result, supplies only current provider, access, custody, and recovery claims that bear on the supplier branch. It establishes no supplier capability, assignment, Work, or production result. The first use produces this filled five-line result:

1. Architecture input: StationArchitectureCandidate-7, including the selected discharge interface, placement, material, geometry, and tolerance claims.
2. Unsupported branch: ManifoldRealizationBranch-1; a pre-existing discharge-manifold blank must be changed, and a newly constituted mounted subassembly must satisfy those claims.
3. Missing support: SupplierWeldCell-4 is the candidate transformer System for later welding Work. The branch still needs a capability result for the selected material and geometry and a feasible positioning fixture.
4. Next Work: the WorkPlan contains FixtureAndSupplierFeasibilityInvestigation-1. Its intended performer is StationRealizationEngineeringTeam-2, not the supplier weld cell whose later production capability is being investigated.
5. Affected earlier answer: if no fixture-and-weld branch meets the selected interface and access conditions, reopen the C.32 comparison of interface, material, module split, and placement alternatives.

For this case, the PlanItem records the following intended Work and conditions:

Station7RecursiveRealizationArrangement-R1 : U.Episteme is the case result. Its EntityOfConcern is StationArchitectureDecision-7 for the bounded station-realization question. It cites the provisional realization-network description and the distinct WorkPlan, names ManifoldRealizationBranch-1 as the first unsupported branch, records the proposed transformer and enabling Systems, and names the earlier architecture claim that the fixture-and-weld gap can reopen. It establishes neither an obtaining realization network nor performed Work.

If the fixture itself must be developed, that need opens one recursive branch for a toolmaking System and its capability. The engineer stops there unless this branch changes the immediate investigation. If no admissible weld or fixture branch remains, the engineer reopens the C.32 comparison of interface, material, module split, and placement alternatives. The engineer reassesses the linked station concept under SYSE.2 only if the concept or outside-use claim must change. The fixture does not become part of the pump merely because realization needs it. The supplier’s shop title does not establish welding capability, and the WorkPlan does not establish that welding Work or manifold change occurred.

Manufacturer’s ERP-enabled planning change

The architecture candidate concerns one deployed production-planning System. It names the software bearer, interfaces to order and shop-floor Systems, selected data and decision relations, and the planning functions that those Systems are expected to support.

The first unsupported branch is the change from current product, order, and resource descriptions to the configuration and integration state required by the candidate. PlanningIntegrationTeam-2 is the candidate transformer System for RepresentativePlanningDataIntegrationWork-1: mapping one representative data family and configuring its source-to-planning interface. The planned holder-dependent capability requirement is the ability of that team to apply BoundedPlanningDataMappingMethod-v1 under the actual source semantics, access, timing, and configuration conditions. This is WorkPlan content until A.2.2 supplies a current capability result and A.2.1 supplies an assignment occurrence when one is needed.

MigrationToolService-3 is a separate proposed tool or service contribution to that Work: access to a named mapping-execution interface under the selected configuration. This case attributes no transformer assignment or data-mapping capability to that service label. If a later claim relies on it as an acting System, the engineer applies System recognition before making separate claims about its role, capability, and Work. The immediate WorkPlan item names PlanningIntegrationTeam-2 as intended performer of the representative-slice feasibility investigation and asks for RepresentativeIntegrationFeasibilityAccount-1 plus any organization- design result needed to make the slice feasible.

If the gap concerns who may change source definitions, which organization holds an assignment, or which authority relation applies, the engineer obtains that result from Organization Engineering or Governance rather than encoding it as a technical interface. If the branch cannot preserve the required decision timing or data meaning, the engineer reopens the C.32 comparison of interface, placement, and responsibility structures. The engineer reassesses the linked planning concept under SYSE.2 only when the planning-use claim must change. The words platform and migration pipeline establish neither integration capability nor one universal Work order.

Occupied building retrofit

SYSE.2 supplies the continuing building, the occupied-use claim, and a candidate concept through the occupied region, safe-entry, egress, and essential-service interfaces. C.30 and C.32 supply candidate building zones, service paths, interfaces, and load-bearing relations. Temporary access, work-area isolation, and construction sequencing remain realization and WorkPlan questions.

The first unsupported branch is how a contractor System can reach and change the selected building region while the occupied-use boundary and essential services remain supported. The candidate transformer System is one contractor team. Access-equipment Systems remain separate resources or participating Systems unless their relation to the team is independently established. The missing support is a capability claim under the occupied configuration, access, isolation, load, and service-continuity conditions. The first WorkPlan item is a contractor-capability and temporary-access investigation for those conditions.

If no admissible access arrangement remains, the engineer reopens the C.32 comparison of zones, service paths, placement, and interfaces. The engineer reassesses the linked occupied-use concept under SYSE.2 if continuing occupancy or the use boundary must change. A construction sequence is plan content; it is not the building concept, the changed building, or evidence that the Work has occurred.

SYSE.3:6 - Biases to Watch

Two recurring biases matter here. Diagram-made feasibility treats a product tree, schedule, or toolchain description as proof that capable transformers and relations obtain; return to the first unsupported branch. Endless builder recursion expands every dependency before choosing useful Work; recurse only when the added branch changes the next action.

SYSE.3:7 - Conformance Checklist

SYSE.3:8 - Common Anti-Patterns and How to Avoid Them

SYSE.3:9 - Consequences

Engineering participants gain an early feasibility result without waiting for a complete WorkPlan. One unsupported branch becomes visible together with the System and Work needed to resolve it. Recursive build-the-builder dependencies can be added where they change the next action, while architecture candidates remain open to repair.

The cost is explicit incompleteness. A provisional realization-network description can contain unresolved Systems, capabilities, Methods, relations, and specialist needs. Maintaining the distinction between that episteme, a WorkPlan, and actual Work takes care, but it prevents planned or drawn dependencies from being mistaken for physical feasibility.

SYSE.3:10 - Rationale

Systems Engineering connects a proposed System to the Systems and Work that can make or change it. The systems mantra keeps outside use, architecture, and transformer dependencies in view. In this pattern, engineers inspect those dependencies toward the first unsupported branch and relate later observed Work and change through their own facts. These are two views of the case, not one calendar sequence.

The recursive account is deliberately demand-driven. An exhaustive description of every supplier, tool, team, capability, and possible dependency would be expensive and unstable. One unsupported branch plus one WorkPlan item is already enough to change what the project does next. Further recursion is justified only by that next decision.

SYSE.3:11 - SoTA-Echoing

These sources support particular realization branches. This pattern combines the use of documents in Work, creation relations, recursive consideration, Method choice, continuing development, platform Work and configuration. Its synthesis works backward to the first unresolved need, bounds recursion and revises the affected local arrangement under current FPF. Reconsider the affected realization claim or receiving architecture decision when comparative evidence changes applicability or shows that a specialist Method is needed.

SYSE.3:12 - Relations

• A compatible SYSE.6 architecture decision supplies only the selected structures, constraints, alternatives, accepted losses, and reopen conditions needed by this realization question. A compatible SYSE.8 provider- arrangement account supplies only supported provider claims and design constraints that change a branch. Each use rechecks subject, configuration, use, horizon, evidence window, and availability; otherwise it uses a qualified direct source or records the missing result.
• C.30 supplies the grounded architecture question and claims; C.32 supplies candidate configurations over selected structures; C.32.PAD supplies a project architecture decision when that question is current. A missing architecture function bearer reopens the bearer question under A.6.F and C.32.
• A.1.STM keeps the outside-use, architecture, and realization questions in attention while the engineer finds the first unsupported answer and later relates observed Work and change through independently grounded facts. It supplies neither Work order nor an actual realization network.
• A.2 supplies the local TransformerSystemRole kind; A.2.1 supplies an obtaining assignment; A.2.2 supplies holder-dependent capability and its envelope, measures, qualification window, and currentness. Candidate wording and WorkPlan content establish none of these facts.
• A.15.2 supplies a WorkPlan for intended Work. A.15.1 and A.3.1 govern actual Work and enacted Method. A.3.4 governs actual bounded change, and A.15.PROD governs subject-specific production results and completion claims when those distinct questions are current.
• E.18 supplies one selected transformation-flow structure. E.18.NET supplies a selected network only after independent members, obtaining relation occurrences, endpoint bindings, constraints, and use frame are established. Before that boundary, keep a provisional description and name the missing discriminator.
• SYSE.11 may use only the recursive realization arrangement from a compatible result for the same increment boundary. It does not perform Work, establish platform use or constituent commitments, or make the proposed System actual.
• Feasibility, integration, configuration, cost, delay, and evidence results can change the smallest branch, architecture, concept, use, or project-focus claim to which they apply. Platform Engineering, Organization Change, Operations, portfolio selection, configuration, safety, security, governance, law, finance, and other specialist practices retain their Methods and decisions.

SYSE.3:End