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.