Viewpoint and View Recognition for Multi-View Describing

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

At a glance. Use E.17.0 to decide whether one exact engineering account is a view under one already defined viewpoint, without mistaking its label, layout, generation history, bundle position, or publication for conformance.

Use this when. A description, model slice, query result, diagram, or other claim-bearing episteme is being called a functional, safety, maintenance, architecture, or other view, and the next reading, comparison, construction, or publication depends on whether that claim is warranted.

What goes wrong if missed. A viewpointRef, familiar face name, generated table, or readable diagram is accepted as a view without testing the viewpoint's concerns and rules. The opposite failure is to rebuild a viewpoint convention, bundle, evaluation package, and publication dossier before an ordinary reuse can proceed.

What this buys. One stable test works for directly authored and derived epistemes: identify exact candidate E, resolve exact viewpoint edition P, and test P's fixed conformance predicate without changing either episteme's identity.

First action. Recover candidate E through C.2.1, resolve an existing U.ViewpointRef to exact P, and read the target, concern-coverage, semantic-form, completeness, consistency, and admitted-omission rules fixed by P. Do not author a new viewpoint or bundle merely to perform this test.

First useful result. State one readable direct judgment: either episteme E conforms to viewpoint edition P, in which case the same E is a U.View, or E does not conform to P, naming the failed fixed rule without inventing a negative relation occurrence. Keep exact E and P recoverable. If missing identity or interpretation prevents the fixed predicate from being evaluated, report that exact unresolved condition rather than manufacturing a negative result.

Ordinary stop. If the next work needs only view recognition, stop after that judgment. Do not add an occurrence designator, explicit result ValueKind, evaluation package, source-viewing relation, correspondence model, collection or structure, publication occurrence, form, or carrier. Add one of those only when a named receiving use depends on it.

Tech-name: MultiViewDescribing Plain-name: recognizing viewpoints and views in multi-view describing

MultiViewDescribing names this pattern's method. It is not a public U-kind, a family record, or an extra entity beside the epistemes and relations recovered below.

Builds on: C.2.1 for episteme identity; C.13 for collections; A.22 for selected structures; A.6.5 for relation-signature participant SlotSpecs; A.6.3 for an optional source-to-view construction relation; E.10.D2 for Description epistemes and specification use; E.24.PUB for publication; C.29 for representations.

Used by: E.17 publication, E.17.1 viewpoint bundles, E.17.2 TEVB, E.18 transformation-flow descriptions, and domain patterns that compare several views.

An engineer may have several claim-bearing epistemes about one system, method, structure, work occurrence, or another exact entity. A functional description, safety description, maintenance description, and allocation description may serve different concerns. One episteme may also be constructed from another by a query or projection, rendered in several forms, published several times, or compared with another view.

Relations

E.17.0builds onMathematical Lens Use
E.17.0outline parentMulti‑View Publication Kit
E.17.0explicit referenceMathematical Lens Use
E.17.0explicit referenceMulti‑View Publication Kit
E.17.0explicit referenceTransformation Flow Structure
E.17.0explicit referenceUnified Term Sheet
E.17.0explicit referenceDecision Theory (Decsn-CAL)
E.17.0explicit referenceThe Agential Role & Agency Spectrum
E.17.0explicit referenceEvidence Graph Referring (C-4)
E.17.0explicit referenceEvidence Graph & Provenance Ledger
E.17.0explicit referenceTrust and Assurance Calculus
E.17.0explicit referenceAlignment and Bridge across Contexts
E.17.0explicit referenceSystem-Role Kinds and Assignments

Content

Problem frame

An engineer may have several claim-bearing epistemes about one system, method, structure, work occurrence, or another exact entity. A functional description, safety description, maintenance description, and allocation description may serve different concerns. One episteme may also be constructed from another by a query or projection, rendered in several forms, published several times, or compared with another view.

Those uses involve different objects and relations:

  1. the exact EntityOfConcern of each episteme;
  2. the episteme itself, identified under C.2.1;
  3. an exact U.Viewpoint episteme carrying fixed concerns and conformance rules;
  4. an obtaining EpistemeViewpointConformanceRelation occurrence;
  5. dependent U.View membership of the same episteme individual;
  6. an optional A.6.3 viewing relation recording how one episteme was constructed from another;
  7. an optional viewpoint selected for one current describing use when it changes what that use reads or checks or may conclude;
  8. exact correspondence relations and epistemes that assert or describe them;
  9. publication occurrences, forms, carriers, and representations.

The list is an orientation, not a form to fill. Ordinary positive recognition needs items 1 through 5; a negative test stops without an obtaining conformance occurrence or U.View membership. Construction, selection, correspondence, and publication stay outside unless the receiving use calls for them.

Problem

How can an engineer recognize and use views under explicit viewpoints while preserving exact episteme identity and direct relation semantics, without treating a selected viewpoint, a query result, a diagram, a family label, or a publication as what makes an episteme a view?

The common practical failure is not merely loose wording. The wrong object is used to justify the next action. A generated table is accepted as a view because it was generated; a published diagram is accepted because it is readable; a viewpointRef is treated as proof of conformance; or several documents are put in one package and called a multi-view model without recovering any cross-view relation.

Forces

ForceTension
Lightweight use vs inspectable assuranceMost uses need one readable conformance judgment; contested use needs exact participants, predicate, occurrence identity, evaluation, and warrant.
Stable kind membership vs changing useAn episteme can remain a view after a reading, project, publication, or selected-use episode ends.
Direct authoring vs derivationSome views are authored directly; others are constructed through a query or projection. Construction history must not define view membership.
Self-contained viewpoint vs reusable convention structureOne P can carry the complete fixed test; separate C/Q/S is useful only when convention components and their organization vary independently and change a named reuse, comparison, or maintenance action.
Several views vs one invented containerMulti-view work needs organization and correspondence, but a package, graph, or shared heading does not establish either.
Readable domain language vs ontological precisionPractitioners need functional view and safety view; load-bearing use still needs exact epistemes and direct relations.
Correspondence vs consistency repairA correspondence can obtain while later evaluation finds an inconsistency or while repair work is still pending.
View vs publicationA view can be unpublished, and one view can be published repeatedly through different forms and carriers.

Solution

Local mantra. Identify the candidate episteme. Resolve the exact existing viewpoint episteme. Test their fixed conformance predicate. If it obtains, recognize the same episteme as a view; if it fails, name the failed rule and stop or repair. Add construction, selection, correspondence, evaluation, or publication only for the current use.

The mantra is a recall aid. Sections 4.1 through 4.11 supply the object distinctions, obtaining rules, and stopping conditions.

Identify the candidate episteme before calling it a view

Recover candidate E : U.Episteme through C.2.1:

  • exact claim content;
  • exact EntityOfConcern T;
  • effective U.ReferenceScheme.

These three discriminators identify E. A layout, file, query run, viewpointRef, selected project context, publication form, or carrier does not add another episteme identity discriminator.

If the current thing is only a diagram element, graph node, form, or carrier, recover that object under C.29 or E.24.PUB first. Do not promote it to an episteme or view by appearance.

Resolve one exact viewpoint episteme

U.Viewpoint is a same-individual dependent durable kind under U.Episteme. One exact viewpoint P is the same individual as a C.2.1 episteme.

P has one truthful C.2.1 EntityOfConcern. In the ordinary self-contained branch it is the exact independently admitted durable or local target kind whose membership criterion P uses. For a local kind, recover which candidates it can classify, what intended members must satisfy, what separates relevant non-members, and when a changed declaration still describes the same kind. A practice or source boundary helps find and compare that membership rule; it does not decide kind identity. Only when separately versioned convention components and their organization change a named reuse, comparison, or maintenance action is P instead about exact selected S_viewpoint : U.Structure. Neither branch introduces a new public kind or organization record.

