#TEVB — Project-local Typical Engineering Viewpoint Bundle Template for Holons

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

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Status: Stable authoring template; no TEVB catalogue value is shipped by this pattern.

Use this when. A project wants to author one small local family of engineering viewpoints for descriptions of holons, so that functional, procedural, allocation-responsibility, and module-interface claims remain distinguishable and comparable.

What goes wrong if missed. A functional, procedural, responsibility, structural, diagram, or report label starts doing several jobs at once: it is treated as the viewpoint, the view, the described holon, a publication face, or proof of an engineering relation. The opposite failure is to require all four viewpoints and their full authoring machinery for one local reading.

What this buys. TEVB supplies a four-position authoring template. Once a project has constituted its own catalogue L and bound four exact local references to four exact viewpoint epistemes, that project can reuse the resulting local family while keeping candidate episteme, described holon, conformance, cross-view relations, and publication separate. One use may select just one bound member.

First action. Resolve the already admitted project-local catalogue edition L and the local declaration designated by f_eng, then resolve only the U.ViewpointRef needed for the present question. If L or the declaration is new, missing, or disputed, use E.17.1:4.2 to constitute or verify <G_L, K_L, R_L> for that edition. If a needed P edition is missing, author and admit it under E.17.0 before binding its reference. Reuse those results while the catalogue edition, effective scheme, declaration, and relied-on premises remain unchanged.

First useful result. For materialization: one exact project-local L, ordinary family designator f_eng, four exact local references r_functional, r_procedural, r_allocation, and r_module, and four exact local P targets to which those references resolve under R_L. For later use: the admitted L and declaration, one needed reference resolving one exact P, and a readable E/P conformance judgment. Before the four bindings exist, the result is only an authoring template, not a reusable family value.

Ordinary stop. For materialization, stop when the exact local catalogue triple, declaration claim block, four reference bindings, and four exact P targets are recoverable. For later use, stop after resolving the admitted L and declaration, the one needed P, and its E/P judgment; reopen full catalogue constitution only under the E.17.1:4.2 triggers. Add another member, structured viewpoint-authoring witness, C.13/A.22 organization, construction history, cross-view relation, evaluation, or publication object only when a named receiving use depends on it.

Not this pattern when. Keep a one-off viewpoint local when no recurring four-position family is needed. Author another E.17.1 declaration for safety, assurance, information, mission, deployment, business, publication, or architecture-framework-specific concerns outside the four TEVB positions. TEVB is not a universal architecture framework.

Tech-name: TEVB — the template name, not a family designator or catalogue value Plain-name: project-local typical engineering viewpoint bundle template for holons

Product-form boundary. This pattern ships no exact catalogue edition, effective scheme, family designator, U.ViewpointRef, or viewpoint episteme edition. Every L, f_eng, r_*, P_*, C_*, Q_*, and S_* symbol below is a variable in the template until one project supplies and verifies its exact binding. Equal labels in two projects establish no shared family or cross-project reuse. Such reuse begins only when both uses resolve the same exact L and member references.

The template does not by itself constitute an architecture framework, a U.Method, a set of publication forms, or an additional entity alongside exact catalogue L and its referenced P editions. It prescribes no modelling notation, storage format, or tool API.

Builds on: E.17.0 for U.Viewpoint, EpistemeViewpointConformanceRelation, and U.View; E.17.1 for bundle packaging by U.ViewpointRef; C.2.1 for episteme identity; C.13 for the constituent collections of viewpoint conventions; A.22 for their selected structures; A.6.6 and E.17.0 for exact constituent-dependency relations; A.6.3 for optional view construction; E.24.PUB for publication.

Used by after a project materializes the bindings: E.18 transformation-flow descriptions, E.17 multi-view publication, architecture-description patterns, and domain patterns that need that exact local engineering concern family for holons.

Engineering descriptions repeatedly ask four different questions about one holon:

#Relations

#Content

#Problem frame

