#TEVB — Typical Engineering Viewpoints Bundle

Pattern E.17.2 · Stable Part E - The FPF Constitution and Authoring Guides

Tech‑name: TEVB (Typical Engineering Viewpoints Bundle, bundle id VF.TEVB.ENG) Plain‑name: typical engineering viewpoints bundle for holons Tag: Archetypal species of U.ViewpointBundle for engineering holons

Status. New; archetypal, notation‑agnostic species of U.ViewpointBundle / U.ViewpointBundleLibrary. It is an engineering‑level bundle over holons; it does not itself constitute an architecture framework or architecture‑specific viewpoint library. Architecture‑focused viewpoint bundles are introduced as separate U.ViewpointBundle species that may import TEVB.

Builds on.

• E.17.0 — U.MultiViewDescribing. Supplies the generic notion of U.Viewpoint, U.View, and ViewFamily over an EoIClass ⊑ U.Entity (here: EoIClass = U.Holon).
• E.17.1 — U.ViewpointBundleLibrary. Provides the generic U.ViewpointBundle/ViewFamilyId structure; TEVB is a concrete bundle (VF.TEVB.ENG) in the core library.
• A.1 — Holon. Holon kinds U.System and U.Episteme as the typical engineering entities‑of‑interest.
• A.6.2–A.6.4 — Episteme morphisms. U.EffectFreeEpistemicMorphing, U.EpistemicViewing, U.EpistemicRetargeting as the generic morphism classes behind engineering views.
• A.7 / E.10.D2 — Strict Distinction & I/D/S. I/D/S discipline and DescriptionContext; engineering descriptions/specifications under TEVB are D/S‑epistemes with explicit ViewpointRef.
• C.2.1 — U.EpistemeSlotGraph. Provides DescribedEntitySlot, ViewpointSlot, ViewSlot and the slot discipline (A.6.5) used by TEVB‑aligned descriptions/specs.

Used by.

• E.18:5.12 — E.TGA viewpoint map. As a canonical consumer, E.TGA binds its engineering transduction families (Functional, Procedural, Role‑Enactor/Device‑Structure, Module‑Interface) to TEVB viewpoints VP.Functional, VP.Procedural, VP.RoleEnactor, VP.ModuleInterface.
• E.17 (MVPK). Publication of engineering morphisms uses TEVB engineering viewpoints on the description/spec side and PublicationVPs on the Surface side.
• Engineering description/spec patterns. System, method, module/interface and role‑related description/spec patterns for holons (U.System, U.Episteme) refer to TEVB when declaring their ViewpointRef.
• ISO‑aligned architecture‑description bundles. Future species patterns for architecture‑specific viewpoint bundles reuse TEVB as the canonical engineering view family (Functional vs Structural etc.) over systems and their epistemes.

Guard (lexical & ontological).

1. Engineering scope only. TEVB applies to EoIClass = U.Holon with typical cases U.System and U.Episteme. Using TEVB viewpoints for non‑holonic entities (e.g., pure data structures, abstract theories) requires an explicit species‑level justification; by default it is a conformance violation.
2. Viewpoint vs Surface. VP.Functional, VP.Procedural, VP.RoleEnactor, VP.ModuleInterface are viewpoints (intensional U.Viewpoint specifications), not Surface kinds. They MUST NOT be used as carrier/Surface names (those remain {PlainView, TechCard, NormsCard, InteropCard, AssuranceLane, …} under L‑SURF).
3. EngineeringVPId vs PublicationVPId. VP.* in this pattern are EngineeringVPId values (E.18:5.12) and SHALL NOT be reused as PublicationVPs in MVPK. MVPK must introduce separate PublicationVPId symbols, linked to TEVB viewpoints only through correspondences.
4. No new role coordinates in I/D/S. TEVB references stakeholder groups via U.RoleEnactor families but does not introduce U.Role as a coordinate in I/D/S signatures (E.10.D2). Role semantics remain confined to RoleEnactment patterns (A.15, F‑R family).
5. No extra viewpoints inside TEVB. TEVB defines a fixed core set of four engineering viewpoints. Other labels such as “Assurance‑Oriented”, “Interop‑Oriented”, “Information/Data‑Oriented”, “Operational/Deployment”, “Mission/Context” may appear only as lexical aliases in E.18:5.12 (e.g. as ViewFamilyId / AliasInViewFamilies values for transduction species). They MUST NOT extend TEVB.EngBundle.viewpoints and MUST NOT be interpreted as additional U.Viewpoint kinds in this bundle; when SoTA or local practice demands explicit assurance, information, or mission viewpoints, these SHALL be provided as separate U.ViewpointBundle species that can be imported alongside TEVB rather than by mutating VF.TEVB.ENG.
6. Not an architecture framework. TEVB is an engineering‑level viewpoint bundle; architecture‑specific viewpoint bundles and architecture frameworks MUST be introduced as separate U.ViewpointBundle species that may import TEVB. They MUST NOT redefine VF.TEVB.ENG as an “architecture viewpoint library” or extend it with architecture‑only viewpoints.