Existing-P route. Resolve one current U.ViewpointRef to exact P and inspect P's fixed target criterion, admitted kinds, concern coverage, semantic-form, completeness, consistency, and omission rules. Do not reconstruct P's constituent collection or authoring history merely to use the already admitted edition.

Run the ordinary E/P route contiguously

  1. Identify exact candidate episteme E under C.2.1.
  2. Resolve the existing exact viewpoint edition P and its fixed rules.
  3. Apply the five-condition test in §4.4 to fixed <E,P>.
  4. State exactly one readable result: positive, negative with the failed fixed rule, or unresolved with the missing identity or interpretation.
  5. Stop unless a named receiving use triggers exact occurrence designation, warrant, new-viewpoint authoring, evaluation, selection, construction history, multi-view organization, or publication detail.

Test the direct conformance relation and state the result

EpistemeViewpointConformanceRelation is a direct species of U.Relation. Plainly: the episteme conforms to this exact viewpoint.

Its only two actual participants are independently identified before the test:

  • candidate episteme E : U.Episteme;
  • viewpoint episteme P : U.Viewpoint.

EpistemeViewpointConformanceRelation(E,P) obtains exactly when:

  1. E is one independently identified episteme and P is one independently admitted viewpoint episteme;
  2. exact T := EntityOfConcern(E) is recovered only from E's C.2.1 constitution;
  3. exact T satisfies P's fixed EntityOfConcernKindCriterion through the cited public durable-kind membership rule or the direct identity and membership rule of one exact independently admitted local kind; an exact C.3.2 KindSignature edition and one exact U.ContextSlice are separate test inputs only when P's local membership test needs them;
  4. E has at least one independently admitted episteme kind referenced by P's admitted-kind claims, excluding U.View and every kind whose membership depends on this same conformance; and
  5. E's fixed claim content, interpreted under its effective reference scheme, satisfies P's fixed concern-coverage and semantic-form rules, including each exact completeness rule and each admitted omission or loss condition named by P.

T is recovered from E, not guessed from a use qualifier, topic, P, label, reference spelling, or evaluator input, and it is not a hidden third participant. Changing T changes E. Changing P's target criterion, admitted target kind or cited membership rule, any exact KindSignature edition or U.ContextSlice named as a separate test input, admitted-kind claims, or conformance rules changes P.

State the result immediately after the five tests:

  • positive: all five conditions hold, so the pair-determined positive relation occurrence obtains and the same E is a U.View relative to exact P;
  • negative: at least one evaluable fixed condition fails; name that condition, do not mint a negative relation occurrence, and do not claim U.View membership through P;
  • unresolved: missing or ambiguous E identity, P identity, kind criterion, local sense, or interpretation prevents evaluation; name that exact missing condition and claim neither positive nor negative conformance.

Ordinary stopping rule. Stop with that readable result when the next work needs neither an exact occurrence designator nor warrant. Add an occurrence designator, assertion episteme, evaluation episteme or local result value, evidence path, work record, or decision-use episteme only for the named receiving need. A readable assertion is not occurrence identity, but neither is mandatory reification or evidence justified without a consumer.

For fixed E and P, one positive occurrence is participant-determined by <E,P>. Discovering, warranting, or using the judgment may involve a classifier, evaluation work, assertion, evidence path, result value, operational state, publication, audience, current use, or newly selected slice; none adds a participant or identity discriminator to the conformance occurrence. If conformance could change while E and P remain fixed because another current object changed, route that condition to a separately identified adequacy or evaluation claim or reopen the relation architecture.

Conformance covers E's semantic content relative to P's fixed convention claims. Truth about T, decision fitness, stakeholder satisfaction, evidence-backed adequacy, publication usefulness, and operational usefulness remain separate evaluations. Evaluation never makes the direct predicate obtain or produces another occurrence for the same fixed pair.

Exact declaration and public designation of conformance

EpistemeViewpointConformanceRelationSignature is a separate RelationSignature episteme about the direct kind and declares exactly:

SlotSpecValueKindRefKind
CandidateEpistemeSlotU.EpistemeU.EpistemeRef
ViewpointEpistemeSlotU.ViewpointU.ViewpointRef

The declaration, SlotSpecs, references, and relation-participant designations alone do not establish that the relation obtains. Its positive occurrence is identified by the actual E/P pair under the fixed predicate. P remains the ordinary episteme about its exact C.2.1 EntityOfConcern; P is not this signature.

The complete F.18 NameCard for the direct conformance kind is below. Its public-row fields point to the current F.17 result rather than paraphrasing that result's scheme or local sense:

FieldExact value or rule
NameCardIdNameCard.EpistemeViewpointConformanceRelation.FPFPublic; card identity only
GovernedValueRefexact direct kind EpistemeViewpointConformanceRelation, not a source line, card, signature, token, phrase, occurrence, or reference
GovernedValueKindRefU.Kind; this is the kind of the governed value, not another value reference
SubjectPatternLocatorE.17.0, locating the exact defining and occurrence-identity claims; F.18 separately constrains naming, A.6.5 declares SlotSpecs, and E.24.UK admits the dependent kinds
ReferenceSchemeexact by-value FPFCoreReferenceScheme
ClaimContentNameCard.EpistemeViewpointConformanceRelation.FPFPublic.ClaimGraph, constituted by all identity-bearing naming-settlement claims in this table
LocalSenseCellRefSenseCell.EpistemeViewpointConformanceRelation.FPFCore.2026-08-02
LocalSenseBasisRelationRefLocalSenseBasisRelation.EpistemeViewpointConformanceRelation.FPFCore.2026-08-02
TechLabelEpistemeViewpointConformanceRelation
PlainLabelthe episteme conforms to this exact viewpoint
CandidateSetselected label, EpistemeConformsToViewpointRelation, ViewpointConformanceRelation, ViewConformanceRelation, EpistemeViewpointGovernanceRelation, ViewpointGovernanceRelation, ViewMembershipRelation, viewpoint-to-description relation
RejectedCandidatesshorter conformance names hide a participant or assume view membership; governance collapses selection with semantic conformance; membership names the derived classification; the description placeholder narrows arbitrary episteme and omits the predicate. None is an alias.
SelectionRationalethe selected Tech label names both participant kinds and the obtaining predicate without presupposing that E is already a U.View
BridgeRefsnone; this naming settlement makes no semantic-correspondence or substitution claim
PublicRowStatuscurrent
UnifiedTermRowRefUTS.EpistemeViewpointConformanceRelation.FPFCore.2026-08-02
LineageEntriesthe selected name replaces viewpoint-to-description relation without admitting that placeholder as a synonym or second public designation
RefreshConditionreopen only when either participant kind, the conformance predicate, direct occurrence identity, exact scheme/cell/basis/row reference, or repeated reader evidence changes; not for spelling preference, one reaction, layout, repackaging, or unchanged semantics

The card, label, candidate list, and former placeholder are naming evidence only. None is relation admission, occurrence identity, or proof of obtaining.

Recognize the same episteme individual as U.View

An episteme is a U.View exactly when EpistemeViewpointConformanceRelation(E,P) obtains for at least one exact viewpoint P. This is same-individual dependent-kind membership of E under U.Episteme, not a second view individual, wrapper, form, carrier, result value, or identity discriminator.

One unchanged E may conform to zero, one, or several viewpoint editions through different pair-determined occurrences while remaining one episteme. Direct authoring and A.6.3 construction—including identity viewing—are separate histories: either may be present or absent, and neither grants membership. Selection, transformation, bundling, naming, rendering, publication, audience, or current use also grants none.

Membership survives the end of reading, selection, use, evaluation, bundle membership, or publication. P_old and P_new are different C.2.1 epistemes when they differ in fixed claims, effective scheme, or exact EntityOfConcern—the target kind in the self-contained branch or selected S in the structured branch; an obtaining EpistemeEditionRelation relates them but transfers no conformance. A current use may select P_new while unchanged E still conforms to P_old; adequacy and conformance for <E,P_new> are judged separately. If E's claim content, EntityOfConcern, or effective scheme changes, C.2.1 identifies another episteme and its membership is judged anew.