Engineering descriptions repeatedly ask four different questions about one holon:

1. Functional: what transformations, capabilities, and effects characterize what the holon can or is intended to do?
2. Procedural: what methods, orders, states, concurrency, failures, and recovery rules characterize how relevant behavior unfolds?
3. Allocation-responsibility: which admitted Systems, exact local system-role kinds, current C.3.2 judgments that one System counts under a kind for one KindSignature edition and context slice, obtaining assignments, capabilities, transformations, and separately governed responsibility relations or selected structures are related to the holon's behavior?
4. Module-interface: what constituent holons, interfaces, dependency structures, substitutability conditions, and change rules characterize its construction?

The questions recur across hardware, software, organizations, and mixed systems. Their answers may appear as prose, models, diagrams, cards, or publications, but those forms do not identify the viewpoints or make an episteme a view.

#Problem

How can engineers reuse a compact family of these four concern-bearing viewpoints while keeping all of the following distinct:

• the exact holon described by a candidate episteme;
• the exact viewpoint episteme and its exact target kind or, only in the triggered structured branch, its selected convention structure;
• the candidate episteme and any dependent U.View membership;
• a viewpoint selected for one describing use;
• the Methods, transformations, selected structures, local system-role kinds, assignments, modules, and interfaces mentioned in the claims;
• any viewing construction, evaluation, cross-view relation, publication occurrence, form, representation, or carrier?

Without that separation, a label such as functional view can stand indiscriminately for a concern convention, a diagram, a query output, a report section, or a claim about a system. The next engineering action then relies on the wrong object.

#Forces

#Solution

Local mantra. To materialize a local instance, constitute L and bind f_eng, four exact references, and four exact P targets. To use an admitted instance, resolve L, its declaration, and only the needed reference. Then identify holon-centered candidate E and test E.17.0 conformance. For any additional engineering or publication claim, keep its objects and relations distinct and use the applicable pattern.

The mantra is a recall aid. The following sections specify the template positions, local materialization, conformance use, and stopping rules; none of their variables denotes a repository-shipped value.

#Bind one project-local declaration without embedding viewpoint values

One project instantiates the template only by supplying these exact bindings:

L_local = catalogue episteme identified by <G_L, K_L, R_L>
f_eng   = ordinary family designator interpreted under R_L

local declaration claim block in G_L:
  familyDesignator = f_eng
  targetKindCompatibility = exact U.Holon target-kind criterion
  viewpointRefs = {
    r_functional,
    r_procedural,
    r_allocation,
    r_module
  }

resolve_R_L(r_functional) = P_functional
resolve_R_L(r_procedural) = P_procedural
resolve_R_L(r_allocation) = P_allocation
resolve_R_L(r_module) = P_module

The four r_* variables must be bound to exact local U.ViewpointRef values; the four P_* variables must be bound to exact already admitted viewpoint episteme editions. f_eng and any reader-facing names are ordinary designators under R_L. Designator, reference, viewpoint episteme, any optional selected viewpoint-convention structure, declaration claim block, and catalogue L remain distinct.

The template does not admit P as U.Viewpoint, make another episteme a U.View, or establish publication. Use E.17.0 for both dependent-kind membership tests, E.17.1 for L and its declaration claim block, and E.24.PUB for publication.

The four positions are fixed for a project declaration that claims conformance to this template. Safety, assurance, information, mission, deployment, business, and publication-oriented viewpoints use another local E.17.1 declaration or a later exact project catalogue edition with an explicitly revised declaration. A recurring label alone neither binds nor extends f_eng.

#Materialize each local viewpoint before binding its reference

Each P_* variable must be bound to one exact C.2.1 episteme that independently gains U.Viewpoint membership under E.17.0. Start with E.17.0's self-contained branch: give P its exact admitted target kind as EntityOfConcern and put the complete fixed target-kind, concern, admissibility, semantic-form, coverage, consistency, completeness, omission, and describing-use test in its ClaimGraph. Use the structured C/Q/S branch below only when separately versioned convention components and their organization change a named project reuse, comparison, or maintenance action.