Engineering teams almost always talk about systems and their models through a small set of recurring “views”:

• What capabilities and behaviours does the system enact? — function‑oriented, transduction‑oriented talk.
• What sequences, workflows, and control logics does it realise? — procedure/process/state‑oriented talk.
• Who or what enacts which roles? — role‑enactment, organisational and socio‑technical talk.
• How is the system decomposed into modules and interfaces? — physical/logical architecture talk.

#Keywords

• engineering viewpoints
• holon
• Functional/Procedural/Role-Enactor/Module-Interface views
• EoIClass = U.Holon
• ISO 42010 mapping
• E.TGA bindings.

#Relations

#Content

#Problem frame (informative)

Engineering teams almost always talk about systems and their models through a small set of recurring “views”:

• What capabilities and behaviours does the system enact? — function‑oriented, transduction‑oriented talk.
• What sequences, workflows, and control logics does it realise? — procedure/process/state‑oriented talk.
• Who or what enacts which roles? — role‑enactment, organisational and socio‑technical talk.
• How is the system decomposed into modules and interfaces? — physical/logical architecture talk.

In industry, these lenses show up under many names: functional view, logical view, behavioural view, process view, structural/physical view, deployment view, responsibility view, and so on. Modern standards and tools (ISO/IEC/IEEE 42010:2022, INCOSE SE Handbook, SysML v2 “views as queries”) all recognise that viewpoints should be reusable structures, not ad‑hoc labels.

In FPF, E.17.0 and E.17.1 give the generic machinery:

• U.Viewpoint as an intensional specification (stakes/concerns/allowed D/S kinds),
• U.View as an episteme‑level view (epistema under a viewpoint),
• U.ViewpointBundle / ViewFamilyId as reusable collections of viewpoints.

E.TGA (E.18:5.12) already assumes a canonical engineering family with names like “Functional”, “Procedural”, “Role‑Enactor (Device‑Structure)”, “Module‑Interface”. Without a formal bundle tying these together, those names drift and the mapping between E.TGA, MVPK and I/D/S becomes fragile.

TEVB addresses this by defining a single, explicit engineering bundle with a fixed ViewFamilyId and a small set of canonical engineering viewpoints over U.Holon.

#Problem (informative)

Without TEVB, several failure modes recur:

1. Inconsistent “functional/structural/behavioural” vocabularies. Different teams define “functional view” or “process view” differently, even within one organisation; E.TGA E.18:5.12 then has to guess how to map transduction graphs onto whichever interpretation is currently in play.
2. Architecture frameworks leak into the kernel. 4+1‑style and similar architectural frameworks get hard‑coded as if they were universal; FPF loses its holonic neutrality and becomes biased to a particular school.
3. Viewpoints conflated with surfaces and files. “Functional view” is used both for the underlying viewpoint and for a concrete document or dashboard; MVPK faces, E.TGA transduction families, and I/D/S disciplines become entangled.
4. Role leakage into I/D/S. Engineering views that are about role‑enactors are written directly in terms of U.Role, blurring the boundary between RoleEnactment (A.15) and description/spec layers, and breaking A.7/E.10.D2.
5. Poor reuse across systems. Even when organisations want to reuse the same engineering views across products, plants, or models, there is no canonical bundle to import; each programme recreates “its own” functional/structural views.