The stable gain is one U.Viewpoint extent spanning both a self-contained P about an exact target kind and the narrower P about an action-changing convention structure, plus one U.View extent spanning direct and derived construction without identity, use, or publication collapse. The ordinary cost is one exact P and the fixed E/P test; C/Q/S recovery and A.22 selection are paid only when separately versioned convention organization changes a named action.

Author or revise a reusable viewpoint only when existing P cannot serve

New-viewpoint authoring has two branches. Use one self-contained viewpoint episteme P by default. Open the convention-structure branch only when separately versioned convention components and their organization change reuse, comparison, maintenance, or another named action independently of P's fixed conformance claims.

Head-to-head task replay.

Smallest useful authoring taskSelf-contained PC/Q/S/A.22 branchAction-changing result
A maintenance lead needs a viewpoint for short pump-status descriptions: the candidate must concern an admitted Pump, state operating state and observation time, cite the source reading, and may omit maintenance history.One P about the exact admitted Pump kind carries those fixed concerns, allowed episteme kinds, completeness rule, admitted omission, and use frame. The lead can issue U.ViewpointRef(P) and immediately test candidate E.Splitting the same four rules into constituent epistemes, C, Q, selected relations, and S adds objects and selection work but changes no reuse, comparison, maintenance, or conformance action.No independently varying fact or receiving action exists; use self-contained P and do not create C, Q, S, or A.22 selection.
Several viewpoint editions deliberately reuse separately versioned measurement, reference-plane, and safety-terminology convention epistemes. A base-edition change must identify every dependent P requiring comparison or maintenance.Copying those conventions into each P hides shared edition dependence and makes change-impact comparison manual.Exact constituent editions, obtaining dependency relations, Q, and selected S make the shared organization and affected-P query recoverable.The independently varying base edition changes the maintenance and comparison action; this is a valid convention-structure trigger.

The first row sets the ordinary architecture. The second demonstrates the narrower case in which structure pays for itself. Formality, assurance, or the wish to make a diagram does not trigger the second branch.

Author the smallest self-contained viewpoint episteme

Identify the exact independently admitted target kind K_target that the candidate epistemes' EntitiesOfConcern must satisfy. For a local kind, recover its candidate domain, operative membership condition, intended member/non-member boundary, and continuity rule. Use a practice or source boundary only to find or compare that membership rule. Use an exact C.3.2 KindSignature edition and U.ContextSlice only as separate inputs when the membership test needs them. Constitute exact P under C.2.1 as <ClaimGraph(P), K_target, ReferenceScheme(P)>; the target kind is P's truthful exact EntityOfConcern because P states how epistemes about members of that kind are to be read. P's fixed ClaimGraph:

  1. states the exact target-kind criterion and cites its direct authority;
  2. names exact stakeholder or audience referents only when they change the concerns, and states the exact concerns;
  3. names the independently admitted episteme kinds allowed for candidate E;
  4. states fixed concern-coverage, semantic-form, completeness, consistency, omission, and conformance rules without circular use of U.View; and
  5. states the describing-use frame and fixed applicability qualifiers needed to interpret those rules.

The same episteme P is admitted as U.Viewpoint when those five claim-content conditions hold under its effective scheme. No parent U.Signature, C.13 collection, Q, selected S, A.22 work, organization record, or evaluation result is required. Changed P claim content, exact target-kind EntityOfConcern, or effective scheme identifies another P edition; packaging, publication, evaluation, representation, or current-use selection does not.

Add a viewpoint-convention structure only when it changes action

Use the structured branch only when at least two convention components remain independently identified or versioned and their obtaining dependencies or organization change a named reuse, comparison, maintenance, or joint-interpretation action. Mere decomposition, citation, co-membership, a graph, or future possibility is insufficient.

Construct C_viewpoint under C.13 from the exact constituent episteme editions. The collection may be heterogeneous: its invariant is exact constituent identity, not uniform declaration power. Give each constituent the least-powerful independently admitted kind that carries its actual claims.

ConstituentAdmit it whenExact subject and practical jobDo not collapse it with
E_targetA target-kind criterion is current.One C.2.1 episteme whose exact EntityOfConcern is the admitted target kind and whose claims cite the direct identity and membership rule. For a local target, those claims state which candidates it can classify, what intended members must satisfy, what separates relevant non-members, and when a changed declaration still describes the same kind. A practice or source boundary only helps find or compare that membership rule. An exact C.3.2 KindSignature edition and U.ContextSlice remain separate test inputs when the receiving membership judgment needs them. Use another U.Signature only when the criterion is itself a reused declaration with vocabulary, laws, and applicability.a raw kind reference, target mention as membership proof, a local KindSignature or ContextSlice substituted for the target kind, or a wrapper Signature around a local declaration
E_stakeholder.system[i]The concern names one stakeholder system.One C.2.1 episteme whose exact EntityOfConcern is the independently admitted exact U.System.system mention, stakeholder-family typing, a current system-role assignment, or the episteme substituted for the System
E_stakeholder.systemRoleKind[i]The concern addresses Systems classified under one exact local system-role kind.One C.2.1 episteme whose exact EntityOfConcern is that local U.Kind; its claims state which admitted Systems are candidates, what work-facing condition intended members must satisfy, what separates relevant non-members, and when a changed declaration still describes the same kind. A practice or source boundary only helps find or compare that membership rule. They may cite the current KindSignature edition and U.ContextSlice as separate classification-test inputs when the receiving use needs them. A reusable reference field ends in ...SystemRoleKindRef and is typed by U.KindRef. Classification judgments and actual assignments remain separate.bare role spelling, KindSignature, classification judgment, holder reference, assignment occurrence, or responsibility
E_stakeholder.systemRoleAssignment[i]One exact obtaining assignment occurrence changes the concern.One C.2.1 episteme whose exact EntityOfConcern is that occurrence under a directly declared species of U.SystemRoleAssignment. A reusable reference field ends in ...SystemRoleAssignmentRef and is typed by U.RelationRef constrained to U.SystemRoleAssignment.local kind, holder System, assertion or description of the assignment, assignment spelling, or responsibility
E_stakeholder.collection[i]Several exact Systems jointly form the concern referent.One C.2.1 episteme whose exact EntityOfConcern is the independently identified C.13 collection-as-whole.list adjacency, one System, local system-role kind or assignment, the member plurality, or a description substituted for the collection whole
E_stakeholder.localKind[i]The concern quantifies over one exact local kind.One C.2.1 episteme whose exact EntityOfConcern is the independently admitted local kind. Its claims state which candidates it can classify, what intended members must satisfy, what separates relevant non-members, and when a changed declaration still describes the same kind. A practice or source boundary only helps find or compare that membership rule. An exact C.3.2 KindSignature edition and U.ContextSlice remain separate inputs only when a classification judgment is current. If the concern later relates this kind to another exact local kind, ask the C.3.3 relation question separately.a wrapper Signature, raw class spelling, KindSignature or ContextSlice substituted for the kind, silent public-kind promotion, or a local extension treated as universal
E_concern[i]One exact question or concern claim is needed.Ordinarily one C.2.1 episteme about one independently identified entity. It states what a conforming episteme must address. Promote it to U.Signature only when the concern predicate itself is a reused declaration with vocabulary, laws, and applicability.a public U.Concern, unresolved EntityOfConcern, one-use question inflated into a Signature, or a concern label
E_admittedKind[i]One independently admitted episteme kind may enter conformance.One C.2.1 episteme that cites the exact kind and the rule that admits its members; an exact local KindSignature may itself be the constituent.a raw label or reference, admission by citation, a local wrapper, circular U.View admission, or the reference substituted for the membership rule
E_rule[i]A construction, interpretation, coverage, semantic-form, completeness, consistency, or omission constraint is current.Ordinarily one C.2.1 episteme stating the constraint about its exact EntityOfConcern. Use U.Signature only for genuinely reusable declaration content with vocabulary, laws, and applicability; use U.MethodDescription only when the claims describe one independently admitted method as a way of doing.every rule coerced to Signature, procedural appearance as method-description admission, missing exact subject, or one-use constraint inflated with declaration fields
D_method[i]A method-based convention is actually current.One A.3.2 U.MethodDescription whose exact EntityOfConcern M_method[i] independently passes A.3.1. The description supplies the convention; the raw method stays outside C_viewpoint.method mention as membership, raw method as constituent, several descriptions inferred to form one workflow, or description as performed work

