Library / Systems Engineering Principles Framework
Jump to passage
In this reading

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 07:42:37 UTC · snapshot created 2026-10-03 07:43:27 UTC · last check 2026-10-03 07:55:10 UTC

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.