TEVB makes engineering viewpoint families first‑class reusable bundles and pins them to an explicit EoIClass (engineering holons) so that E.TGA, MVPK and discipline‑packs can align on the same vocabulary.

#Forces (informative)

TEVB resolves these by fixing a minimal engineering bundle and leaving customisation to species patterns and ViewpointBundleLibrary entries that refine concerns and allowed episteme kinds without changing the core families.

#Solution — TEVB as a core U.ViewpointBundle for holons (normative)

#TEVB bundle identity

TEVB is the core engineering viewpoint bundle over holons.

• Bundle object. There exists a canonical U.ViewpointBundle instance:

  TEVB.EngBundle : U.ViewpointBundle

• ViewFamilyId.

  TEVB.EngBundle.viewFamilyId = VF.TEVB.ENG

  VF.TEVB.ENG is reserved for “Typical Engineering Viewpoints (Engineering)” in the FPF core ViewpointBundleLibrary.

• EoIClassSpec (holon scope).

  TEVB is parameterised by

  TEVB.EngBundle.EoIClassSpec =
    { h : U.Holon | holonKind(h) ∈ {U.System, U.Episteme} }

  That is, TEVB applies to holons that are either U.System or U.Episteme. Other holon kinds MAY be added by species patterns but MUST be justified and documented; the default conformance profile assumes systems and epistemes.

• Library placement.

  TEVB lives in the core viewpoint library:

  TEVB.Library : U.ViewpointBundleLibrary
  TEVB.Library.libraryId = FPF.Core.Viewpoints
  TEVB.Library.bundles ⊇ { TEVB.EngBundle }

  Additional organisational libraries MAY import and specialise TEVB, but SHALL NOT redefine VF.TEVB.ENG with incompatible semantics.

• Viewpoint set.

  TEVB defines a finite set of canonical engineering viewpoints:

  TEVB.EngBundle.viewpoints =
    { VP.Functional, VP.Procedural, VP.RoleEnactor, VP.ModuleInterface }

The selection {VP.Functional, VP.Procedural, VP.RoleEnactor, VP.ModuleInterface} is the current NQD‑frontier for engineering holon viewpoints in Part G: it realises a Function–Behaviour–Structure‑plus‑Role (F–B–S+R) cut that is non‑dominated against candidate families including explicit information/data, assurance/safety, and mission/context viewpoints under the N/U/C/D axes (C.18, G.0). Part G records the SoTA candidate set and rejected alternatives; TEVB only fixes the core four where each VP.* : U.Viewpoint is defined below. These four are the only viewpoints in the core TEVB bundle.

Note. Other ViewFamilyId values used in E.TGA (e.g., Assurance‑Oriented, Interoperability‑Oriented, Information/Data‑Oriented, Operational/Deployment, Mission/Context) remain lexical families only for transduction species (E.18:5.12). They do not add viewpoints to TEVB; they are orthogonal to TEVB’s viewpoints set.

#TEVB engineering viewpoints

Each TEVB viewpoint is a U.Viewpoint with:

• viewpointId : ViewpointId (concrete identifier, e.g., VP.Functional);
• EoIClassSpec inherited from the bundle (U.Holon with System/Episteme kinds);
• StakeholderFamilies : FinSet(RoleEnactorFamilyId) — families of U.RoleEnactor that are the primary audience;
• Concerns : FinSet(ConcernId) — engineering concerns this viewpoint foregrounds;
• AllowedEpistemeKinds : FinSet(U.EpistemeKindRef) — description/spec kinds admissible under this viewpoint (all obeying I/D/S discipline and C.2.1 slot discipline);
• ConformanceRules : FinSet(RuleId) — references to checklist items in conformance packs (CV/GF/engineering checklists).