Preserve every exact edition. A concern question, kind citation, or one-use rule acquires none of SubjectKind, RangedValueKind, Vocabulary, Laws, or Applicability merely to fit a common table. Conversely, a constituent that independently is a reusable relation declaration, kind declaration, or method description keeps that stronger admitted kind. Collection position grants no convention job and no stronger membership.

For this branch:

  1. identify the least-powerful exact constituents above;
  2. construct exact C_viewpoint from those editions under C.13;
  3. recover each selected direct relation occurrence using the pattern that defines its obtaining test and occurrence identity;
  4. identify ordinary constraint episteme Q_org about exact C_viewpoint and the admissible describing-use frame;
  5. have an exact system use the applicable A.22 selection method over C, selected obtaining occurrences, applied Q constraints, and the use frame, yielding exact S_viewpoint; and
  6. constitute P under C.2.1 with EntityOfConcern(P)=S_viewpoint and the same five fixed claim-content conditions from §4.6.1.

In this branch, changed P claim content, exact S, or effective scheme identifies another P edition. S itself is not U.Viewpoint; P is the claim-bearing individual. No viewpoint record, wrapper, organization object, context entity, bundle position, package ID, publication grouping, or parent U.Signature grants membership. When the action-changing trigger disappears, use or author self-contained P rather than preserving C/Q/S as ceremonial structure.

Keep explicit evaluation values optional

The fixed E17ViewpointSemanticsSlice@FPFEdition selects the exact FPF and E.17.0 declaration editions, effective U.ReferenceScheme, and Γ_time. In that slice the admission predicates defined here permit exactly two optional C.3.2 local ValueKinds, each carried by its own C.2.1 KindSignature episteme:

Local ValueKindExact extensionAdmit an explicit value only when
KS.ViewpointConformanceValue.E17, carrying KindSignature(ViewpointConformanceValue@E17)the two exact values designated conforms and doesNotConformseparately performed conformance-evaluation work emits the value and a named A.21 gate or C.11 comparison/selection decision consumes it
KS.ViewpointOrganizationSatisfactionValue.E17, carrying KindSignature(ViewpointOrganizationSatisfactionValue@E17)the two exact values designated satisfiesOrganization and doesNotSatisfyOrganizationseparately performed candidate-structure evaluation emits the value and a named C.11 comparison or selection decision consumes it

The four exact values remain distinct from their designators. Both kinds use F4 formality, deterministic exact-equality membership, no SubkindOf, and fail-closed definedness. Incomplete evidence or interpretation leaves the optional evaluation unsupported or undefined; it supplies neither a negative result nor a third unknown member.

Omit both local values from P, direct relation obtaining, and—when the structured branch is active—Q_org and structure identity unless the named consumer actually needs one. Without such a consumer, state the direct conformance judgment or the structured branch's Q_org constraint judgment. KindMembershipJudgment and ConcernCoverageJudgment remain withdrawn and do not return as kinds or result fields.

In the structured branch, state Q_org and select S without hidden organization

Q_org is one ordinary C.2.1 constraint episteme with exact EntityOfConcern(Q_org)=C_viewpoint. Its ClaimGraph carries the applied semantic constraints under its effective reference scheme and the named admissible describing-use frame. Q is not C, a selected relation occurrence, S, P, a result value, Signature, MethodDescription, organization record, actor, or method.

When the structured branch is triggered, Q carries these eight organization constraints by value:

  1. One target criterion. Select exactly one E_target by its exact claim content and cited target-kind membership rule; a raw kind label, viewpoint name, or collection position proves neither selection nor membership.
  2. Concerns depend on the target. Every exact E_concern[i] depends on E_target. When stakeholder attribution changes the concern, cite one exact stakeholder referent recovered as an independently identified System, local system-role kind, obtaining system-role assignment, collection-as-whole, or another exact local kind whose members are the concern referents. A responsibility claim remains a separately defined direct relation and never follows from the kind or assignment.
  3. Coverage depends on exact concerns and claim families. Each coverage constraint depends on the exact concern constituents and exact claim families it evaluates; a heading, graph edge, unresolved family label, or coverage result is neither the dependency nor proof of coverage.
  4. Semantic form depends on the admitted kind. Each semantic-form constraint depends on the exact independently admitted-kind constituent to which it applies; notation, form, or a raw kind reference grants no admission or dependence.
  5. Method conventions depend on exact method descriptions. Each method-based convention depends on one exact D_method[i] whose exact EntityOfConcern is an independently admitted A.3.1 method. The raw method remains outside C, and description, method, dependence, and performed work remain distinct.
  6. Completeness, consistency, and omission name their subjects. Each such constraint depends on the exact concern or claim components it constrains and names any admitted omission condition by value; a bare status or whole-P label is insufficient.
  7. Resolution does not establish a relation. Resolve every designation and reference under the effective scheme, while keeping spelling equality, lookup, graph adjacency, compatible schemes, token presence, and reference resolution from counting as direct-relation obtaining.
  8. No circular view admission. No admitted-kind constituent may depend on U.View membership or the same conformance judgment being established. Every mutually dependent group needs one named joint-interpretation method or fixed-point criterion.

Replay mutually dependent groups through stratified or witnessed joint/fixed-point semantics. Without that witness, the candidate fails the A.22 selection criterion for the named use. A graph, strongly connected component, iteration syntax, or fixed-point diagram is at most a C.29 representation of already judged occurrences and semantics; it is not the witness, criterion, or selected structure.

An exact system uses the applicable A.22 structure-selection method over exact C, exact obtaining occurrences r_1,...,r_n, the applied Q constraints, and the admissible-use frame. The symbols r_1,...,r_n are local notation, not an O object or collection kind. The selection yields exact S under A.22; C remains the C.13 collection, and each r retains the predicate and occurrence identity defined by its relation pattern.

Identity and change stay local:

  • Q changes only with its claim content, exact C EntityOfConcern, or effective reference scheme; another graph, form, carrier, representation, or publication leaves the same Q edition unchanged.
  • Replacing a selected obtaining occurrence changes the organization used to identify S. Replacing only its assertion, occurrence description, D, J, result, production or use relation, provenance, or graph leaves that occurrence unchanged, although use-specific admissibility may need reevaluation.
  • S changes when C, any selected obtaining occurrence, the applied semantic constraint set, or the admissible-use frame changes. Replacing only Q while those discriminators remain semantically unchanged leaves S unchanged.
  • In the structured branch, P changes only with its fixed claim content, exact S EntityOfConcern, or effective reference scheme. In the self-contained branch, exact target-kind EntityOfConcern replaces S as that discriminator. P is neither its EntityOfConcern, a reference, a bundle position, a publication object, nor an evaluation result.

Resolve P's target criterion, admitted kinds, coverage, semantic-form, completeness, consistency, and omission rules through exact constituent claims and selected obtaining occurrences cited by P. Do not leave them as untyped fields, mandatory Signature constituents, or graph edges treated as occurrences.