For any one of the four positions:

1. identify the exact target kind and the complete self-contained P ClaimGraph;
2. apply the five E.17.0 viewpoint-membership conditions;
3. only in the independently triggered structured branch, identify exact convention epistemes under their least-powerful admitted kinds, construct exact collection C under C.13, recover every selected obtaining direct relation, state ordinary constraint episteme Q_org, let a system perform the A.22 selection work, and identify exact selected structure S;
4. bind the resulting exact P to its project-local reader designator and exact U.ViewpointRef; and
5. record the resolution under exact R_L in the local declaration claim block.

No constituent, Q_org, or P becomes a U.Signature merely to fit this template. A constituent is a U.MethodDescription only when it describes one independently admitted method under A.3.2. Exact selection work and its result remain separate from C, S, P, and selected relation occurrences. The structured-witness table below contains variables and optional recipes, not current repository values.

The four template positions use these exact concern objects and patterns when one project authors its P editions:

Keep these claim boundaries explicit:

• Functional: functioning status, input/output boundary, and functional-port coverage remain claims in E_rule.functionalCoverage unless the claim identifies a separate EntityOfConcern and states its exact predicate, participants, and obtaining test. The three concern epistemes stay separately about exact Transformation, exact Capability, and exact transformation-flow Structure; there is no universal function entity or one multi-subject concern episteme.
• Procedural: every method, order, state, concurrency, failure, and recovery claim designates its exact operational subject and the admitted method, state-transition, or transformation-flow relation that gives the claim meaning. A bounded coverage rule may remain in P, but a candidate E cannot satisfy it through vocabulary alone. Method mention grants no MethodDescription membership, state wording is not a Structure, procedural content is not performed work, and safety evidence is added only for a safety-bearing claim or named reliance.
• Allocation-responsibility: holder System, local system-role kind, four-input C.3.2 classification judgment, optional extension representation, assignment, transformer relation, allocation, segregation, capability, and responsibility remain separate typed claims or concern objects. A local system-role kind is not a classification judgment or assignment; classification or assignment establishes neither responsibility nor Work.
• Module-interface: A.6.M ModuleInterfaceClaim remains claim content. Whole-holon, candidate-module, boundary, independently identified InterfaceSpecification episteme and its resolving reference, substitutability, and change-policy content stays in the coverage-rule episteme until an exact module-relation declaration supplies participant kinds, predicate, obtaining rule, and occurrence identity and current facts satisfy it. The claim record is not that relation and a module topic is not an EntityOfConcern.

Split any phrase spanning several exact subjects into separate concern epistemes, or retain it as one constraint claim over candidate content. Give each stakeholder constituent exactly one referent—exact System, local system-role kind, claim-bearing C.3.2 classification-assertion episteme when that judgment is current, exact obtaining system-role assignment, C.13 collection-as-whole, or other independently governed subject. A KindExtension remains an optional representation for a named set-consuming use, not the kind or judgment. Cite any responsibility concern through its separately governed direct predicate. Do not coerce heterogeneous constituents into Signatures merely to make the rows uniform.

The following four rows are structured-branch recipes. Every symbol is a template variable until a project binds exact values; an ordinary self-contained P does not materialize this row.

Each project-bound structured witness remains independently recoverable. Exact constituent editions identify C; every selected dependency occurrence passes the E.17.0 predicate; optional D_dependencyUse states obtaining and named-use admissibility as separate claims; and A.22 selects S from exact C, selected occurrences, applied Q constraints, and the use frame. Exact P is then identified by its ClaimGraph, S EntityOfConcern, and effective scheme. Changing only the Q edition leaves S unchanged when those selection inputs remain semantically unchanged. No topic list, citation, displayed edge, hidden O, D, template variable, or neighboring witness supplies another witness's closure. The dependency relation in this table is exact ViewpointConventionDependencyRelation from E.17.0. It obtains only when interpreting or replaying the fixed claims of the dependent episteme relies on an exact criterion, law, public name, or method claim of the base episteme, and replacing the base edition can change that interpretation or replay. Co-membership, citation, or a visible arrow is insufficient.