The subsections below fix the normative intent and minimal field profiles for each TEVB viewpoint. Species patterns and discipline‑packs may refine Concerns, AllowedEpistemeKinds and ConformanceRules, but MUST preserve the intent.

#VP.Functional — capability & transduction viewpoint

Intent. Look at a holon in terms of what it can do under roles: capabilities, transductions, and functional responsibilities, rather than in terms of modules or procedures.

• viewpointId.

  VP.Functional : ViewpointId  // EngineeringVPId

• EoIClassSpec. Same as the bundle: U.Holon with System/Episteme kinds.

• StakeholderFamilies (typical examples). Actual StakeholderFamilies : FinSet(U.RoleEnactor) values are defined in RoleEnactment discipline packs; labels below are informal.

  • System engineering leads and architects (e.g. SysEng‑lead enactors).
  • Product owners / capability owners.
  • Reliability / performance engineers when reading capability envelopes.

• Concerns (typical).

  • Capabilities and functions provided by the holon (CapabilityConcerns).
  • Behaviour under roles (RoleBehaviourConcerns).
  • Non‑functional envelopes: throughput, latency, availability, energy, safety (NFPEnvelopeConcerns).
  • Compositional semantics of functions/transductions (TransductionCompositionConcerns).

• AllowedEpistemeKinds (shape). VP.Functional admits descriptions/specifications whose DescribedEntitySlot is a holon’s capability/Method/Mechanism under a role, e.g.:

  • SystemFunctionalDescription, SystemFunctionalSpec (species of U.EpistemeKind describing system‑level capabilities and their interconnection).
  • TransductionDescription, TransductionSpec (E.TGA functional lanes).
  • ServiceCapabilityDescription, ServiceCapabilitySpec (when a holon is in Service role).

  All such epistemes MUST:

  • obey I/D/S discipline: …Description/…Spec as D/S‑layers for U.Method/U.Mechanism/U.PromiseContent;
  • make their DescriptionContext = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩ explicit, with ViewpointRef = VP.Functional.

• ConformanceRules (examples).

  • Functional flows are total over their declared domain (no implicit dangling capabilities).
  • Transductions are typed at interfaces (A.6.0, A.6.1) and respect A.6.2/A.6.3 purity/conservativity.
  • When functional views participate in retargeting patterns (e.g. structural reinterpretation species based on U.EpistemicRetargeting), they MUST satisfy the relevant retargeting constraints from A.6.4; concrete consumer patterns (such as E.TGA structural reinterpretation, E.18) MAY impose additional rules.

• SoTA echo (informative). VP.Functional corresponds to the “functional view” in ISO‑aligned architecture descriptions and domain reference architectures (functional viewpoints in IoT and space reference architectures, functional/logical layers in sector frameworks), and to the Function axis in FBS‑style design ontologies. It is also the natural home for SysML/SysML‑v2 capability and logical architecture models and for “logical view” slices in 4+1‑style frameworks, once recast into holon/capability terms.

#VP.Procedural — process & control viewpoint

Intent. Look at a holon in terms of how behaviours are sequenced and controlled: workflows, state machines, operational procedures, and control logic.

• viewpointId.

  VP.Procedural : ViewpointId  // EngineeringVPId

• EoIClassSpec.

  Same as the bundle.

• StakeholderFamilies (typical).

  • Operations and run‑time owners (OperationsEnactorFamily).
  • Control engineers and automation specialists (ControlEngineerEnactorFamily).
  • Safety engineers concerned with procedural correctness (SafetyEngineerEnactorFamily).

• Concerns (typical).

  • Control flow and ordering of actions (OrderConcerns).
  • State‑machine behaviour and lifecycle (StateLifecycleConcerns).
  • Concurrency, synchronisation, and error handling (ConcurrencyConcerns).
  • Operational modes and transitions (startup, shutdown, degraded modes) (OperationalModeConcerns).