In the structured branch the selected public individual is exact episteme P about S. These nearby alternatives remain rejected:

  • S itself is not U.Viewpoint: consumers require the exact claim-bearing edition P, while EntityOfConcern(P)=S.
  • An episteme about one method is a neighboring U.MethodDescription only when exact M and that description independently pass A.3.1 and A.3.2; it is not the viewpoint genus. A method-description constituent does not retarget P from S to M.
  • No viewpoint record, wrapper, organization object, context entity, or non-entity value is needed; P, S, C, and selected relation occurrences already exhaust the identity-bearing objects.
  • A catalogue or local family-declaration position, catalogue edition, package ID, or publication grouping does not constitute P or grant membership.
  • P requires no parent U.Signature, is not a public C.3 local kind, and is not EpistemeViewpointConformanceRelationSignature. A reusable kind declaration, a local-kind classification judgment, and a direct-relation declaration are different jobs with different subjects.

U.Viewpoint is therefore the same P under the complete positive predicate above: no new root identity, wrapper identity, method requirement, selection-dependent membership, or generic-episteme shortcut.

Author progressively and stop at the needed assurance

Authoring is a progressive path, not a mandatory workflow. For self-contained P, identify exact target kind, constitute P with the five fixed claim-content conditions in §4.6.1, apply the positive viewpoint-membership predicate, and mint or reuse U.ViewpointRef. For the structured branch only:

  1. identify every exact constituent edition and state each proposed dependent-to-base claim readably;
  2. resolve both endpoint designations, apply the direct obtaining criterion, and construct exact C from those editions under C.13;
  3. add D only for a named A.22 selection-use claim, and J or evaluation only when that receiving use needs the additional assurance;
  4. apply exact Q constraints and have an exact system use the applicable A.22 selection method over C and the selected obtaining occurrences, producing exact S; and
  5. identify ordinary episteme P about S, apply the positive viewpoint-membership predicate, and only then mint or reuse U.ViewpointRef.

Citation, collection membership, graph adjacency, and displayed edges never close step 2. Selection identifies an existing selected object; it does not construct another constituent episteme. Viewpoint authoring requires neither five fixed stages, one composite method, empirical/formal evaluation, nor J. Identify every cited method under A.3.1 and use B.1.5 only when an order-sensitive method whole independently obtains. Stop as soon as the named receiving use is served; add no assurance artifact merely because a longer path exists.

Keep viewpoint-convention dependence direct

Use ViewpointConventionDependencyRelation(E_dependent,E_base) only when interpreting or replaying the fixed claims of exact dependent constituent episteme E_dependent depends on an exact criterion, law, public name, or method claim carried by exact base constituent episteme E_base, and replacing that base edition or making its exact used content unavailable can change the interpretation or replay. It is the A.6.6 base-dependence case specialized to viewpoint-convention constituents.

Citation, co-membership, reference resolution, compatible schemes, or a graph edge alone does not establish this predicate. For fixed endpoint editions, one positive occurrence r is participant-determined by <E_dependent,E_base>. Scope, time, status, evaluator, evidence, result, use, selection, representation, and publication are neither participants nor occurrence-identity discriminators.

ViewpointConventionDependencyRelationSignature is a separate RelationSignature episteme about the direct relation kind. It declares exactly:

SlotSpecValueKindRefKind
DependentConstituentSlotU.EpistemeU.EpistemeRef
BaseConstituentSlotU.EpistemeU.EpistemeRef

The SlotSpecs declare reusable participant meanings and polarity. Their declaration does not make the relation obtain or identify an occurrence. The current A.6.6 vocabulary resolution chain is viewpointConventionDependsOn -> current vocabulary entry -> ViewpointConventionDependencyRelationSignature -> its EntityOfConcern, ViewpointConventionDependencyRelation. The NameToken, its separate NameCard, vocabulary entry, signature episteme, direct kind, and occurrence remain distinct; spelling or citation proves none of them equivalent and makes no occurrence obtain.

Local designation of the direct relation kind; public row pending

The complete F.18 NameCard below is a durable local naming settlement. Core-facing reuse is proposed, but no current F.17 row or SenseCell accepts this value and sense; the card therefore remains pending and makes no public-row claim.

FieldExact value or rule
NameCardIdNameCard.ViewpointConventionDependencyRelation.Local; this identifies the local card only
GovernedValueRefexact direct kind ViewpointConventionDependencyRelation, not r, its signature, vocabulary entry, token, assertion, or card
GovernedValueKindRefU.Kind; this is the kind of the governed value, not another value reference
SubjectPatternLocatorE.17.0, locating the exact defining and occurrence-identity claims; A.6.6 separately constrains reusable vocabulary-entry use, and F.18 separately constrains this naming act rather than the relation semantics
ReferenceSchemeexact by-value FPFCoreReferenceScheme
ClaimContentNameCard.ViewpointConventionDependencyRelation.Local.ClaimGraph, constituted by all identity-bearing naming-settlement claims in this table
LocalSenseRefsemantic dependence of one exact viewpoint-convention constituent episteme on one exact base constituent episteme, dependent first; replacing that base edition or losing its exact used content can change interpretation or replay
TechLabelViewpointConventionDependencyRelation
PlainLabelthis viewpoint-convention constituent depends on that exact base constituent
CandidateSetdependency candidates: selected label, ConstituentSemanticDependencyRelation, ViewpointConventionRelianceRelation; representation candidates: ConstituentReferenceRelation, ViewpointLinkRelation, ViewpointOrganizationEdge
RejectedCandidatesConstituentSemanticDependencyRelation drops the viewpoint-convention boundary; reliance widens to decision reliance; reference states resolution only; link leaves predicate and polarity unstated; organization-edge names a graph representation rather than obtaining. None is an alias.
SelectionRationalethe selected label names both the viewpoint-convention domain and semantic-dependency predicate; the RelationSignature, not the label, carries participant meanings
BridgeRefsnone; this settlement makes no cross-scheme local-sense correspondence claim
PublicRowStatuspending; no UnifiedTermRowRef, public card identity, F.17 SenseCell, or local-sense basis relation is claimed
LineageEntriesrejected reference, link, organization-edge, semantic-dependency, and reliance spellings remain source lineage only, never synonyms
RefreshConditionreopen when participant kinds, obtaining predicate, A.6.6 use policy, or repeated reader evidence changes; reopen the public-row question only when a current F.17 entry and result accept the exact value, card, scheme, sense, and supported use

Add only the neighboring object the receiving use needs

The compact positive statement may stop at “this exact constituent depends on that exact base constituent.” Add the following objects only under their positive trigger; do not flatten them into one witnessed-base record or add their fields to the two-participant relation.

ObjectPositive trigger and exact identityBoundary
A_dependencya separately reviewable readable assertion is needed: one C.2.1 assertion episteme whose exact EntityOfConcern is E_dependent and whose claims state the direct predicate for exact E_baseauthoring does not make r obtain; A is neither r, an occurrence description, nor a third participant
O_dependencyan already recoverable r needs a separate description: one C.2.1 description episteme whose exact EntityOfConcern is r and whose claims may state endpoints and participant-determined identitythe description is not r, and endpoint mention without independently recoverable r is insufficient
D_dependencyUseone named A.22 structure-selection judgment needs a reviewable claim that exact r is admissible: one C.2.1 episteme identified through obtaining EpistemeConstitutionRelation(G_dependencyUse,r,S_decl), where G is its exact U.ClaimGraph, r is its exact EntityOfConcern, and S_decl is its effective U.ReferenceSchemeD is not G, r, S_decl, an assertion, occurrence description, U.Signature, RelationSignature, selected structure, actor, or third dependency-relation participant; the participant triple does not constitute itself, and obtaining r does not entail use-specific admissibility
J_dependencythat named selection judgment needs inspectable inferential supportJ is non-constitutive justification content, distinct from G; it carries the inferential account for the obtaining and selection-admissibility claims. Claim truth and r's occurrence identity remain governed by their direct rules
empirical or formal evaluation packagea named receiving use needs a tested result or formal conclusionits actors, work, methods, bases, results, evidence, production, and use relations remain separate from r and D
later selection work and C.11 resultaccountable selection or project choice is separately currentan exact system performs Work using the selected method; no generic acceptance relation follows