When an A.22 selection judgment needs an explicit claim that one obtaining dependency occurrence is admissible for that use, identify the separate decision-use episteme described by E.17.0. Do not insert that decision, its evidence, or its evaluation result into the dependency relation or S identity.

#Keep the four concern conventions distinct

Functional. A conforming candidate episteme foregrounds exact transformations, capabilities, effects, functional elements, or transformation-flow relations of its holon. It does not identify a module structure by functional vocabulary and does not mint U.Function. Any neighboring responsibility claim keeps the admitted System, local system-role kind, current C.3.2 classification judgment, exact assignment, kind-relation structure, capability, transformation, and direct responsibility relation separate; use A.2, C.3.2, A.2.1, A.2.7, or the direct responsibility pattern for the claim actually made.

Procedural. A conforming candidate episteme foregrounds exact methods, order, state, concurrency, failure, and recovery related to its holon and designates the exact admitted method, state-transition, or transformation-flow relations on which each claim depends. A procedural view about a holon is not a U.MethodDescription; that dependent kind requires one admitted method as its exact EntityOfConcern. Ordinary operational recovery needs no safety package unless the claim is safety-bearing or a named receiving decision relies on one.

Allocation-responsibility. A conforming candidate episteme foregrounds exact Systems, local system-role kinds, current C.3.2 classification judgments, obtaining assignments, relations among those kinds, capabilities, transformations, and separately governed responsibility relations or selected structures related to its holon. A label creates no kind, classification, or assignment; a classification judgment needs its candidate, kind, KindSignature edition, and context slice but no assignment. The view may state that judgment, but it does not make the criterion true or create an assignment or responsibility relation.

Module-interface. A conforming candidate episteme foregrounds exact constituent holons, dependency structures, boundaries, interfaces, compatibility, substitutability, and change policy. It remains distinct from the functional viewpoint: many modules may support one transformation, one module may support several transformations, and either description may be incomplete without becoming the other.

The following are practitioner recognition and claim-shape cues, not embedded StakeholderFamilies or AllowedEpistemeKinds fields. A reader label creates neither a system-role classification nor an assignment and enters neither viewpoint nor view identity; every example still needs its exact EntityOfConcern, the predicate and participants of each claimed relation, its obtaining test, and its E.17.0 conformance result.

#Recognize holon-centered TEVB views by conformance

TEVB keeps two subjects explicit:

EpistemeViewpointConformanceRelation(E,P) must obtain under the fixed E.17.0 predicate. Only then is the same episteme E a U.View. Direct authoring, query execution, A.6.3 construction, a reader-facing label, declaration membership, or publication does not establish that membership. A reader-facing system-role label also establishes neither the local kind nor a C.3.2 classification judgment or assignment.

For one current describing use, its exact use qualification carries one singular viewpointRef : U.ViewpointRef resolving P under the effective reference scheme. Any reader-facing viewpoint name is only P's ordinary designator. The use qualification, designator, reference, and P remain distinct; selection identifies neither E nor H, establishes no conformance, and adds no conformance participant or episteme-identity field.

Recover exact H only as EntityOfConcern(E) from E's C.2.1 constitution. Do not import a legacy context tuple, generic bounded-context object, or model-use identity field into E, P, S, conformance, or selection. Another use may select another P while E remains unchanged; several selected viewpoints require an exact C.13 collection of their references rather than one overloaded reference. If a user needs a view whose exact subject is a Method, local system-role kind, system-role assignment, transformation, responsibility relation, or structure rather than H, identify another candidate episteme with that EntityOfConcern and use a viewpoint whose target-kind criterion admits it. Do not silently retarget a holon-centered TEVB view.