• AllowedEpistemeKinds (shape). VP.Procedural admits descriptions/specifications where the DescribedEntitySlot is a method/process/control Behaviour for the holon, e.g.:

  • MethodDescription, MethodSpec for operational procedures (A.3.1–A.3.2).
  • ControlLogicDescription, ControlLogicSpec (IEC 61131‑3 style step diagrams/statecharts).
  • WorkflowDescription, WorkflowSpec (business processes, orchestration logic).

  These epistemes:

  • must respect the order discipline (Γ_method, Γ_ctx) and A.15 (Role–Method–Work alignment);
  • must carry I/D/S‑conformant DescriptionContext with ViewpointRef = VP.Procedural.

• ConformanceRules (examples).

  • Pre/post‑conditions at step boundaries are explicit and type‑checked (A.3.1/A.3.2, Γ_method).
  • No embedding of Work or calendars inside procedural descriptions (A.7/E.10.D2).
  • Failure modes and recovery actions are declared and traceable to safety analyses (F.15 harnesses where relevant).

• SoTA echo (informative). VP.Procedural captures the dynamic/process dimension found in SoTA architecture and MBSE practice: process views in 4+1, operational/behavioural views in defence and enterprise frameworks, behaviour diagrams in SysML (activity, sequence, state, interaction), and procedure/control‑oriented models in industrial standards. TEVB abstracts this into a notation‑agnostic “behaviour over time” viewpoint for holons.

#VP.RoleEnactor — role & device‑structure viewpoint

Intent. Look at a holon in terms of who/what plays which roles and how physical/organisational structure supports those roles. This viewpoint covers both socio‑technical role assignments and “device view” readings of transduction graphs (E.TGA).

• viewpointId.

  VP.RoleEnactor : ViewpointId  // EngineeringVPId

• EoIClassSpec.

  Same as the bundle.

• StakeholderFamilies (typical).

  • Organisational designers and operations managers (OrgDesignEnactorFamily).
  • Safety and compliance officers concerned with separation of duties (SegregationOfDutyEnactorFamily).
  • Hardware/system engineers concerned with which devices carry which functions (DeviceEngineerEnactorFamily).

• Concerns (typical).

  • Which holons enact which roles under which contexts (RoleEnactmentConcerns).
  • Allocation of capabilities to devices/subsystems (CapabilityAllocationConcerns).
  • Organisational constraints: segregation of duties, responsibilities, escalation paths (GovernanceConcerns).
  • Device‑view readings of functional graphs (E.TGA Device‑View).

• AllowedEpistemeKinds (shape). VP.RoleEnactor admits descriptions/specifications where the DescribedEntitySlot is a role structure or capability allocation associated with the holon, e.g.:

  • RoleDescription, RoleSpec (F.4, F.18) for human or system roles.
  • RoleEnactmentDescription for mappings Holder#Role:Context (A.15).
  • DeviceAllocationDescription mapping functions/transductions to physical modules or devices.

  As with other TEVB viewpoints, these are D/S‑epistemes with DescriptionContext.ViewpointRef = VP.RoleEnactor.

• ConformanceRules (examples).

  • Role vs Method vs Work vs Capability separation is upheld (A.7, A.15).
  • Device‑view reinterpretation from functional flows MUST be expressed as U.EpistemicRetargeting with an explicit KindBridge witness (A.6.4). Specific retargeting schemes (for example, E.TGA’s structural reinterpretation in E.18) may add further constraints but are not fixed by TEVB itself.
  • No “role as behaviour” conflation: Roles are masks, behaviours remain Methods/Work.

• SoTA echo (informative). VP.RoleEnactor aligns with the allocation/responsibility and resource/organisational view clusters seen across MBSE frameworks: allocation views in UAF/NAF, role‑responsibility matrices and RACI‑style artefacts, and “who/what plays which role” slices in usage and operational viewpoints. Many post‑2015 reference architectures treat this axis implicitly; TEVB makes it explicit and holon‑centred while remaining compatible with socio‑technical and device‑allocation practices.

#VP.ModuleInterface — module & interface viewpoint