D_dependencyUse is therefore the exact C.2.1 episteme identified through obtaining EpistemeConstitutionRelation(G_dependencyUse,r,S_decl). The ordered triple names the exact ClaimGraph, EntityOfConcern, and effective ReferenceScheme participants; it is not a self-constituting card or record and does not make the relation obtain.

When the structured branch is active, G_dependencyUse designates exact r and the receiving A.22 use: exact C_viewpoint, exact Q_org constraints applied, and the named admissible-use frame. It carries two separate claim values:

  • c_dependencyObtains: exact direct predicate obtains, independently of use and evidence;
  • c_dependencyAdmissibleForSelection: exact r is admissible among candidate organizing occurrences for that named use frame.

Both are claim values in G, not C.2.1 epistemes, occurrences, or decision results. Changing the use frame can change the second claim while r remains unchanged. Add exact U.ClaimScope or a time qualification to G only when it changes the represented claim; neither becomes a participant. Cite the exact current A.6.6 vocabulary entry and exact RelationSignature as declarations, not as r or proof of r. D is reidentified only when one of exact <G_dependencyUse,r,S_decl> changes; a changed claim value changes D only through changed constitutive G.

When J is present, keep separate conclusion nodes for the two claims and at least these distinct premises when they are actually relied on:

  1. exact E_base under exact S_base carries the criterion, law, public name, or method claim used to interpret or replay E_dependent;
  2. an exact system in exact interpretation or replay work, enacting an admitted method, resolves and applies that base content to E_dependent under exact S_dep; and
  3. replacing exact base edition E_base or making its exact used content unavailable can change interpretation or replay of fixed exact E_dependent.

Designation, citation, graph location, co-membership, scheme compatibility, version difference alone, or a failed lookup supplies none of those premises. If the interpretation is method-dependent, cite the exact U.MethodDescription, but identify the acting system, admitted method, and work occurrence separately.

Keep empirical and formal evaluation local

When empirical interpretation or replay testing is current, identify separately:

  • H_dependencyEvaluator : U.System under A.1 as performer;
  • exact RA_dependencyEvaluator : DependencyEvaluationWorkAssignment <: U.SystemRoleAssignment under A.2.1, with H_dependencyEvaluator in HolderSystemSlot, declaration-local assigned-kind domain DependencyEvaluatorSystemRoleKindDomain, and DependencyEvaluatorSystemRole as RA's assigned-kind value admitted by that domain; the value, assignment, holder System, and Work remain distinct, and neither the value nor assignment acts;
  • M_dependencyTest : U.Method under A.3.1 and, when needed, D_dependencyTest : U.MethodDescription under A.3.2; D describes M but is neither method, work, RelationSignature, nor OperationAlgebra, and a separate A.6.1 operation declaration is cited only when typed application is current;
  • exact W_dependencyTest : U.Work: A.13 first recovers H as the exact actual performer through the already named obtaining RA; A.15.1 independently admits W as enacting M; because this branch expressly represents precise assignment-bound attribution, F.6 separately relates W to that same RA. F.6 identifies neither RA nor H, and a failed F.6 relation would leave W intact while removing only that attribution;
  • exact B_dependencyEmpirical, a C.2.1 episteme identifying the model, calibration, assumptions, and interpretation basis; and
  • exact result episteme T_dependency = <G_dependencyTestResult,E_dependent,S_test>, whose ClaimGraph designates exact E_base, predicate, method, conditions, basis, and positive or negative result.

Establish actual participation of E_dependent, E_base, each parameter, and B_dependencyEmpirical during W only through the exact relations that define those participation positions or A.6.1 operation-application bindings. A MethodDescription or compatible SlotSpec establishes no participation. Open a local A.15.PROD claim only when the receiving use needs to say W first constituted T or later completed its declared production; inception, completion, episteme identity, and dependency obtaining remain distinct.

When formal interpretation is current, constitute exact formal-evidence episteme E_dependencyProof = <G_dependencyProof,E_dependent,S_proof> and exact B_dependencyFormal identifying the theory, axiom set, proof semantics, and interpretation basis. Its ClaimGraph designates exact E_base, proof obligation, formal method, basis, and result. Preserve entailment, refutation, malformed input, timeout, and checker failure as different outcomes; neither a refutation nor a checker failure fabricates positive r. The proof episteme is distinct from r and its participants.

If reusable target claims are needed, constitute them separately under C.2.1:

  • C_dependencyObtains has c_dependencyObtains as its principal claim and concerns the exact endpoint pair and predicate;
  • C_dependencyDoesNotObtain carries a distinct negative principal claim and is not a state of the positive episteme; and
  • C_dependencyAdmissibleForSelection concerns exact r under the named use frame and remains distinct from both obtaining claims.

Co-representation in one ClaimGraph does not merge these epistemes. T carries its empirical conclusion locally; E_dependencyProof carries its formal conclusion locally. If a target-claim episteme separately represents one conclusion, use C.29 only when representation correspondence matters—never as truth, use, or r. Mint no duplicate evidence-bearing relation and no new A.10 ontology.

Keep these three cases distinct:

  1. exact r obtains while support for c_dependencyObtains is unknown; a selecting system may decline reliance without deleting or reidentifying r;
  2. a negative empirical or formal result may support C_dependencyDoesNotObtain without presupposing r, fabricating D, or becoming a positive occurrence; and
  3. T may support the claim that r obtains without supporting use-specific admissibility; a later decision method may consume empirical and formal result epistemes in separate declared premise slots and produce a separate C.11 result.

For historical reliance on a claim or result, use A.10 to recover its obtaining premise, decision-use, reference-use, or operation-argument relation for the named bounded use. Recover exact Work and its enacted Method only when that dated Work is itself a current claim or the expressly selected empirical evaluation branch above requires them. Retain that branch's A.13 performer basis, independent A.15.1 Work admission, and F.6 when precise assignment-bound attribution is consumed. Storage, inspection, citation, attachment, production, graph membership, or adjacency alone does not establish that use. Keep empirical and formal algebras distinct; keep provenance and assurance with A.10, G.6, and B.3. Retain a missing-governor blocker instead of inventing a generic evidence, use, or acceptance relation.

Schemes, scope, transformation, and change

Recover S_dep from E_dependent, S_base from E_base, and S_decl from D. They are three uses of existing U.ReferenceScheme, outside r and its RelationSignature. G may designate exact endpoints, claim values, and declared names through those schemes; designation is neither occurrence obtaining, truth, nor historical participation.

Keep claim-scope widen, narrow, and refit under A.2.6 when no local-sense translation is needed. Use translate only when scope membership must be expressed between exact local senses: require an obtaining F.9 Bridge between their exact SchemeSenseCell values, the separate affirmative claim for that translation's direction, rule, and tolerance, and the current A.10 or B.3 reliance branch. Scheme difference, same spelling, token reuse, or translation intent triggers no Bridge.

Open RepresentationSchemeTransitionRelation@Context only when all six required participants—one independently selected BoundedModelUseStructure : U.Structure, the preserved EntityOfConcern, source and receiving representation epistemes, and source and receiving scheme-description epistemes—are independently recoverable before dependency testing and an exact system performs actual representation-transformation Work. The @Context suffix is only the retrieval label for that A.1.1 bounded-context use; no bounded-context object or generic context field participates, and the required Work is part of the obtaining test rather than a seventh participant. Require the same exact EntityOfConcern, declared preservation for the receiving use, explicit loss or recoverability, tuple-plus-scheme-pair occurrence identity, and a separate transition-description episteme whose EntityOfConcern is that occurrence. Add C.29 only for a current mathematical lens and keep its output local. If no exact transition or Bridge applies, block the proposed cross-scheme dependency use.