#Import, subset, and extend one materialized local instance

An E.17.0 multi-view use can import TEVB only after it resolves one admitted project catalogue edition L, retrieves the declaration claim block designated by exact local f_eng, and resolves the exact imported r_* members or subset. Open <G_L, K_L, R_L> under E.17.1:4.2 only when L or the declaration is new, missing, or disputed, or a named later use consumes the catalogue constitution as premises. f_eng is only an ordinary designator inside L: it identifies neither L nor any viewpoint by itself and is not a member reference. Each imported reference resolves exact P under R_L; any reader-facing viewpoint name is only P's designator. A local subset names retained references, preserves <editionDesignator(L), f_eng> provenance, and records whether each omission is unused coverage or an intentional exclusion.

If local work changes only reader-facing aliases or adds examples, keep those as naming or annex content. If it changes a viewpoint's target criterion, concerns, admitted episteme kinds, or conformance rules, identify another viewpoint episteme edition and bind another exact reference as needed. If it changes declared family membership, identify another catalogue episteme carrying the revised declaration claim block. Do not keep an old designator while changing the exact P it resolves under the same effective scheme.

Several local families may be used together, but each member retains its exact catalogue provenance and resolved viewpoint edition. Similar labels do not merge members. Two projects can claim use of the same reusable family only when they resolve the same exact L, declaration, and member references; independent instances of this template remain different local families even when all four labels match.

A project may bind its local four positions to reader names such as Functional, Procedural, Allocation-Responsibility, and Module-Interface. Those names do not perform the binding. A different reference-to-position mapping is another local declaration and must not silently reuse the earlier f_eng under R_L.

#Keep cross-view relations and publication separate

A materialized local TEVB instance provides four exact project references; the template alone provides none. Neither instance nor template asserts correspondence among resulting views. When a later engineering use depends on a relation between a functional claim and a module claim, or between a procedural claim and a system-role-assignment claim:

1. identify the exact participating entities or epistemes;
2. state the exact realization, allocation, dependency, consistency, trace, or other direct relation claimed;
3. use the concrete pattern that defines and tests that relation, including its obtaining law;
4. use A.6.RCD when no existing direct or derived relation is sufficient;
5. use C.29 only for a representation of the recovered relation.

If a separate receiving claim asserts dated U.Work, recover each exact actual performer through A.13 and use A.15.1 to establish the Work, Method, time, and containing System independently. Add F.6 only when that receiving claim also consumes precise assignment-bound attribution through the same obtaining A.13 assignment; missing or failed F.6 leaves the Work intact. Those Work and optional attribution facts are neither participants in the cross-view relation nor prerequisites for identifying it.

E.17 and E.24.PUB may publish a selected TEVB view edition through three distinct relations: PublicationFormExpressionRelation(selectedEdition,publicationForm,boundedUseDeclaration), PublicationFormBearingRelation(presentationCarrier,publicationForm), and the five-participant EpistemePublicationRelation(selectedEdition,audienceDeclaration,boundedUseDeclaration,publicationForm,presentationCarrier). Each retains its own participant set and maximal continuous obtaining interval; changing a participant or restoring availability after a gap yields another occurrence without reidentifying unchanged E or P.

Rendering, printing, upload, or carrier manipulation is separate system-performed U.Work. Use C.29 only when a representation corresponds to independently recovered objects or relations. A publication-side viewpoint, when current, is another exact viewpoint episteme selected by reference—not a TEVB position label reused as a form or file name. View episteme, viewpoint episteme, construction, conformance, form, carrier, publication, rendering, and representation remain distinct; publication and representation make no represented world-side relation obtain.

#Worked cases

The cases below assume one hypothetical project has already constituted exact L_local, bound f_eng, and resolved r_functional -> P_functional, r_procedural -> P_procedural, r_allocation -> P_allocation, and r_module -> P_module under exact R_L. They demonstrate a materialized local instance; they do not assert that these values exist in the repository or in another project.