Intent. Look at a holon in terms of its modules, interfaces, and structural composition: what parts exist, how they connect, and how their contracts are specified.

• viewpointId.

  VP.ModuleInterface : ViewpointId  // EngineeringVPId

• EoIClassSpec. Same as the bundle.

• StakeholderFamilies (typical).

  • Hardware and software architects responsible for structure (StructureArchitectEnactorFamily).
  • Integration and test engineers (IntegrationEngineerEnactorFamily).
  • Lifecycle and maintenance planners looking at replaceable units (MaintenancePlannerEnactorFamily).

• Concerns (typical).

  • Module decomposition and containment (mereology) (ModuleMereologyConcerns).
  • Interfaces and contracts — ports, APIs, physical connectors (InterfaceConcerns).
  • Dependency structures and allowed couplings (DependencyConcerns).
  • Replaceability and variation points (VariabilityConcerns).

• AllowedEpistemeKinds (shape). VP.ModuleInterface admits descriptions/specifications where the DescribedEntitySlot is a structural architecture of the holon, e.g.:

  • SystemStructureDescription, SystemStructureSpec (module/connector descriptions).
  • ModuleInterfaceDescription, ModuleInterfaceSpec (signature, contracts, physical interface definitions).
  • E.TGA‑style interface/port descriptions over Signature/Mechanism graphs.

  These epistemes describe the carrier (structure) rather than capability. Functional↔physical reinterpretations between VP.Functional and VP.ModuleInterface are expressed via U.EpistemicRetargeting + KindBridge (A.6.4, E.18).

• ConformanceRules (examples).

  • Interfaces are typed and explicitly bound to standards where applicable (A.6.0, F‑specs).
  • No inlining of Methods/Work into structure (strict separation of structure vs behaviour).
  • Reinterpretations from functional views into structure MUST respect the applicable U.EpistemicRetargeting/Bridge constraints (A.6.4). When combined with a concrete retargeting scheme (e.g. E.TGA structural retargeting, CC‑TGA‑06‑EX), that scheme’s additional rules also apply.

• SoTA echo (informative). VP.ModuleInterface matches the structural/implementation/deployment families that dominate SoTA architecture descriptions: development and physical views in 4+1, construction/deployment viewpoints in IoT reference architectures, logical/physical architecture layers in UAF/NAF and RASDS‑style frameworks, and structural and interface‑focused models in SysML‑based MBSE. TEVB treats all of these as specialisations of a single holonic “modules and interfaces” viewpoint.

#Archetypal grounding (informative)

A minimal TEVB instantiation looks as follows:

TEVB.EngBundle :
  U.ViewpointBundle {
    viewFamilyId   = VF.TEVB.ENG
    EoIClassSpec   = { h : U.Holon | HolonKind(h) ∈ {System, Episteme} }
    viewpoints     = { VP.Functional, VP.Procedural, VP.RoleEnactor, VP.ModuleInterface }
    LibraryRef     = FPF.Core.Viewpoints
  }

Each VP.* viewpoint is a U.Viewpoint as in E.17.0, with:

• viewpointId ∈ {VP.Functional, VP.Procedural, VP.RoleEnactor, VP.ModuleInterface},
• EoIClassSpec inherited from TEVB.EngBundle,
• StakeholderFamilies, Concerns, AllowedEpistemeKinds, ConformanceRules aligned with the subsections above.

Engineering holon (example).

Let Plant_X : U.System be a production plant, and ControlStack_X : U.Episteme be its control and optimisation stack as a holon.

• Under VP.Functional, Plant_X is viewed as a bundle of capabilities and transductions: material/energy/product flows, optimisation functions, safety envelopes.
• Under VP.Procedural, Plant_X is viewed as sets of procedures and control sequences: startup/shutdown, normal operation, emergency handling.
• Under VP.RoleEnactor, Plant_X is viewed as networks of role‑enactors: human operators, controllers, subsystems enacting roles in SOPs and safety cases.
• Under VP.ModuleInterface, Plant_X is viewed as modules and interfaces: equipment units, pipelines, control modules, buses, and their interfaces/contracts.