Changing only J, an assertion or occurrence description, evaluation result, basis, provenance, production, later-use relation, or representation leaves r unchanged while its endpoint pair is fixed. It also leaves D unchanged while exact <G_dependencyUse,r,S_decl> is fixed. Unknown support does not make an obtaining r non-obtaining, and support for a negative claim creates no positive r. A changed representation transition invalidates judgments that depended on that transition, but changes r only when an endpoint episteme or the direct predicate also changes.

Progressive stopping rule. Use the lightest sufficient rung: readable dependency assertion; reusable RelationSignature when declaration reuse matters; D only for a named A.22 selection-use claim; J only for inspectable inference; evaluation work and exact participation only when evaluation is current; local A.15.PROD only for a needed result-inception or completion claim; provenance, assurance, representation transition, mathematical lens, scope translation, and Bridge only at their own triggers. No higher rung proves a lower-rung occurrence.

Keep selection for one describing use separate

For one current describing use, always name the use. Add one singular viewpointRef : U.ViewpointRef only when selecting P changes what the use reads or checks or what a relying use may conclude; otherwise omit the reference. When present, resolve it under the effective reference scheme to exact P. ViewpointId is P's designator; designator, reference, episteme, and describing use remain different objects.

When the viewpoint matters, that describing use selects P for itself only. The selection does not establish conformance or U.View membership, give E a new C.2.1 identity, reidentify E, or create a universal selection relation, legacy context tuple, bounded-context object, or generic model-use identity field. Another use may select another P while E remains unchanged. A use needing several viewpoints first identifies the C.13 collection and its exact membership; it does not overload viewpointRef with a collection value.

The architecture therefore keeps exactly two positive dependent-kind rules—P as U.Viewpoint by its fixed self-contained content about an exact target kind or, conditionally, by fixed content about selected S; and E as U.View by obtaining conformance—and two direct relation kinds: viewpoint-convention dependence and E/P conformance. D remains optional for a named A.22 use; the two local explicit-result ValueKinds remain optional for named evaluation consumers. Families carry exact U.ViewpointRef values only when a named use needs viewpoint selection. C.2.1 identity, MethodDescription, A.6.3 construction, E.24.PUB publication, C.29 representation, and unrelated interfaces retain their separate identities and rules.

Add viewing construction only when its history matters

A.6.3 defines an exact viewing relation from a source episteme to a separately identified receiving episteme. It preserves the same exact EntityOfConcern. Claim content and the effective reference scheme may be preserved or changed only within A.6.3's declared construction law. If the exact EntityOfConcern changes, the move requires A.6.4 rather than counting as viewing construction.

Keep these claims independent:

  • constitution: C.2.1 identifies the receiving episteme;
  • construction: A.6.3 states an obtaining source-to-receiving viewing relation when one exists;
  • membership: E.17.0 states whether the receiving episteme conforms to an exact viewpoint;
  • work: A system may perform query, authoring, or rendering work;
  • production: use A.15.PROD only when a local work/change/entity-identity-inception or completion claim about the receiving episteme is current.

Do not infer one claim from the label generated view.

Recover multi-view organization and correspondence only as needed

Several conforming views do not automatically form one new entity. For ordinary comparison, exact view epistemes, exact viewpoint epistemes, and their conformance occurrences can remain a plurality.

When the work depends on the collection as a whole, construct it under C.13. When it depends on an organization among those views, recover the exact direct relation occurrences and select one U.Structure under A.22. A package, table, graph, or shared EntityOfConcern is not that structure by appearance.

When cross-view correspondence matters:

  1. name the exact participant epistemes or represented entities;
  2. state the direct correspondence, consistency, realization, trace, or change-impact relation that is claimed;
  3. apply the concrete pattern that defines and tests that relation, including its obtaining and occurrence-identity rules;
  4. identify a C.2.1 assertion or description episteme only when the correspondence claim itself must be reviewed or used;
  5. use C.29 when a graph, matrix, or diagram represents the already recovered objects and relations.

Plain correspondence model may describe such a claim-bearing episteme after its exact EntityOfConcern and direct relations are recoverable. It is not a universal U.CorrespondenceModel kind, a substitute for the relations, or proof that they obtain. If no pattern defines and tests the needed direct relation, return the exact missing-relation blocker or use A.6.RCD; do not close the case with linked, mapped, or consistent.

Temporary inconsistency is represented by exact evaluation claims and, when current, repair work. It does not silently weaken the conformance predicate or erase an obtaining correspondence relation.

Keep publication and conceptual form outside view identity

E.24.PUB keeps three direct relation occurrences distinct:

  • PublicationFormExpressionRelation(selectedEdition,publicationForm,boundedUseDeclaration) states that the exact form expresses enough of that selected episteme edition for the declared use;
  • PublicationFormBearingRelation(presentationCarrier,publicationForm) states that the exact U.PresentationCarrier bears the recoverable form; and
  • EpistemePublicationRelation(selectedEdition,audienceDeclaration,boundedUseDeclaration,publicationForm,presentationCarrier) makes that edition available to entities admitted by the audience declaration for the bounded use, only while both supporting relations obtain and the audience can get the edition through the carrier.

Expression has its exact three participants, bearing its exact two, and publication its exact five. Each occurrence retains its own maximal continuous obtaining or availability interval. Changing a participant identifies another occurrence; an availability gap followed by restoration creates a later publication occurrence. None of those changes reidentifies an otherwise unchanged C.2.1 episteme.

Rendering, upload, or carrier manipulation is U.Work only when an exact system performs it. C.29 separately defines representation and correspondence for mathematical, diagrammatic, or other representations of independently recovered objects and relations. A form, carrier, representation, rendering, or publication occurrence grants no U.Viewpoint or U.View membership and makes no world-side relation obtain.

Plain published view therefore means an already recognized view episteme participating as the selected edition in an exact publication occurrence. It is not another durable kind. One unchanged view may participate in several publications through different audiences, uses, forms, carriers, and availability intervals.

Worked cases

Directly authored architecture view

Architecture episteme E concerns exact system T. Maintainability viewpoint episteme P concerns its selected viewpoint-convention structure and states the target-kind, concern, admitted-kind, coverage, and semantic-form rules. E satisfies those fixed rules, so EpistemeViewpointConformanceRelation(E,P) obtains and the same E is a U.View. No source episteme or A.6.3 viewing is required.

Query output that is not yet a view

A query over source episteme X constructs episteme Y, and A.6.3 records the source-to-Y viewing relation. Y omits a concern component that exact viewpoint P requires. The construction relation obtains, but conformance does not; Y is not a U.View under P. A later repair may create Y2 with different claim content and a new C.2.1 identity.

One episteme, two viewpoints, one selected use

Unchanged episteme E conforms to safety viewpoint P1 and maintenance viewpoint P2. Two participant-determined conformance occurrences obtain, while the named current review use selects only P1 through one singular viewpointRef. E remains one U.View; the selection neither creates the P1 conformance nor removes the P2 conformance.

Viewpoint revision and library repackaging

Adding a reference to unchanged viewpoint episteme P to another E.17.1 local family declaration, or carrying it in another catalogue edition, changes only the catalogue declaration and provenance; it does not change P. Revising P's conformance rules creates another episteme P_new; conformance of E to P_old does not imply conformance to P_new. An EpistemeEditionRelation may relate the P editions, but it is not a conformance occurrence.

Two publications of one view

View episteme E conforms to P. A web page and a printed sheet use exact forms F1 and F2 borne by exact carriers K1 and K2. Separate expression and bearing relations obtain, and two five-participant publication occurrences make the same E edition available under their own audience, bounded-use, and maximal availability intervals. E remains one view episteme; none of the forms, carriers, supporting relations, or occurrences becomes E or P.

Cross-view correspondence

A functional view names transformation F and a structural view names module M. A project claim says M realizes F. The shared system EntityOfConcern and aligned diagram positions do not establish realization. Recover exact F and M, apply the direct realization-relation pattern, then identify an assertion episteme about that occurrence if review needs it. A traceability matrix may represent the assertion and occurrence under C.29; its cell is not the realization relation.