#Four views of a processing plant

Exact plant Plant_X : U.System is the EntityOfConcern of four separately identified epistemes.

• E1 states transformations, capabilities, material-flow effects, and functional boundaries. r_functional resolves P_functional; E1 conforms to that P and is a functional U.View.
• E2 states claims about exact admitted method PlantOperation, exact A.19.SPR operational-state structure PlantRunState, and exact E.18 transformation-flow structure PlantRunFlow; its order, failure, and recovery claims designate the exact transition conditions and flow relations in those structures. It conforms to P_procedural; it is not a method description because its EntityOfConcern is the plant. No safety-bearing claim or named reliance is present in this case, so no safety-analysis, A.10, or B.3 branch is opened.
• E3 states that PumpUnit-3 counts as local kind CoolingCirculatorSystemRole in the plant slice through a separate C.3.2 judgment over the exact candidate, kind, KindSignature edition, and slice; that claim needs no assignment. E3 separately states any obtaining assignments, capabilities, transformations, and governed responsibility structures that are current. It conforms to P_allocation; neither E3 nor P_allocation makes the classification criterion true or creates an assignment or responsibility relation.
• E4 states constituent equipment holons, dependency structure, pipes, interfaces, substitutability, and change policy. It conforms to P_module; the diagram rendering E4 is published in remains separate.

The four conformance occurrences make E1-E4 views. Their shared holon and common local declaration do not establish any cross-view realization or consistency relation. Those claims are tested separately.

#Query output missing a required concern

A query constructs episteme Y from plant model X, and A.6.3 records that construction. Y is labelled functional view, but it omits the output-condition coverage required by exact P_functional. Construction obtains; conformance does not. Y is not a U.View under that P until another episteme edition with repaired claim content passes the predicate.

#Ordinary non-safety jam recovery

Candidate procedural episteme E_jamRecovery concerns exact conveyor system H. Its ClaimGraph designates exact admitted method ClearJam, an exact operational-state structure with Running, Blocked, and Resetting positions, the exact transition conditions between those positions, and the exact E.18 flow relation that resumes only after the blockage sensor is clear. These method, state, and flow facts supply the operational basis for its failure-and-recovery claims. If EpistemeViewpointConformanceRelation(E_jamRecovery,P_procedural) obtains, E_jamRecovery is a procedural U.View.

No claim in this case is safety-bearing, no receiving decision relies on a safety analysis, and no evidence or assurance result is requested. Therefore neither an A.10 evidence path nor a B.3 assurance branch is opened. A later actual clearing remains separately identified U.Work.

#Safety-triggered recovery use

Suppose a second claim says that restarting H after the same jam is safe for an exposed operator, and a named restart decision relies on that proposition. The project now identifies the exact safety-analysis episteme and its hazard, guard, and recovery claims; relates the relied-on evidence through A.10; and uses B.3 only when an actual named assurance claim for the restart use is current. If the applicable safety rule or restart decision requires assurance, state that claim, its exact target, and its named use before applying B.3. The operational method, state transitions, and flow relations remain the same exact operational basis; safety analysis and reliance are added because this claim and decision trigger them, not because every failure or recovery description requires assurance.

#Responsibility diagram and actual assignment

A responsibility-diagram episteme E concerns exact System H. Exact local reference r_allocation : U.ViewpointRef resolves exact P_allocation; EpistemeViewpointConformanceRelation(E,P_allocation) obtains.

Diagram cue. One box names MaintainerSystemRole@Plant. That spelling can help locate the plant-side definition; by itself it establishes neither an exact local system-role kind, an assigned-kind domain, a C.3.2 judgment, nor an assignment.

Classification-only claim. If a current claim says PumpUnit-3 counts as CoolingCirculatorSystemRole for exact CoolingCirculatorKindSignature-2 and PlantSlice-7, recover J(PumpUnit-3, CoolingCirculatorSystemRole, CoolingCirculatorKindSignature-2, PlantSlice-7) = true under C.3.2. No assignment is required.