Each of these is a family of D/S‑epistemes with DescriptionContext = ⟨DescribedEntityRef(Plant_X or ControlStack_X), BoundedContextRef, ViewpointRef=VP.*⟩ and TEVB ensures that E.TGA and MVPK can rely on this common structure.

#Conformance checklist (normative)

CC‑TEVB‑1 (Bundle identity). Any artefact claiming to be “TEVB engineering viewpoints” MUST:

• refer to viewFamilyId = VF.TEVB.ENG,
• have EoIClassSpec = {h : U.Holon | HolonKind(h) ∈ {System, Episteme}},
• enumerate viewpoints = {VP.Functional, VP.Procedural, VP.RoleEnactor, VP.ModuleInterface} and no others.

CC‑TEVB‑2 (Viewpoint definition). Each VP.* viewpoint MUST be a well‑formed U.Viewpoint per E.17.0:

• viewpointId equal to one of the four engineering IDs,
• EoIClassSpec equal to the bundle’s,
• StakeholderFamilies, Concerns, AllowedEpistemeKinds, ConformanceRules explicitly declared.

CC‑TEVB‑3 (DescriptionContext completeness). Every D/S‑episteme participating in a TEVB‑managed multi‑view family for a holon MUST have a DescriptionContext = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩ with:

• DescribedEntityRef referencing a U.System or U.Episteme,
• ViewpointRef ∈ {VP.Functional, VP.Procedural, VP.RoleEnactor, VP.ModuleInterface},
• BoundedContextRef pointing to the engineering context (E.10.D1).

CC‑TEVB‑4 (Separation from PublicationVPs). VP.* identifiers from TEVB MUST NOT be used as PublicationVPId in MVPK. Publication viewpoints live in MVPK and may correspond to TEVB engineering viewpoints via CorrespondenceModel, but are separate symbols.

CC‑TEVB‑5 (No Role coordinate in I/D/S). TEVB‑aligned descriptions/specs MAY reference U.RoleEnactor families in StakeholderFamilies but SHALL NOT add Role or RoleEnactor as axes in I/D/S signatures beyond what A.7/E.10.D2 already provides. Role semantics stay in RoleEnactment patterns; TEVB just selects concerns.

CC‑TEVB‑6 (Alignment with consumer viewpoint maps). When a pattern defines engineering viewpoint families named “Functional”, “Procedural”, “Role‑Enactor (Device‑Structure)”, or “Module‑Interface” over the same EoIClass and claims TEVB alignment (for example, E.TGA E.18:5.12 viewpoint map), it MUST bind them to TEVB viewpoints as follows:

• “Functional” → VP.Functional,
• “Procedural” → VP.Procedural,
• “Role‑Enactor (Device‑Structure)” → VP.RoleEnactor,
• “Module‑Interface” → VP.ModuleInterface.

Any deviation MUST be explicitly documented as a species‑level extension and MUST NOT reuse VF.TEVB.ENG.

#Rationale & SoTA echoing (informative)

#NQD‑grounded choice of the core four

Part G’s NQD discipline treats candidate viewpoint families as points in an N/U/C/D quality space (Use‑Value, Constraint‑Fit, Novelty, Diversity_P). Applied to a SoTA‑harvested candidate set of engineering viewpoints (Functional, Behavioural/Procedural, Structural/Module, Allocation/Role, Information/Data, Assurance/Safety, Mission/Context, Deployment/Operational, Business/Usage), this yields a small Pareto frontier for engineering holon viewpoints. On that frontier, the F–B–S+R cut implemented by {VP.Functional, VP.Procedural, VP.RoleEnactor, VP.ModuleInterface} is the minimal set that:

• spans the Function–Behaviour–Structure ontology used in contemporary design theory while adding an explicit allocation/responsibility axis;
• aligns with the “functional/process/structural/deployment” clusters recurrent in standards and architecture frameworks;
• stays neutral with respect to domain‑specific qualities (‑ilities) and business/mission framing, which are captured in separate Q‑Bundles and governance-oriented viewpoint bundles rather than in TEVB itself.

