E.17.2:4.2 - 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:

identify the exact target kind and the complete self-contained P ClaimGraph;
apply the five E.17.0 viewpoint-membership conditions;
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;
bind the resulting exact P to its project-local reader designator and exact U.ViewpointRef; and
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:

Template position	Exact concern subjects and applicable claim-specific patterns
functional	exact `U.Transformation` under A.3.4; the independently identified holder System, with its qualified ability stated in the concern episteme under A.2.2; exact transformation-flow `U.Structure` under E.18 and A.22
procedural	exact `U.Method` under A.3.1; exact transformation-flow `U.Structure` under E.18 and A.22; exact operational-state `U.Structure` under A.19.SPR and A.22
allocation-responsibility	exact local system-role kind under A.2; when the view claims that one exact System counts under that kind, the separate C.3.2 judgment over candidate, kind, exact `KindSignature` edition, and context slice; an optional `KindExtension` representation only for a named set-consuming use; exact obtaining assignment occurrence under a directly declared `U.SystemRoleAssignment` species when an assignment claim is current; exact `SystemRoleKindRelationStructure` under A.2.7 and A.22; the independently identified holder System, with its qualified ability stated in the concern episteme under A.2.2; exact `U.Transformation` under A.3.4; an independently governed responsibility relation or selected structure when responsibility is current
module-interface	exact dependency `U.Structure` under B.1.1 and A.22; every module, interface, boundary, substitutability, or change-policy relation separately names its predicate, participants, obtaining test, and applicable pattern

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. A concern episteme about a Transformation, a holder’s ability or a transformation-flow Structure has respectively that exact Transformation, holder System or Structure as EntityOfConcern. State the ability in its claim content; select an ability-assertion episteme itself as subject only for a question about that assertion. When several of these concerns are needed, keep their subject accounts distinct. 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.

Exact project substrate after binding	Applied constraints, selected structure, and viewpoint episteme	Selected direct dependencies	Method and work boundary
`C_functional = {E_target.tevbHolon, E_admitted.tevbEpisteme, E_concern.functionalTransformation, E_concern.capability, E_concern.transformationFlowStructure, E_rule.functionalCoverage, E_rule.functionalModuleSeparation, E_rule.functionalRetargeting}`	`Q_org.functional` is an ordinary constraint episteme about C. A.22 selects `S_functional`; exact project `P_functional` has `EntityOfConcern=S_functional`, is assigned local reader designator `d_functional`, and passes E.17.0 viewpoint membership before `r_functional` is bound to it.	Each concern episteme depends on `E_target.tevbHolon`; `E_rule.functionalCoverage` depends on all three concern epistemes and `E_admitted.tevbEpisteme`; separation depends on functional-transformation concern; retargeting depends on the target.	No method constituent is required. A method convention enters only as exact `U.MethodDescription` after its method passes A.3.1.
`C_procedural = {E_target.tevbHolon, E_admitted.tevbEpisteme, E_concern.method, E_concern.transformationFlowStructure, E_concern.operationalStateStructure, E_rule.proceduralCoverage, E_rule.proceduralMethodBoundary, E_rule.proceduralNoWorkInference}`	`Q_org.procedural` is about C. A.22 selects `S_procedural`; exact project `P_procedural` has `EntityOfConcern=S_procedural`, is assigned local reader designator `d_procedural`, and passes E.17.0 membership before `r_procedural` is bound.	Each concern episteme depends on the target; coverage depends on all concerns and admitted-episteme kind; method boundary depends on method concern; no-work-inference depends on method and transformation-flow concerns.	Operational methods remain subjects of separate method-description epistemes. Concern selection, view construction, evaluation, and use do not form one method or workflow by mention.
`C_allocation = {E_target.tevbHolon, E_admitted.tevbEpisteme, E_concern.systemRoleKind, E_concern.systemRoleKindRelationStructure, E_concern.capability, E_concern.transformation, E_concern.responsibility, E_rule.allocationCoverage, E_rule.allocationNoWorkInference, E_rule.allocationRetargeting}`; add `E_concern.systemRoleClassification` only for an independently current four-input C.3.2 judgment, and add `E_concern.systemRoleAssignment` only for an independently current assignment claim	`Q_org.allocation` is about C. Use A.22 to select `S_allocation`; exact project `P_allocation` has `EntityOfConcern=S_allocation`, is assigned local reader designator `d_allocation`, and passes E.17.0 membership before `r_allocation` is bound.	Each current concern episteme depends on the target; coverage depends on all current concerns and the admitted-episteme kind; no-work-inference depends on whichever kind, classification, assignment, transformation, and responsibility concerns are current; retargeting depends on the target.	A bare role label, raw kind or relation reference, and raw Method are not collection members. Only exact current concern epistemes enter C. An allocation or analysis Method enters only through an exact MethodDescription episteme.
`C_module = {E_target.tevbHolon, E_admitted.tevbEpisteme, E_concern.dependencyStructure, E_rule.moduleCoverage, E_rule.interfaceTyping, E_rule.functionalModuleSeparation, E_rule.substitutabilityChange, E_rule.moduleRetargeting}`	`Q_org.module` is about C. A.22 selects `S_module`; exact project `P_module` has `EntityOfConcern=S_module`, is assigned local reader designator `d_module`, and passes E.17.0 membership before `r_module` is bound.	Dependency-structure concern depends on the target; coverage depends on target, dependency structure, and admitted-episteme kind; typing, functional separation, and substitutability/change depend on dependency structure; retargeting depends on target and dependency structure.	No method, work, or module relation enters by mention. A direct module or interface relation joins only after its own pattern supplies participants, obtaining law, and occurrence identity.

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.