Assignment claim. If a separate claim says admitted System S holds an assignment, first recover the exact local kind—here named MaintainerSystemRole—through C.3 and declare the exact assigned-kind domain—here named PlantMaintenanceSystemRoleKindDomain. The diagram cue identifies neither. Then recover exact RA : MaintenanceWorkAssignment <: U.SystemRoleAssignment under A.2.1, with S in HolderSystemSlot, PlantMaintenanceSystemRoleKindDomain as the declaration-local assigned-kind domain, and MaintainerSystemRole as RA's assigned-kind value.

E can assert or describe RA without becoming RA. Any responsibility of S remains a separately governed direct claim.

#One view, two publications

Module-interface view E is published as an interactive model and as a printed inspection sheet. Both publication occurrences select the same episteme edition. Their forms and carriers differ; E, its conformance occurrence, and its U.View membership do not.

#DDD Context Mapping method and product

A team enacts DDD Context Mapping. The way of doing is one independently admitted U.Method under A.3.1; an episteme that substantively describes that method may separately be a U.MethodDescription with the method as its exact EntityOfConcern. Neither is a TEVB viewpoint or view by its label.

First determine whether the product is a claim-bearing episteme or only a diagram, form, or carrier. A claim-bearing product called a Context Map is separately identified under C.2.1 as candidate episteme E with its own exact claim content, EntityOfConcern, and effective scheme. It becomes a U.View only if one exact viewpoint P admits E's EntityOfConcern and EpistemeViewpointConformanceRelation(E,P) obtains. Method enactment, product naming, diagram form, declaration position, publication, and visual resemblance grant no membership. If the map represents independently recovered domain regions or relations, C.29 defines that correspondence; a mere carrier remains with E.24.PUB, and the drawing makes no represented world-side relation obtain.

#Consequences

Reopen the TEVB template when its four positions no longer give a small useful engineering concern family for routine holon description. Reopen one materialized local instance when a bound P's exact target criterion or conformance rules change, or when a candidate concern cannot be expressed without changing a local binding. Author another local family instead when the concern is orthogonal rather than a replacement for the four.

#Provisional local design rationale and source status

The four TEVB positions are a provisional local authoring cut for routine holon description. They are retained because each changes a different immediate practitioner question and none is safely recoverable from another by label alone:

The cut is deliberately small, not claimed complete. Serious omitted branches remain visible rather than being forced into the four:

Source status. ISO 42010 is historical vocabulary lineage only. Function–behaviour–structure language is also lineage and a recognition aid, not evidence for this exact four-position cut. Query or projection production uses C.2.1 to identify the candidate episteme and A.6.3 to state its construction; it is not an external source for viewpoint selection. Responsibility/allocation is retained because it changes the practical question and avoids a recurrent function/actor collapse. SysML v2 is deliberately not used as positive evidence or lineage for this selection: official status, search prominence, systems-oriented naming, and prospective scope do not supply a demonstrated current solution to this exact reusable-family problem.

Reopen. Re-run source selection and a bounded actual-use comparison when an exact current problem-solving source or exercised project result supplies a better reusable family; when routine project replay repeatedly needs one omitted branch at the same frequency and action impact as the four; when two retained positions cease to change different actions; or when the four-position template produces more selection work than it saves. Until such evidence exists, call the cut provisional local rationale and never a computed frontier.

#Pattern contributions and boundaries