Procedural view is not a method description

A TEVB procedural view E concerns exact holon H and carries claims about methods, order, state, concurrency, and recovery through their exact relations to H. E may conform to procedural viewpoint P and therefore be a U.View, but it is not a U.MethodDescription because its exact EntityOfConcern is H rather than one admitted method. A true method-description view retargets to the method and uses a viewpoint whose target-kind criterion admits methods.

Consequences

GainCost or boundary
Directly authored and derived views share one stable membership rule.A contested view claim requires inspection of one exact viewpoint edition and its fixed rules.
One episteme can serve several viewpoints without duplicated view individuals.Current-use selection must be kept separate from conformance.
Viewpoint catalogues package references without redefining viewpoint identity.A self-contained new P must state its complete fixed test; the C/Q/S branch is justified only when separately versioned convention organization changes a named reuse, comparison, or maintenance action.
Multi-view structures and correspondences become inspectable.A package or graph cannot substitute for collection, structure, or direct-relation recovery.
Publication and rendering can evolve independently of view identity.Publication users must name the exact occurrence, form, and carrier when those distinctions affect work.

Reopen the pattern when either conformance participant kind changes, the fixed predicate changes, or a proposed condition makes occurrence identity depend on an object other than E and P. Reopen a particular use when the candidate episteme, viewpoint edition, selected describing use, direct correspondence, or publication occurrence changes.

Rationale, lineage, and current FPF basis

Only a recoverable exact external source may appear here as SoTA evidence. ISO 42010 remains vocabulary lineage. The local design rationale below uses the current FPF construction, representation, relation, evaluation, and work boundaries directly; a category label is not evidence.

Source or practice lineAdopted moveRejected overreadPractical effect
Architecture-description viewpoint practice, including ISO/IEC/IEEE 42010:2022, used as established practice lineage rather than current architecting SoTASeparate concern-bearing viewpoint, view, described entity, correspondence, and publication.A standards vocabulary does not supply FPF identity, obtaining, or work methods.Readers can recover familiar distinctions while using FPF direct relations and dependent-kind criteria.
Local design rationale, not external SoTA evidence: current C.2.1 identifies source and receiving epistemes; use A.6.3 for any actual source-to-receiving construction, A.15.1 for performed query or projection work, and C.29 for its representation.Treat a query or projection as one possible construction route between separately identified epistemes.Query execution, a query definition, or a projected form does not grant U.View membership or prove claim preservation.Directly authored and query-produced candidates use the same independent E/P conformance test; construction history is opened only when consumed.
Local design rationale, not external SoTA evidence: current direct-relation patterns define and test correspondence predicates; C.29 defines their representations, F.9 defines an exact Bridge between distinct F.17 cells when its predicate obtains, evaluation patterns test consistency, and A.15.1 identifies repair work.Keep correspondence, consistency evaluation, and performed repair distinct.A trace link, graph edge, correspondence episteme, or repair result does not make the subject relation obtain.Inconsistency and repair can be stated and acted on without collapsing world-side relation, epistemic judgment, representation, and work.
Local design rationale, not external SoTA evidence: current FPF constructive-relation and episteme architectureIdentify E and P independently; identify selected S and convention-dependency occurrences only in the action-changing structured branch; derive U.View membership from obtaining E/P conformance.Do not materialize a universal family record, mandatory convention structure, context slot bundle, or correspondence-model kind.Ordinary authoring can stop at self-contained P, while shared-convention maintenance remains replayable when it actually exists.

Relations and contribution boundaries

  • C.2.1 identifies episteme, claim-content, EntityOfConcern, scheme, and edition identity for P, E, D, and any optional assertion, description, result, basis, or target-claim episteme. E.17.0 adds dependent U.Viewpoint and U.View membership to those same individuals.
  • Use C.13 to construct exact C_viewpoint only in the action-changing structured-viewpoint branch, and any separately needed collection of selected viewpoints or views.
  • A.6.6 defines the reusable viewpointConventionDependsOn vocabulary entry; A.6.5 declares the four SlotSpecs inside the two RelationSignature declarations. E.17.0 defines direct dependency and conformance obtaining tests and positive occurrence identity.
  • C.3.2 admits the two optional local explicit-result ValueKinds and any exact local target or stakeholder KindSignature; their values do not determine direct judgments.
  • Use A.22 to select S_viewpoint only when separately versioned convention organization changes a named action, and to select any separately current multi-view structure. E.17.0 supplies Q and candidate relation occurrences for that branch.
  • A.6.3 defines optional source-to-receiving viewing construction, including identity viewing; it does not define view membership.
  • E.10.D2 defines description epistemes and specification use. A describing use is always named; it selects a viewpoint only when that choice changes reading, checking, or a permitted conclusion. Selection does not establish conformance.
  • F.18 supplies the two relation-kind NameCards; naming metadata neither defines relation semantics nor grants admission. F.9 applies only when an exact relation between distinct F.17 SchemeSenseCell values obtains.
  • E.17.1 defines exact catalogue epistemes and local family declarations whose members are exact U.ViewpointRef values. E.17.2 supplies the four-position project-local engineering viewpoint authoring template and, only after local materialization, its four exact bindings. A declaration, template position, or reference grants no viewpoint or view membership.
  • E.24.UK admits dependent U.Viewpoint and U.View once for public use; E.17.0 supplies their stable positive membership predicates.
  • E.24.PUB defines form expression, carrier bearing, publication availability, and recurrence. C.29 defines representations and correspondence; neither makes the represented world-side relation obtain.
  • A.1, A.2, A.2.1, A.3.1, A.3.2, A.15.1, and F.6 distinguish performer Systems, local system-role kinds, exact assignments, Methods, MethodDescriptions, Work, and attribution. Responsibility remains under its direct predicate. Use A.15.PROD only for a separately needed local inception or completion claim.
  • A.10, G.6, and B.3 retain provenance and assurance. Use A.6.RCD when no pattern defines a needed cross-view or use relation.

Conformance checklist

  1. Candidate E has recoverable C.2.1 claim content, exact EntityOfConcern, and effective reference scheme.
  2. U.ViewpointRef resolves to one exact viewpoint episteme P; designator, reference, P, P's exact target-kind or structured EntityOfConcern, and any catalogue position remain distinct.
  3. Self-contained P has the exact admitted target kind or exact local-kind subject as EntityOfConcern and carries the complete fixed conformance test in its ClaimGraph. Only the action-changing structured branch uses an A.22-selected S_viewpoint over least-powerful exact constituent editions and obtaining relations, with Q carrying the eight organization constraints.
  4. Every dependency occurrence has only exact dependent/base epistemes as participants; assertion, description, D, J, evaluation, work, scope, time, scheme, representation, publication, and use remain conditional neighbors.
  5. EpistemeViewpointConformanceRelation has exactly E and P as participants, the fixed five-condition semantic predicate, and pair-determined positive-occurrence identity.
  6. U.View membership follows only from an obtaining conformance relation, never from authoring, identity viewing, query, selection, packaging, form, carrier, rendering, or publication.
  7. The current describing use is named. A singular viewpoint reference selects P only when that choice changes reading, checking, or a permitted conclusion; omission otherwise changes neither episteme identity nor conformance. Multi-selection uses a C.13 collection with exact membership.
  8. Optional local result values, evaluation, evidence, occurrence designation, decision-use D, and J exist only for a named receiving work or decision need; unsupported evaluation is not a third or negative value.
  9. For every multi-view collection, selected structure, or cross-view relation, apply the pattern that defines its identity or obtaining test; a table, graph, matrix, or shared subject proves none.
  10. Form expression, carrier bearing, five-participant publication availability and recurrence, rendering work, and C.29 representation remain distinct from E, P, view membership, and every represented world-side relation.
  11. Ordinary use stops at a readable direct judgment unless a named consumer needs more structure; authoring stops at the shortest progressive path that produces exact P and its reference.

E.17.0:End


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