Other candidates (e.g. dedicated information, assurance, or mission viewpoints) remain important but either duplicate concerns already captured by TEVB (when specialised to engineering holons) or are better modelled as orthogonal quality bundles (C.25) or non-engineering viewpoint bundles (business and governance viewpoint bundles). TEVB therefore pins only the core four and leaves the rest to specialised families.

#Alignment with post‑2015 engineering practice

• Modern architecture standards built on ISO/IEC/IEEE 42010 describe viewpoint libraries in which functional, behavioural/process, structural/deployment, and business/usage concerns are the dominant clusters; sector RAs such as IoT RA 30141 and space‑domain RAs provide explicit functional and construction/implementation viewpoints alongside business/usage and trustworthiness viewpoints. TEVB reuses the functional and construction/structural clusters as VP.Functional and VP.ModuleInterface, while treating business and trustworthiness as separate bundles.
• Model‑based systems engineering practice (INCOSE MBSE guidance, SysML v2 “views‑as‑queries”, UAF/NAF view grids) converges on a small set of core diagram families: structure vs behaviour vs allocation/responsibility vs requirements/mission. TEVB’s VP.Procedural and VP.RoleEnactor correspond to the behaviour and allocation/responsibility axes, respectively, and are designed to be notation‑neutral over SysML/UAF/UML/Capella‑style models.
• The FBS family of design ontologies (Function–Behaviour–Structure and extensions) provides a widely used conceptual basis for separating what a system is for, what it does over time, and what it consists of. TEVB’s four viewpoints intentionally implement an FBS+R split at the holon level: VP.Functional ≈ Function, VP.Procedural ≈ Behaviour, VP.ModuleInterface ≈ Structure, with VP.RoleEnactor capturing the explicit mapping from functions/behaviours to role‑enacting carriers.
• Within FPF itself, E.TGA’s “viewpoint families” (Functional, Procedural, Role‑Enactor/Device‑Structure, Module‑Interface, plus assurance/interoperability/data/operational/mission aliases) are harmonised by letting the core four be TEVB viewpoints and treating the rest as lexical or bundle‑level overlays, not as new kernel viewpoints.

#Why TEVB stays small

TEVB is deliberately not a complete architecture framework. It gives FPF a stable, holon‑centred engineering bundle that:

• is small enough to keep in working memory and to govern via EpistemeSlotGraph discipline;
• is expressive enough to host mappings from SoTA architecture frameworks (4+1, domain‑specific RAs, UAF/NAF grids, SysML‑based MBSE method kits);
• can be safely combined with additional U.ViewpointBundle species (safety/assurance packs, business/mission packs, information/data packs) without mutating the core four;
• sits conceptually below architecture‑specific viewpoint libraries, which are introduced as separate U.ViewpointBundle species layering TEVB with mission/quality/business viewpoints instead of redefining TEVB.

As SoTA evolves, new bundles can be added or TEVB can gain a new edition with a revised NQD‑frontier, but the TEVB‑A edition fixed here remains the archetypal engineering bundle for holons.

#Relations (informative)

• Builds on. E.17.0 (U.MultiViewDescribing), E.17.1 (U.ViewpointBundleLibrary), A.7/E.10.D2 (I/D/S), C.2.1 (EpistemeSlotGraph), A.6.2–A.6.4 (episteme morphisms).
• Constrains. E.18:5.12 (E.TGA viewpoint map), engineering description/spec patterns, MVPK engineering publication profiles.
• Coordinates with. L‑SURF/L‑PUBSURF (Surface kinds), F‑R family (Role, RoleDescription, RoleSpec), F.18 (naming discipline for ViewFamilyId / ViewpointId / EngineeringVPId / PublicationVPId).
• Non‑goals. TEVB does not prescribe modelling notations (SysML, BPMN, IEC 61131‑3, etc.), storage formats, or tool APIs. It only fixes the conceptual viewpoint bundle that such tools must respect when claiming FPF alignment.

#E.17.2:End