• E.17.2 provides the four-position project authoring template and its concern distinctions. It supplies no exact L, declaration, reference, P edition, or membership occurrence; a project materializes those objects through the patterns below.
• Use E.17.0 for U.Viewpoint and U.View membership, ViewpointConventionDependencyRelation, EpistemeViewpointConformanceRelation, and ordinary-use stops.
• Use E.17.1 for catalogue L, local family declarations, and packaging by exact viewpoint references; it admits no bundle U-kind.
• Use C.2.1 to identify every constituent episteme, Q, P, candidate E, assertion, and description.
• Use C.13 to construct exact collections and A.22 to select structures.
• Use A.6.3 only for optional source-to-receiving viewing construction; that construction does not grant view membership.
• Use A.3.1/A.3.2 for Methods and MethodDescriptions, A.3.4 for transformations, A.2 for local system-role kinds, C.3.2 for their KindSignature declarations, four-input classification judgments, and optional extensions, A.2.1 for exact U.SystemRoleAssignment species and occurrences, A.2.2 for capabilities, A.2.7 for relations among system-role kinds, the direct responsibility pattern for responsibility, E.18 for transformation flows, and B.1.1 plus applicable module or interface patterns for dependency, module, and interface relations.
• Use E.24.PUB for publication objects and relations and C.29 for representations of independently recovered objects or relations.
• Use A.6.RCD to state or derive a needed relation claim, or return its exact blocker, when current predicates are insufficient.

#Conformance checklist

1. The pattern is used as an authoring template until one project supplies exact <G_L, K_L, R_L>, ordinary f_eng, four exact r_* : U.ViewpointRef values, four exact P targets, and their resolution path; labels or variable names fill none of those positions.
2. Exact G_L contains one local declaration claim block with the four bound references; it is not an inferred bundle U-kind, separate bundle entity, embedded viewpoint value, view, document, form, carrier, or publication occurrence.
3. Each reader-facing viewpoint name is only the project-local designator of exact P; designator, reference, P, any structured-branch S, and declaration position remain distinct.
4. Each P passes all five E.17.0 viewpoint-membership conditions. It uses the self-contained branch by default; an exact C/Q/S witness is required only when separately versioned convention organization changes a named action.
5. In a triggered structured branch, each witness names exact least-powerful constituent editions, every selected obtaining dependency occurrence, ordinary Q_org, exact A.22-selected S, and ordinary P; optional dependency-use decisions and evaluations remain named-use neighbors.
6. Each concern episteme has one independently recoverable EntityOfConcern. Every relation claim names its exact predicate, participants, obtaining test, and applicable pattern; a multi-subject phrase is split or retained as a constraint claim, never promoted to a hidden group kind.
7. Candidate E has one exact holon H as EntityOfConcern and becomes U.View only through obtaining EpistemeViewpointConformanceRelation(E,P).
8. A singular describing-use reference selects P without entering E/P identity or conformance; A.6.3 construction, declaration membership, naming, evaluation, rendering, and publication grant no membership.
9. Every procedural failure or recovery claim has an exact operational subject and admitted Method, state-transition, or transformation-flow basis. A safety-analysis episteme or A.10 evidence path appears only for a safety-bearing claim or named reliance. Within that branch, use B.3 only when an actual named assurance claim for that use is current. Procedural views remain distinct from MethodDescriptions and Work; allocation-responsibility views keep the local system-role kind, any four-input C.3.2 classification judgment, optional extension, assignment, performer System, and responsibility relation distinct; module-interface views remain distinct from direct module relations or functional views.
10. DDD Context Mapping remains a U.Method; a product called Context Map is a separately identified episteme and becomes a View only through exact E/P conformance.
11. Every cross-view relation names its exact predicate, participants, obtaining test, and applicable pattern; a diagram edge, correspondence label, citation, shared holon, or common template is insufficient.
12. Form expression, carrier bearing, five-participant publication and recurrence, rendering work, C.29 representation, and any publication-side viewpoint remain distinct and make no represented world-side relation obtain.
13. Cross-project reuse is claimed only for the same resolved L, declaration, and exact member references. Equal TEVB position labels or independently filled templates establish no shared family.
14. Later ordinary reuse resolves the admitted L and declaration, then one needed P, and stops after the readable conformance judgment unless a named receiving work needs more structure. It reopens full catalogue constitution only under the E.17.1:4.2 triggers.

#E.17.2:End

Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)