Part C - Kernel Extension Specifications
Preface node
heading:part-c-kernel-extension-specifications:41789
What this page is
This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.
Methodology
Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.
Content
Epistemic holon composition (KD-CAL)
Scope & exports. A substrate-neutral calculus for composing epistemic holons (U.Episteme) and reasoning about their change and equivalence. Exports: (i) three point-characteristics—Formality F, ClaimScope G, Reliability R—that locate one exact claim-bearing episteme for a stated use; (ii) a pairwise ladder of Congruence Levels (CL 0…3); (iii) four Δ-moves (Formalise, Generalise/Specialise, Calibrate/Validate, Congrue); (iv) composition rules (Γ_epist) for aggregates; and (v) propagation laws for CL through mappings and notation relations. C.2.1 identifies an episteme by its exact claim content, exact EntityOfConcern, and effective U.ReferenceScheme under EpistemeConstitutionRelation. Empirical grounding and edition are separate C.2.1 relations. Viewpoint selection and U.View conformance use E.17.0; mathematical or diagrammatic representation uses C.29 and A.6.3.RT; publication uses E.17/E.24.PUB; a carrier remains a distinct entity. Every F–G–R computation names the exact claim and its U.ClaimScope. If a path changes scope, notation, kind, reference plane, source-local meaning, model-use basis, or evidence basis, it names the actual relation traversed and applies only the loss that relation declares; no generic Context, slot umbrella, or Bridge stands in for those different relations.
Formality F is the rigor characteristic defined normatively in C.2.3. All KD‑CAL computations and guards SHALL use U.Formality (F0…F9) as specified there; no parallel “mode” ladders are allowed.
Problem Frame
FPF fixes two archetypal sub-holons: U.System (physical/operational) and U.Episteme (knowledge holon). KD-CAL is the primary composition pattern for U.Episteme, giving engineers a compact, testable way to say (a) how strictly an episteme is written (F), (b) where its exact claim is asserted to apply (G), (c) how well that claim is warranted by evidence or severe tests (R), and (d) how closely two epistemes coincide (CL). C.2.1 supplies the constitution test: exact claim content, one exact EntityOfConcern, and one effective U.ReferenceScheme. Grounding, edition, viewpoint, view, representation, publication, form, and carrier remain neighboring objects or relations under their direct patterns.
Problem
Teams routinely entangle programs, specifications, proofs, and datasets; a “proof” is treated as a tested routine, a “program” is cited as if it entailed a theorem. Trust decays because justification and evidence freshness are not explicit. Epistemes are anthropomorphised as actors (“the standard enforces…”), producing category errors at execution. Without a shared composition and equivalence calculus, aggregates hide weakest links and analogies harden into overclaims. KD‑CAL must stop these failure modes with a single constitution and scale‑set.
Forces
- Universality vs domain idioms. One calculus must cover physics theories, legal codes, safety specs, algorithms, and formal proofs without flattening their differences.
- Meaning vs materiality. Meaning must be independent of carrier, yet accountable to it historically.
- Deductive vs empirical. Axiomatic certainty and empirical trust have different evidence-continuity profiles; both must compose.
- Abstraction vs enactment. Epistemes constrain action; systems act. The calculus must keep the roles distinct.
Solution
Coordinates, constitution, and neighboring relations
KD‑CAL characteristics (single‑episteme, point‑values).
- Formality F. From free prose to machine‑checkable proof/specification. Litmus: would a machine reject it if wrong?
- Claim scope (G), a set‑valued applicability over
U.ContextSlice, with ∩/SpanUnion/translate algebra; CL penalties apply to R, not to F/G. Litmus: how wide is the declared scope, and under what minimal assumptions does the claim hold? - Reliability R. From untested idea to continuously validated claim. Litmus: where is the last successful severe test? R‑claims MUST bind to evidence and declare relevance windows; stale bindings degrade R or require waiver per ESG policy.
Congruence Level (CL), pairwise ladder.
CL‑0 Opposed/Disjoint (contrastive; no substitution); CL‑1 Comparable / Naming‑only (label similarity; no substitution); CL‑2 Translatable / RoleAssignment‑eligible (structure‑preserving mapping in a declared fragment with stated loss; theorems may transport); CL‑3 Near‑identity / Type‑structure‑safe (invariants match; type‑structure substitution allowed). CL is a characteristic of a relation between two epistemes; it is not a fourth member of the F–G–R assurance tuple and it is not a characteristic space of its own. Norm: substitution is permitted only if plane‑preserving and CL ≥ 2; substituting type‑structure requires CL = 3.
Constitution and neighboring relations. State F, G, and R for one exact claim of one C.2.1 episteme. Its exact claim content, EntityOfConcern, and effective U.ReferenceScheme identify the episteme through EpistemeConstitutionRelation. F characterizes the claim's form; G is the separate U.ClaimScope; R relies on exact evaluation, evidence-use, and assurance relations. Empirical grounding and edition remain separate C.2.1 relations. Viewpoint selection and view conformance remain under E.17.0; notation and other representation structure remain under C.29/A.6.3.RT; publication occurrence, form, and carrier remain under E.17/E.24.PUB. Multiple notations are allowed only when their exact representation or notation relation is explicit and any declared loss is applied to R rather than hidden in an omnibus episteme field.
Four Δ‑moves (epistemic motion)
- ΔF — Formalise. Rewrite for stricter calculi/grammars; raise proof obligations.
- ΔG — Generalise / Specialise. Widen or narrow the claim scope (assumptions & scope). Changes to decomposition granularity are an orthogonal view and do not change G unless they alter the envelope.
- ΔR — Calibrate / Validate. Strengthen severe tests or add live monitoring; update evidence bindings.
- ΔCL — Congrue. Establish and record the sameness relation between two epistemes (ladder 0→3). Moves compose into paths; CL along a path is the minimum of its links.
Composition (Γ_epist) and propagation
Let Γ_epist combine epistemes {Eᵢ} into a composite episteme Γ that makes a joint claim (AND‑style) or exposes an interface (series composition). KD‑CAL imposes safe defaults:
-
R (Reliability). Along any justification path
P, computeR_eff(P) = max(0, min_i R_i − Φ(CL_min(P)))(weakest‑link with congruence penalty). For series composition (claims needed conjunctively), the path‑wise weakest‑link applies; for parallel support (independent lines to the same claim), useR(Γ) = max_P R_eff(P)(annotate independence); never exceed the best attested line. A traversed notation, scope-translation, kind, plane, source-local, model-use, or evidence-reuse relation contributes toCL_min(P)only through the loss rule it actually declares. -
F (Formality).
F(Γ) = minᵢ F(Eᵢ)(monotone non‑increasing along used paths). To raise F, apply ΔF to the weakest parts. -
G (ClaimScope). On any dependency path, take the intersection of claim scopes (the narrowest overlapping scope). Across independent support paths to the same claim, set
G(Γ) = SpanUnion({G_path})constrained by support (drop unsupported regions). Widening/narrowing the scope is an explicit ΔG± operation. -
CL (Congruence). For a chain of mappings
E₀ ~ E₁ ~ … ~ Eₖ, the path congruence ismin CL(Eⱼ,Eⱼ₊₁). Passing through a NotationBridge sets CL to the bridge’s declared level; the Φ(CL) penalty is applied in the R fold for any path that traverses it.
These rules keep Γ aligned with the holonic kernel: Γ is only defined on holons and respects identity/boundary discipline from the core.
What must not be conflated (normative guards)
- Representation structure ≠ carrier. Files, PDFs, or repositories are carriers outside the episteme; they never count as parts of
U.Episteme(see C.2.1 EP‑1; CC‑EPI‑2/3). - Epistemes do not act. Only systems perform Work. Epistemes carry claim content and can participate in constitution, grounding, edition, description, evidence-use, reliance, viewing, representation, and publication relations under their direct patterns.
- CL is not a score. It is a qualitative ladder of preservation classes; do not average it.
✱ Archetypal Grounding (Tell–Show–Show)
Universal rule (tell). Compose knowledge by Γ_epist with weakest-link R, monotone F, and explicit CL on every relation that declares it. Identify the episteme by exact claim content, EntityOfConcern, and effective reference scheme; keep empirical grounding, edition, viewpoint selection, view conformance, representation, publication form, publication occurrence, and carrier in their own direct relations.
System (show, current physical-system lens). Consider a battery-pack thermal subsystem integrating a physics model of heat flow and an operating envelope for fast-charge. As a system, it composes pumps, sensors, and controllers through the system, composition, boundary, state, and dynamics guidance in A.1, A.14, A.22, and A.3.4, with conservation constraints made explicit; B.1.6 and C.16 govern resource and measurement claims as applicable. Planned C.1 (Sys-CAL) may later consolidate that guidance, but it supplies no current governing semantics. The assurance story depends on epistemes about the model and envelope; the system acts, epistemes constrain. (Archetypes and boundary discipline per core.)
Episteme (show, KD-CAL lens). Consider a CMIP-class climate projection episteme (post-2015 generation): its exact claim content covers PDEs and parameterisations; its EntityOfConcern identifies what the projection claims concern; and its effective reference scheme supplies the interpretation rules. A separate U.ClaimScope names historical forcings, resolution, and assumptions. Any empirical-grounding occurrence names the grounding holon and covered claim subgraph separately. Its representation may include domain equations and a tabular schema linked by an explicit notation or representation relation with stated loss. Compose sub-epistemes for radiation, clouds, and ocean mixing: R = min across the critical path; an independent hindcast line can raise R only up to its own level; F is bounded by the least-formal sub-claim unless the composition adds formal invariants.
Bias‑Annotation
- Metric worship. Treating
[F,G,R]as ends rather than means; mitigation: require evidence bindings and narrative of limits in the claim scope and grounding envelope. - Category slip. Equating a notation, view, publication form, or carrier with claim content, EntityOfConcern, effective reference scheme, or an empirical-grounding participant; mitigation: apply C.2.1 constitution and then the direct neighboring relation pattern.
- Analogy inflation. Presenting CL‑0/1 as identity; mitigation: always name the CL rung for cross‑mappings.
Conformance Checklist
- C2-1 (Episteme constitution and neighbors). Every
U.EpistemeMUST satisfy C.2.1 constitution through exact claim content, one exact EntityOfConcern, and one effectiveU.ReferenceScheme. Empirical grounding and edition are stated through their separate C.2.1 relations. Viewpoint selection andU.Viewconformance use E.17.0; representation uses C.29/A.6.3.RT; publication occurrence, form, and carrier use E.17/E.24.PUB. None is treated as an episteme slot or identity component merely because a record or notation places it beside the constitution values. - C2‑2 (Coordinates). Each episteme SHALL declare
[F,G,R]with a brief rationale; F isU.Formality ∈ {F0…F9}per C.2.3, exactly one episteme‑level F computed as the min over essential parts. CL is declared for pairs only. A named notation scheme MAY use sub‑anchors (e.g.,F4[OCL],F7[HOL]), which MUST preserve the global order and map to their parent anchor from C.2.3. - C2‑3 (Composition). Authors SHALL choose Γ_mode (series vs parallel). For any justification path use
R_eff(P) = max(0, min_i R_i − Φ(CL_min(P))); for parallel independent lines to the same claim, takeR(Γ) = max_P R_eff(P)(never exceeding the highest-R support line). ComputeF(Γ) = minalong the used paths. For G, use path‑wise intersections and then SpanUnion({G_path}) constrained by support. A traversal MUST name the actual scope-translation, notation, kind, plane, source-local, model-use, evidence-reuse, or other direct relation and apply only its declared congruence loss toR. - C2‑4 (NotationBridge). Multi‑notation representation components SHOULD register
NotationBridgeedges with CL and loss note; any cross‑notation reasoning MUST cite the bridge’s CL. - C2‑5 (No action). Epistemes MUST NOT be assigned actions; work is executed by systems in role.
Consequences
Benefits. A single, compact map for all knowledge epistemes or publications; fast detection of weakest‑link R in aggregates; disciplined reuse across domains with explicit CL; consistent separation of meaning from material carriers. Trade-offs. Authors must learn to declare Γ-mode and CL explicitly; multi-notation work requires relation-specific bookkeeping. Mitigation: the three-part C.2.1 constitution test and direct neighboring patterns keep the ordinary entry brief while preserving recoverable precision.
Rationale
KD-CAL turns the coarse legacy semiotic picture into holonic composition over exact C.2.1 epistemes and their claims. Exact claim content, EntityOfConcern, and effective reference scheme keep episteme identity stable; formal structure and claim scope (F,G), evidence (R), and pairwise congruence (CL) remain visible and composable without an omnibus slot relation. Direct grounding, edition, view, representation, publication, and carrier patterns prevent category collapse. The resulting characteristics remain manager-readable and formalisation-ready, with G grounded in scope/envelope rather than part count.
Relations
- Depends on:
C.2.1 U.Episteme: Constitution, Empirical Grounding, and Edition Relationsfor episteme identity, the constitution relation, and the separate grounding and edition relations;E.17.0for viewpoint selection andU.Viewconformance;C.29andA.6.3.RTfor representation; andE.17/E.24.PUBfor publication occurrence, form, and carrier. - Peers: planned Sys-CAL (
C.1) may later consolidate physical-system guidance; current system composition, boundary, state, conservation, resource, and measurement claims useA.1,A.14,A.22,A.3.4,B.1.6, andC.16as applicable. KD-CAL composes epistemes and feeds assurance lenses in Part B. - Constrained by authoring: Architectural patterns must include Tell–Show–Show with Archetypal Grounding (this section).
Worked mini‑examples (post‑2015 flavours)
- Formal lift (ΔF). Recasting a 2019 variational free‑energy narrative into a typed calculus raises F, clarifies scope, and enables CL‑2 bridges between biological and ML formulations—without claiming empirical gain (R unchanged).
- Parallel evidence (R, max). Two independent hindcast lines (circa CMIP6, 2019) supporting the same forecast allow
R(Γ)=max(R₁,R₂); if one line drifts, the composite is bounded by the higher-R support line until series constraints apply. - Notation bridge (CL drop). A 2021 type‑theoretic specification rendered in a semi‑formal DSL requires a
NotationBridgewith a CL<3 note; any theorem transported across must respect the bridge’s declared preservation.
(No tooling is implied; these are conceptual moves within the calculus.)
C.2:End
U.Episteme: Constitution, Empirical Grounding, and Edition Relations
Type: Pattern Status: Stable Normativity: Normative except where a section is explicitly marked informative
Plain name. Episteme constitution.
Mint or reuse. This pattern reuses U.Episteme, U.ClaimGraph, U.Entity, U.ReferenceScheme, U.Holon, U.Signature, RelationSignature, and SlotSpec. It introduces the direct relation names EpistemeConstitutionRelation, EpistemeEmpiricalGroundingRelation, and EpistemeEditionRelation. It also defines the reusable non-entity value C.2.1 ClaimAddress for one intrinsically identified claim inside one exact episteme edition and states the U.EpistemeRef resolution rule it consumes. Each named ...RelationSignature below is the relation-facing use of one declaration episteme for which the A.6.0 membership predicate obtains; A.6.0 therefore recognizes that same individual as a U.Signature, not as another identity. The signature-local SlotKinds named below identify participant meanings only inside their stated signatures. An episteme itself has no slots, and repeated slot spelling in another signature establishes no shared SlotKind by spelling alone.
One-line summary. A U.Episteme is a knowledge holon identified by exact claim content, one exact EntityOfConcern, and the effective U.ReferenceScheme that makes those claims interpretable as claims about that entity. EpistemeConstitutionRelation is the core direct relation of the episteme ontic. Empirical grounding, viewpoint, view, scope, model use, edition succession, description, publication, carrier, and mathematical representation remain neighboring objects and relations.
Use this pattern when. Use C.2.1 when one body of claims about one exact subject, interpreted under one effective reference scheme, must be identified or compared. In ordinary words, identify what this body of knowledge says, what it says about, and which shared rules make that saying interpretable.
Changed claims, a changed subject, or a changed interpretation identify another episteme. Changed empirical grounding, viewpoint or view use, publication, form, carrier, or representation can leave the episteme unchanged; update the neighboring object or relation that actually changed.
A theory, model, specification, proof, or diagnosis can therefore be an episteme when the selected object is that claim-bearing whole. A diagram or dashboard has two branches: use C.2.1 when the selected claim-bearing whole satisfies the constitution test above; when the current object is instead its layout, file, display, or correspondence to something else, treat it as a publication form, carrier, or C.29 representation rather than as the episteme.
Primary working reader. An engineer or researcher who needs to identify a knowledge object and use it without mistaking its subject, file, view, evidence, or publication for that knowledge object.
Primary working concern. Keep one claim-bearing object reidentifiable through empirical grounding, viewing, revision, and publication, and detect when changed claims, subject, or interpretation identify another episteme.
Primary viewpoint. The practitioner using, comparing, revising, or publishing that knowledge object while keeping its identity and neighboring relations distinct.
Primary governed object. One U.Episteme: the claim-bearing knowledge holon being identified or compared.
Architecture in scope. C.2.1 also governs that episteme's EpistemeConstitutionRelation, EpistemeEmpiricalGroundingRelation, and EpistemeEditionRelation; it coordinates with the subject patterns of viewpoint, view, scope, model use, description, publication, form, carrier, and representation.
Terminology guard. The EntityOfConcern of an episteme is the exact entity its claims concern. It is not the same field as the primary governed object of this pattern.
First useful move. Ask three ordinary questions: what is claimed, what exact entity are the claims about, and what designation and interpretation rules make those claims readable about that entity? Where the claims use measurement, comparison, or evaluation rules, name those applicable rules too. Those answers identify the episteme. If identity is all the task needs, stop there. Otherwise name the concrete receiving use—such as comparison, preservation, teaching, publication, inquiry, or decision—and add only the neighboring object or direct relation needed for its next visible sentence or action. Name an unresolved uncertainty or choice only when a real inquiry or decision has one.
What goes wrong if missed. A file or diagram becomes "the model"; a subject label drifts while the same episteme name is retained; the holon through which claims are empirically inspected, or the viewpoint from which claims are selected, is copied into episteme identity without justification; or a revised publication is mistaken for a changed knowledge object.
What this buys. Epistemes can be compared, revised, grounded, viewed, published, and used recursively while ordinary prose stays short. The complete distinction among the episteme, its direct relations, and their assertion, publication, and representation objects remains recoverable without making users restate every object for every claim.
Not this pattern when. Use the direct subject pattern when the current question concerns the system, work, method, relation occurrence, or other entity described by an episteme. Use A.1 for constructive recognition of a candidate under an admitted holon kind, C.3.2 for a local-kind membership judgment, and E.24.UK for FPF U-kind admission. Use E.17 and E.24.PUB for publication, A.10 and B.3 for evidence or assurance, C.29 for a mathematical representation, and E.10, C.2.P, or F.18 for precision restoration or naming. C.2.1 governs episteme identity, including the identity of a separately current classification assertion.
Problem Frame
FPF treats an episteme as a holon, not as a document class or a filled record. A pump-maintenance specification, a clinical model, a theorem, a learned classifier description, and a curriculum model can all be epistemes when each is a claim-bearing whole about an exact EntityOfConcern under an effective reference scheme. Their carriers, notations, and admissible operations differ, but that difference does not remove the shared ontology question: what makes this one episteme, and what changes its identity?
The episteme ontic coordinates these distinct objects without collapsing them:
- the
U.Epistemeknowledge holon; - direct relation occurrences that constitute, ground, or connect editions of that holon;
- declaration epistemes whose C.2.1 identity is fixed independently, whose same individual has
U.Signaturemembership underA.6.0, and whose relation-facingRelationSignatureuse declares reusable participant SlotSpecs for one exact relation kind; - assertion epistemes that claim a direct relation predicate obtains and description epistemes whose EntityOfConcern is one explicitly individuated occurrence;
- publication occurrences that make one selected episteme edition available for a bounded audience and use;
- publication forms that express the selected edition for that publication use;
U.PresentationCarrierentities that bear those forms;- C.29 mathematical representations that correspond to independently recovered objects for an explicit modeling or reasoning use.
The core constructive question is not which fields a card contains. It is whether an exact U.ClaimGraph, exact U.Entity, and effective U.ReferenceScheme stand in the relation that makes the claim content interpretable and evaluable as claims about that entity. When they do, their selected organization yields a whole-level epistemic characteristic: the resulting holon can be used as one defeasible or deductive body of knowledge. That characteristic is not supplied by any one participant alone.
Any exact U.Entity can participate as the EntityOfConcern. An episteme can therefore concern a system, work, method, relation occurrence, another episteme, or itself without changing the constitution relation. Episteme recursion does not introduce a second meta-episteme ontology.
Contemporary work on formal languages as cognitive tools, material and diagrammatic reasoning, distributed representations, and tool-assisted reasoning explains why representation regimes matter. C.2.1 preserves that insight by keeping representation and admitted operations explicit when current. It does not let notation, latent geometry, tool output, or a publication form determine episteme identity.
Problem
Without one direct episteme ontology, several practical failures recur.
- Carrier and episteme collapse. A PDF, database row, proof script, dashboard, or neural-model file is treated as the knowledge holon. File replacement is then reported as epistemic change even when claim content, EntityOfConcern, and interpretation are unchanged.
- Subject drift. A specification or model keeps one label while the entity it concerns changes. Comparison and evidence use then combine claims about different entities.
- Interpretation drift. The same tokens or graph are read under different designation, measurement, or evaluation rules while users assume one unchanged episteme.
- Neighboring-relation collapse. Grounding holon, viewpoint, view, claim scope, model-use structure, evidence, edition, and publication become optional fields of one omnibus record. Their different obtaining and identity rules disappear.
- Representation-first ontology. Tuple components, graph nodes, schema fields, and database keys are treated as actual relation participants or subject identity discriminators merely because a tool exposes them.
- Agency leakage. A standard, model, method description, or claim graph is said to perform work. Systems perform work; epistemes participate in use, description, evidence, decision, and publication relations.
- Dependent-kind identity fork. A method description or view is assigned another identity merely because its direct pattern supplies a membership condition. The same episteme can then appear twice, and a viewpoint or method-description use can be mistaken for a change of knowledge object.
The familiar Symbol-Concept-Object triangle can still introduce the difference among expression, meaning, and subject. It cannot serve as the ontology because it suppresses reference scheme, grounding, viewpoint, evidence, and the distinction between a relation and a representation of that relation.
Forces
Solution
Identify each U.Episteme through EpistemeConstitutionRelation: first state what it says, what exact entity it concerns, and the scheme under which those claims are read. Then name what the reader will do with that episteme. Add a neighboring relation only when the reader's next sentence or action requires it. Keep declaration epistemes, assertions, descriptions, names, references, publication occurrences, publication forms, carriers, and representations distinct under their direct patterns.
Local episteme mantra. Name the claims, what they concern, and the scheme that gives those claims their reference. Stop if identity is all the task needs. Otherwise name the concrete receiving use and add only the neighboring object or relation needed for its next sentence or action. Ask for an unresolved question only in a real inquiry or decision. Update episteme identity only when claim content, EntityOfConcern, or effective reference scheme changes; otherwise update the affected neighboring relation, publication occurrence, publication form, or carrier under its direct pattern.
The mantra is a recall aid, not a work plan. The application method and stop conditions are carried by sections 4.1-4.9; section 4.10 is a later reference for relation and neighboring-object distinctions.
First-use completeness questions
Begin with the three questions that identify the episteme. They are identity questions, not fields to fill.
If the task needs only the episteme's identity—for example, to cite, catalogue, compare, teach, or reconstruct it—stop after the three answers. Otherwise state the concrete receiving use. Ask for an unresolved uncertainty or choice only when that use is a real inquiry or decision; comparison, preservation, teaching, and publication need no invented decision question.
Open a row below only when its first column names the reader's next sentence or action. Each positive answer adds an independently governed object or direct relation; none adds another slot or identity discriminator to the episteme.
Stop when no row describes the next sentence or action. A readable sentence naming the claims, EntityOfConcern, and effective reference scheme is then enough. Do not complete the table as a record. Use section 4.10 only when a later sentence or action actually needs the full relation and neighboring-object reference.
Identify the episteme by its constitution
The shared C.2.1 identity of one U.Episteme is:
claim content is the identity-bearing U.ClaimGraph carried as the episteme's constitutive claim structure. Each episteme selects one exact U.Entity as the EntityOfConcern of the current claim-bearing whole. Its ClaimGraph may also designate other independently governed entities as participants in relational, comparative, negative, counterfactual, or modal claims.
When the subject really is an admitted relation kind, an already individuated obtaining relation occurrence, an admitted collection-as-whole, or another independently identified joint entity, that object may be the EntityOfConcern. Several participant designations do not by themselves constitute such an object. A negative or counterfactual relation claim can designate the relation kind and its participants in the ClaimGraph without requiring an obtaining world-side occurrence.
Split the ClaimGraph only when it combines independent subjects in a way that makes the selected EntityOfConcern untruthful or breaks the intended identity or comparison use; do not split merely because one predicate connects several participants. The reusable predicate-definition boundary is stricter: before publication, name one truthful exact EntityOfConcern and state what the definition claims about it. If no such single concern can be selected, remain at local compound-claim level.
The effective U.ReferenceScheme supplies the designation and interpretation rules needed to read this ClaimGraph as claims about this EntityOfConcern. Add measurement, comparison, or evaluation rules only when the claims' meaning uses them. The corresponding measurement or evaluation entities and relation occurrences remain under their direct patterns.
Formal near-miss: a theorem read under a formal vocabulary and calculus needs designation and interpretation rules, but it does not acquire ceremonial measurement or evaluation rules. Empirical contrast: a pump-tolerance episteme uses the applicable units, measurement procedure, and pass/fail criterion to make its claim meaningful; the actual measurement and evaluation occurrences remain neighboring objects rather than episteme constituents.
Changing any identity discriminator yields another episteme. Changing a carrier, layout, rendering, publication occurrence, evidence item, viewpoint assignment, or model-use setting does not by itself yield another episteme. A direct pattern may recognize the same individual as a dependent episteme kind through its stable membership condition, but it does not add another identity discriminator. [A.3.2](/generated/patterns/A.3.2) governs U.MethodDescription membership; [E.17.0](/generated/patterns/E.17.0) governs U.Viewpoint and U.View membership through fixed predicates over already identified epistemes. [A.6.3](/generated/patterns/A.6.3) governs an optional viewing construction between source and receiving epistemes, not view membership. If any work or construction changes claim content, EntityOfConcern, or effective reference scheme, those changed C.2.1 discriminators identify the resulting episteme, not the dependent-kind label.
This identity is constructive. The claim graph and reference scheme are epistemic constituents; the EntityOfConcern remains an independently governed entity related through aboutness and reference. When EpistemeConstitutionRelation obtains, their organization yields the whole-level characteristic of being one interpretable claim-bearing whole. The relation occurrence and the resulting episteme are distinct but reidentified from the same three discriminators.
Govern the core direct relation
Tech name: EpistemeConstitutionRelation.
Plain reading: these claims, under this reference scheme, are claims about this exact entity and together constitute one episteme.
Participants and the shared reusable-declaration rule
Before using any signature-local table, identify the declaration itself. Each of EpistemeConstitutionRelationSignature, EpistemeEmpiricalGroundingRelationSignature, and EpistemeEditionRelationSignature is first one exact C.2.1 episteme: its own U.ClaimGraph carries the declaration claims, its exact EntityOfConcern is the direct relation kind, and its effective U.ReferenceScheme makes those claims interpretable. For each of these three declarations the fixed A.6.0 membership predicate obtains, so A.6.0 independently recognizes that same episteme individual as a U.Signature. RelationSignature names the relation-facing use of that same individual; it is neither another U-kind nor another identity.
A complete declaration claim names the direct relation-kind designator, the exact A.6.5 SlotSpecs needed by reusable typed uses, the obtaining predicate, the occurrence-identity rule, applicability, and only the dependencies and provided names that are actually current. The direct relation kind, its actual participants, an obtaining occurrence, an assertion about it, a relation-occurrence description episteme, the declaration episteme, its publication, and a representation of any of these remain distinct. A receiving need may justify typed reuse but does not identify the declaration. One readable assertion needs no signature or manifest. An A.6.0 manifest is optional and is used only when actual dependencies or provided names must be exposed; a manifest row, list, citation, identifier, or edition marker creates neither episteme identity nor dependency.
Applying that shared rule locally, typed reuse of EpistemeConstitutionRelation uses the one declaration episteme EpistemeConstitutionRelationSignature, whose exact EntityOfConcern is EpistemeConstitutionRelation and whose declaration includes these SlotSpecs:
The SlotKinds belong only to this declaration. An actual claim graph, EntityOfConcern, or reference scheme is an actual relation participant under its independently governed kind. A card field or assertion designation corresponds to a SlotKind but does not become the participant.
Obtaining and occurrence identity
EpistemeConstitutionRelation obtains exactly when the effective reference scheme supplies a coherent designation and interpretation of the claim graph as claims about the exact EntityOfConcern, and the three participants are constitutively organized as one claim-bearing whole whose claims can in principle be evaluated under that scheme. Merely placing three designations in a card does not make the relation obtain.
The relation occurrence is participant-determined by the exact <ClaimGraph, EntityOfConcern, ReferenceScheme> triple. The same triple cannot constitute two distinct U.Episteme instances under the shared C.2.1 identity rule. Recognition of that individual as a dependent episteme kind adds a membership judgment under the dependent kind's subject pattern, not another constitution occurrence or discriminator. A tuple may represent the triple under C.29, but tuple order and storage keys contribute nothing to identity.
The episteme and the relation occurrence are not identical. The relation is the obtaining organization among the three participants. The episteme is the knowledge holon constructively identified through that organization and its whole-level claim-bearing characteristic.
Ordinary assertion, classification assertion, and explicit occurrence use
An ordinary assertion can state that claim content concerns an entity under a scheme without explicitly naming a relation occurrence. For every direct predicate, keep four jobs separate: the direct pattern defines participant meanings, the obtaining predicate, applicability, and the occurrence-identity rule; the current case supplies the facts that satisfy or fail that predicate; the assertion carries affirmative or negative polarity; and a separately governed evaluation or evidence-use relation states supported, refuted, or unresolved reliance when the receiving use needs it. When a receiving relation or claim needs the exact constitution occurrence, inspect the current ClaimGraph, EntityOfConcern, and ReferenceScheme facts against C.2.1's predicate. Only after those facts satisfy the predicate may the participant-determined identity rule individuate the occurrence for designation. The assertion, designation, occurrence, case facts, and reliance judgment remain different objects.
Each classification judgment has one pattern governing its criterion. A.1 governs constructive recognition of a candidate as an instance of an already admitted holon kind. C.3.2 governs a local-kind membership judgment. E.24.UK governs the ontology-level decision that admits a public U-kind; it does not classify a project candidate. None of these judgments is a direct admission relation created by C.2.1.
When project work needs a classification judgment as a separately reviewable claim, identify one claim-bearing episteme whose exact EntityOfConcern is the candidate entity. For an admitted holon kind, its claim content states affirmative or negative polarity for the exact classification predicate, names the kind, cites the A.1 constructive criterion and any kind-specific criterion, designates the direct part-relation occurrences used in the assessment, and cites any evidence-use relations that make supported, refuted, or unresolved reliance inspectable for the declared use. For a local kind, its claim content states the same polarity distinction for the candidate, local kind, selected KindSignature edition, context slice, and judgment governed by C.3.2; its reliance posture remains separate. A value classification inside another claim can remain claim content of that episteme instead of fabricating a value-shaped EntityOfConcern.
The assertion does not create the candidate, admit a U-kind, or make the candidate change kind when an FPF host is renamed or republished. For example, the assertion that Pump #37 satisfies the constructive U.System criterion may be revised when evidence changes, while Pump #37 and the criterion it satisfies retain their independently governed identities.
A card that calls a listed collection a holon is still only a classification assertion episteme. Its assertion polarity is affirmative, but the card alone leaves reliance unresolved for any use that requires A.1 to recover the exact constituents and grounded part relations, their constructive assembly, the whole's reidentification rule, actual compatibility with a governed larger-assembly construction, a composition-grounded whole-level characteristic, and the already admitted holon kind with its kind-specific criterion. The card form supplies none of those facts and does not make the classification predicate true.
The same constitution rule applies when a reader proposes to use an obtaining F.9 Bridge. Say first in ordinary words what the reader proposes to compare, substitute, translate, publish, or otherwise do; name the direction d, use-specific correspondence rule r, tolerated semantic loss t, and affirmative or negative polarity for named use u. Identify that statement as one ordinary C.2.1 assertion episteme: the exact Bridge b is its EntityOfConcern, its ClaimGraph designates <u,d,r,t> and polarity, and its effective ReferenceScheme makes those designations, the rule, and the tolerance interpretable. The exact <ClaimGraph, b, effective ReferenceScheme> triple identifies the assertion. Changing u, d, r, t, or polarity changes the claim content and therefore the assertion episteme, not fixed Bridge b. Keep this local claim form in ordinary wording: it introduces no public U-kind, universal use relation, or durable CamelCase claim name. Reopen F.18 only if an independent later use actually needs a reusable name.
An affirmative bounded-use assertion is one premise for that use; it is neither permission nor proof that the use occurred. A negative assertion leaves an otherwise obtaining Bridge in place. Use A.10 to classify ordinary bounded reliance on the exact evidence-provenance path: pass supports only the named use, degrade supports only its named narrower use, and another disposition supplies no support for the attempted use.
Use B.3 only when an actual named assurance claim about this bounded use is current. That assurance result remains separate from the Bridge-use assertion and adds assessment Work, System, Method, assignment, bindings, witnesses, or a reusable note only when the assurance use depends on those identities. A direct domain rule may require an assurance claim for a consequential use, but neither consequence nor a display creates the claim. Neither the A.10 nor B.3 branch authorizes the use. If the use actually happened, recover the actual Work under A.15.1, assertion episteme under C.2.1, publication occurrence under E.17, direct relation under its domain predicate, operation application under A.6.1, or another result under its own pattern.
State rule-content and subject assertions without pattern ownership
In ordinary prose, cite the PatternID and state the concrete contribution: what the cited content defines, constrains, tests, distinguishes, or helps the practitioner do. This readable branch is normally sufficient. A pattern is neither an owner nor an actor, and no governance relation is implied by an instrumental sentence such as “use A.1 to test constructive holon recognition.”
Open an exact defining or constraining episteme edition or ClaimGraph only when its identity changes interpretation, migration, conflict analysis, publication, dependency repair, or reuse. Then identify the subject, predicate or constraint, polarity, exact defining content, case facts, and only the scope, time, scheme, or bounded-use qualifications that change the assertion. Do not fabricate an assertion episteme merely to avoid an ordinary pattern citation.
Definition or constraint is not actual rule-content use. State derivedUsingRuleContent(dependentContent, baseContent) only when one identified derivation claim used the exact nonempty base subgraph as a formal premise under a declared inference rule. State evaluatedAgainstRuleContent(dependentContent, baseContent) only when one identified criterion-selection claim selected that base for one exact bounded evaluation. Consultation, influence, quotation, provenance, evidence, evaluation Work, and later sufficiency establish neither predicate.
An E.4.PFR row is optional and opens only for a named framework-maintenance, edition-impact, comparison, publication/dependency-repair, or refresh receiver. It represents an already identified assertion; it creates neither the assertion nor a pattern-owner fact.
Address one claim inside an exact episteme edition
U.EpistemeRef is the admitted RefKind for designating one already identified U.Episteme. Under the effective reference scheme of the receiving assertion or description, its resolution method returns exactly one episteme satisfying the C.2.1 identity rule. A value that resolves to none or more than one is unresolved. The reference, its token or serialization, the resolution act, and the episteme remain different objects. Retargeting the reference designates another already identified episteme; it does not revise either episteme.
Use the reusable C.2.1 value ClaimAddress only when a receiving claim or work item needs one exact claim inside a larger ClaimGraph:
The second component is not a printed node label interpreted by the episteme's general ReferenceScheme. It is a claim identity that the exact ClaimGraph itself declares and preserves across its admissible representations. Resolve the edition first, then require that its ClaimGraph contains exactly one claim with that intrinsic identity. Resolution fails when the edition is unresolved, the identity is absent or non-unique, or the token belongs only to one rendering or serialization.
Two ClaimAddress values are equal only when they resolve the same exact episteme edition and the same intrinsic claim identity in that edition. Reusing the same visible token in another edition does not preserve the address. An EpistemeEditionRelation also does not preserve it by itself; a receiving migration rule must state any claim-to-claim correspondence it uses.
When a ClaimGraph declares no stable intrinsic identity for the needed claim, cite the whole episteme or constitute the claim as its own C.2.1 episteme. Do not invent an address from a heading, row number, file location, or display token.
[C.2.1](/generated/patterns/C.2.1) ClaimAddress designates claim content carried by the exact edition. It is neither a U-kind nor a RefKind, turns no claim content into a U.Entity or another U.Episteme, and carries none of the claim content itself. Use U.EpistemeRef for the whole episteme and the admitted reference kind for an independently identified entity or relation occurrence.
Add empirical grounding through its own relation
Tech name: EpistemeEmpiricalGroundingRelation.
Plain reading: these designated empirical claims of this episteme are inspectable through exact observation, intervention, measurement, or test relations involving this grounding holon.
C.2.1 uses explicitly designated partial coverage. For one candidate grounding occurrence, select one exact nonempty claim subgraph C from the episteme's already constitutive ClaimGraph. The occurrence says that every empirical claim in C is grounded; it says nothing about empirical claims outside C. To claim full empirical grounding for the episteme, C must contain every empirical claim in that episteme. Purely formal epistemes need no grounding occurrence merely to fill a record.
For every claim in C, state a concrete claim-to-world mapping under the episteme's effective ReferenceScheme to independently governed direct observation, intervention, measurement, or test relation occurrences involving the exact grounding holon. The mapping names what observation, intervention outcome, measured characteristic, or test result bears on that claim. One measurement involving the same holon cannot ground an unrelated claim.
The selected claim subgraph is by-value predicate content drawn from the episteme's ClaimGraph; it is not a third world-side relation participant, another episteme constituent, or a new U-kind. An assertion about grounding designates that subgraph and the claim-to-world mappings but creates none of the mapped occurrences.
Applying the shared declaration rule in 4.2.1, EpistemeEmpiricalGroundingRelationSignature is one declaration episteme whose exact EntityOfConcern is EpistemeEmpiricalGroundingRelation; the same individual has U.Signature membership and relation-facing RelationSignature use only under A.6.0. Its complete declaration includes the covered-claim-subgraph rule, obtaining predicate, maximal-continuous-interval identity rule, applicability, actual dependencies and provided names, and these participant SlotSpecs:
EpistemeEmpiricalGroundingRelation over participants (E,H), with covered=C, obtains exactly while every empirical claim in exact covered claim subgraph C has a current claim-to-world mapping to the required independently governed direct observation, intervention, measurement, or test relation structure involving H under E's effective ReferenceScheme. Every mapped relation required by that coverage must obtain. An exact direct evaluation relation counts as part of the empirical test only when the mapping states its concrete use in that test; otherwise evaluation and evidence can support or challenge an assertion about grounding but are not its world-side base.
One occurrence is identified by <episteme, exact covered claim subgraph, grounding holon, maximal continuous interval during which the complete coverage predicate is true>. Closing the open end of that interval refines the description of the same occurrence. Demonstrated failure of any required mapping followed by restored complete coverage yields another occurrence. Evidence or evaluation availability alone establishes neither obtaining nor nonobtaining and proves no temporal gap. If the complete coverage predicate is known to obtain, grounding continues without a stored report or work log. If it is known not to obtain, the relation does not obtain. If its truth is unknown, an affirmative grounding assertion has unresolved reliance for the declared use; that posture is not a third world-side grounding state.
The grounding holon need not be identical to the EntityOfConcern. One method-description episteme may have one grounding occurrence for a claim subgraph mapped to exact enactment work and another for a different claim subgraph mapped to the system whose behavior was observed. Each occurrence names its own C, H, and mappings. Sharing one grounding holon makes comparison inspectable but proves neither the same subject, the same claim content, nor coverage of any unlisted claim.
Keep neighboring uses under their direct relations
Names ending in Slot are admissible here only as SlotKinds inside the exact RelationSignature governed by the neighboring direct relation pattern. A card or other episteme form carries participant designations in ordinary fields; it does not acquire SlotKinds by using similar field labels. None of those neighboring SlotSpecs belongs to EpistemeConstitutionRelationSignature.
Relate distinct episteme editions explicitly
Tech name: EpistemeEditionRelation.
Plain reading: this later episteme continues this earlier episteme as an edition under one applicable continuity rule.
EpistemeEditionRelation has exactly two direct participants. Applying the shared declaration rule in 4.2.1, EpistemeEditionRelationSignature is one declaration episteme whose exact EntityOfConcern is EpistemeEditionRelation; the same individual has U.Signature membership and relation-facing RelationSignature use only under A.6.0. Its complete declaration includes the direct predicate, participant-determined identity, applicability, actual dependencies and provided names, and these SlotSpecs:
The relation obtains only when all of these conditions hold:
- the two epistemes have different C.2.1 identities;
- the later episteme actually uses the earlier episteme as the source for the claimed revision, refinement, or supersession;
- one applicable edition-continuity policy or rule states which claim, EntityOfConcern, and effective-reference-scheme features must be preserved, which may deliberately change, and what counts as continuation for this episteme family;
- the exact preserved and deliberately changed features satisfy that rule;
- no failure condition in that rule classifies the case as a fork, translation, retargeting, or independent reconstruction instead.
Work, an enacted Method, provenance, and change results supply case facts. Their labels do not make continuity true. C.2.P may recover the source expression and source-to-revision use; the direct change patterns supply exact changed features. If the continuity claim separately consumes a first-existence fact, apply the shared boundary in 4.9. A missing required rule or fact blocks only that positive edition claim.
One occurrence is identified by the exact <earlier episteme, later episteme> pair. Two revision Work occurrences do not create two edition occurrences for the same pair. The relation is acyclic in its earlier-to-later direction. A renamed file, later publication, shared title, bare provenance edge, or Method named “revision” establishes no occurrence.
Several edition occurrences form a lineage structure only when a receiving use depends on their organization. A separately identified edition collection remains under A.14; collection membership does not establish continuity. PhaseOf may describe one unchanged episteme over a proper interval but does not connect two different C.2.1 identities.
When claim content, EntityOfConcern, or effective reference scheme changes, the later object is another episteme. Apply A.6.4 separately when the current claim is effect-free retargeting between epistemes with different EntitiesOfConcern; retargeting alone does not establish edition continuity. A changed publication form alone identifies neither another episteme nor an edition relation.
Keep descriptions, cards, publications, and representations downstream
A claim-bearing filled card can itself be an episteme when its claim content, EntityOfConcern, and effective reference scheme are recoverable. The reusable arrangement of that card can instead be a publication form, and a selected graphical or tabular element can participate in a C.29 representation. Identify each object through its own constitution and the direct relation in which it participates; visible shape does not determine its kind.
When a card or other form designates the participants of one direct relation, its field labels may correspond to SlotKinds in that relation's RelationSignature, and its field values may be by-value designations or references of the declared refModes. The form is not a filled direct relation occurrence; supplying fields does not make the predicate obtain or provide occurrence identity.
In a relational assertion, the claim graph designates the actual participants and states affirmative or negative polarity for the direct predicate. The direct pattern defines that predicate and the occurrence-identity rule; current case facts determine whether the predicate is satisfied or failed. A forecast, scenario, counterfactual, permission, or another claim family names its exact direct governor rather than using one common catch-all field. Only when an explicit reliance judgment is current for the declared use does A.10 or the receiving evaluation separately state supported, refuted, or unresolved reliance. An affirmative assertion may designate an occurrence only after the case facts satisfy the predicate and the direct identity rule individuates that occurrence; a negative assertion creates no failed world-side occurrence. In a relation-occurrence description episteme, the EntityOfConcern is that exact already individuated occurrence. The assertion and description retain their own C.2.1 identities; neither supplies case facts, obtaining, or the occurrence-identity rule.
Keep the direct verbs with their objects. A designator designates an already recoverable referent. A governed reference resolves to that referent under an effective reference scheme. An assertion or description episteme carries claims and participant designations. A C.29 representation stands in an explicit correspondence to what it represents. A publication occurrence makes a selected episteme edition available; a publication form expresses that edition for the use; a presentation carrier bears the form.
Plain published episteme means one already identified U.Episteme that currently participates as the selected edition in an exact publication occurrence. It is a contingent publication use, not a durable U.EpistemePublication kind and not a second identity for the episteme. The episteme keeps the same C.2.1 identity before, during, and after that availability relation.
A publication occurrence makes one selected episteme edition available to a declared audience for a declared bounded use. A publication form expresses that edition for the publication use. A U.PresentationCarrier bears the form. These are three different direct relations governed by E.17 and E.24.PUB; an assertion that any one obtains is a separate episteme. C.2.1 governs the identity of the selected U.Episteme; it does not replace the participants, predicates, or occurrence rules of those publication relations.
One completed inspection card shows why the distinctions matter. Its filled claims can identify one episteme; its reusable layout can be a publication form; its paper sheet or file can be a presentation carrier; and a publication occurrence can make the selected card episteme edition available to the maintenance team. None of those uses makes the others identical.
When rendering is current, a system performs rendering work and the exact work-participation, transformation, or A.6.1 binding current in that case relates the work to its affected entities. Rendering work, rendered entity, publication occurrence, form, carrier, and episteme retain their own identities. Republishing unchanged claims with another form or carrier creates no new episteme edition; changed claim content, subject, or effective scheme identifies another episteme without requiring a claim about when any entity first existed.
Under C.29, a tuple can represent the identity triple and a graph or hypergraph can represent claim, justification, dependency, or relation structure. U.ClaimGraph and JustificationGraph remain graph-valued epistemic structures. Their nodes and edges remain representation elements. An explicit correspondence can relate one selected representation element to an independently recovered object, but it neither identifies the two nor makes the representation element a participant of the represented direct relation.
Preserve description and meta-description recursion
If episteme E1 describes pump P, P is the EntityOfConcern participant in the constitution relation that identifies E1. If review episteme E2 describes E1, then E1 is the EntityOfConcern participant for E2. The two relations have different triples and therefore identify different epistemes.
An episteme may describe itself when its own identity remains recoverable. Self-reference never closes an assurance argument by itself. Each justification or evaluation path terminates in independently governed evidence, observation, or formal derivation rather than in a cycle of claims that cite one another.
Description and specification use remain distinct. A Description episteme is admitted for specification use only when the E.10.D2 conditions are satisfied: checkable claims and a named harness or validation relation. If the relying use selects a viewpoint, name that describing use and preserve or update its exact selection only when the selection affects reliance. Formal notation alone does not grant specification use or change the episteme's kind.
Locate the change before updating episteme identity
Hand episteme transformations to their subject patterns
Shared identity-inception boundary. Work or transformation can explain how an entity came about, but C.2.1 by itself establishes neither when that entity first existed nor that the work caused its inception. Open this boundary only when a current receiving claim asks whether a new entity began. Then use the subject's direct inception rule: its pattern defines the predicate and identity rule, and current case facts must satisfy them. If no such rule is recoverable, return one missing-governor blocker naming the entity, work and change facts, required inception predicate, and receiving use. When the current question is only changed episteme identity, form, representation, view, or publication, do not open this boundary.
A.6.2-A.6.4 define episteme-to-episteme morphing, source-to-receiving viewing construction, and retargeting. Identify every source and receiving episteme independently under C.2.1 before testing the exact transformation relation. Each transformation pattern states which identity discriminator is preserved or changed and names the exact correspondence, reinterpretation, or retargeting relation on which it relies. When a possible Bridge between exact F.17 cells is current, use F.9 to test whether that relation obtains. If the morphism relies on that Bridge for a proposed use, state a separate C.2.1 assertion with the Bridge as EntityOfConcern and <u,d,r,t> plus polarity in its ClaimGraph, then use A.10 for ordinary evidence reliance or B.3 only when an actual named assurance claim is current; none of those facts makes the morphism application occur. Categorical function, mapping, or tuple notation creates no direct relation occurrence.
For an A.6.3 source-to-receiving viewing construction, the two identified epistemes may retain the same EntityOfConcern while claim content or effective scheme is restricted. E.17.0 alone judges whether the receiving episteme conforms to an exact viewpoint and therefore has dependent U.View membership. Direct authoring or query generation can yield a candidate episteme without an A.6.3 construction, and neither route creates a multi-view family. For retargeting, the EntityOfConcern changes and the case names the exact domain correspondence, retargeting rule, or relation on which it relies. An F.9 Bridge is additional only when the case separately asserts a semantic relation between exact F.17 local senses from different semantic contexts and the F.9 predicate obtains. For a representation transition, the represented episteme may remain unchanged while the C.29 representation scheme and admitted operations change.
Relation and neighboring-object reference
This reference table keeps the neighboring objects and relations visible after the application method. Ordinary prose names only the current object and its direct relation. A sentence such as “Model M concerns Pump P under Scheme S” is sufficient until another use needs explicit empirical grounding, a classification assertion, occurrence identity, edition continuity, publication, or representation correspondence.
Semantic triangle as a didactic projection (informative)
The Symbol-Concept-Object triangle is a teaching projection, not the episteme ontology.
A triangle diagram may be used to introduce expression, meaning, and subject if its caption says that it compresses the C.2.1 episteme ontic. Its corners and arrows are representation elements. They supply no SlotKinds, direct relation occurrences, or identity rules.
This limitation matters in practice. A proof-assistant term, wiring diagram, clinical chart, learned embedding, or verbal explanation can all occupy the Symbol corner while supporting different operations and different losses. Those questions belong to the representation-scheme and transition patterns; one geometric picture does not answer them.
Description and specification-use boundary (normative)
A Description episteme is a U.Episteme whose exact EntityOfConcern is the entity being described. Description does not create a second kind beside ordinary epistemes; it names the current relation and use of one episteme.
For a description use, keep these values recoverable:
When a filled card used to describe the entity has recoverable claim content, EntityOfConcern, and effective reference scheme, it is one episteme carrying these values. Its reusable layout can be a publication form, and the exact sheet or file that bears that layout can be a U.PresentationCarrier. The episteme, form, and carrier are not direct relation occurrences, and none makes a viewpoint, scope, or model-use relation obtain.
Use E.10.D2 to keep the EntityOfConcern, its Description episteme, and specification use distinct. A Description episteme is admitted for specification use only when its claims are checkable and a named harness or validation relation can test them. Preserve or update a selected viewpoint only for the named describing use whose reliance depends on it. The suffix Spec, formal notation, approval appearance, or publication in a repository does not grant that use.
Self-description uses the same rule. If an episteme describes itself, its EntityOfConcern designation resolves to that episteme. If a review episteme describes it, the review episteme has the first episteme as EntityOfConcern and its own claim content and reference scheme.
Episteme morphing, viewing, and retargeting (normative)
C.2.1 governs episteme identity discriminators and neighboring relations. A.6.2-A.6.4 govern transformations between epistemes.
Effect-free episteme morphing
For a morphism from episteme X to episteme Y, state by value:
- which of claim content, EntityOfConcern, and effective reference scheme are preserved, restricted, bridged, or changed;
- which exact viewpoint selection the use names, which exact empirical-grounding, claim-scope, model-use, evidence, or representation occurrences the arrow rule reads, and which endpoint facts it compares; the arrow changes none of those occurrences and makes none obtain or cease;
- which claims in
Yare preserved from or supported byXunder the named morphism, the exact correspondence or retargeting relation governed by that morphism pattern, and anyF.9Bridge that governs cross-context sense use when current; - whether a separate operation application or Work actually produced or changed an episteme, and which direct pattern governs that occurrence.
The morphism declaration and its mathematical arrows are different objects. The declaration is a C.2.1 episteme, normally an A.6.0 FormalSubstrate signature, whose EntityOfConcern is the local mathematical family and whose claim content declares vocabulary, laws, and applicability. One arrow f : X -> Y is a C.29-local mathematical object identified inside that substrate by its exact endpoints, arrow rule or designator, and declared formal equivalence.
The mathematical statement f : X -> Y names no execution. When an exact operation application is current, A.6.1 separately identifies its argument and result bindings. For any precise performed-Work claim, use A.13 to identify the actual performer and A.15.1 to admit the dated Work independently. If that claim must also identify the assignment under which the Work was performed, check that relation separately through F.6. Identify the affected or newly constituted episteme, its C.2.1 discriminators, and any production or change relation under their direct governors. The same arrow may be used in several applications, and an arrow may relate already existing epistemes. No bare result, generic Work result, or universal production relation follows from an arrow or declaration.
A claim that one arrow is suitable for one exact use is another C.2.1 assertion. Its complete claim content names the arrow, use, conditions, and polarity. Evidence and reliance qualify that assertion; they do not identify the arrow or operation application.
Epistemic viewing
A.6.3 governs an exact source-to-receiving viewing construction when one separately identified receiving episteme is constructed from one separately identified source episteme. That construction may preserve the exact EntityOfConcern while restricting claim content or specializing the effective reference scheme. It neither grants U.View membership nor performs work. Direct authoring and query generation can identify receiving epistemes without this construction relation.
E.17.0 independently asks whether one fixed receiving episteme E conforms to one fixed viewpoint episteme P; formally, whether EpistemeViewpointConformanceRelation(E,P) obtains. Only an obtaining relation gives the same E dependent U.View membership. A system may perform viewing, query, authoring, or rendering work, but neither that work nor an A.6.1 result position grants U.View membership or supplies C.2.1 identity.
Empirical grounding continues only while every mapped direct relation required by the receiving episteme's exact covered claim subgraph obtains. Changing publication, current use, evaluator, or evidence alone changes neither the conformance of fixed E to fixed P nor grounding. Several source or receiving epistemes do not automatically form a multi-view family; identify any current collection under C.13 and any selected organization under A.22.
Epistemic retargeting
A.6.4 governs a local class of effect-free arrows r : X -> Y whose exact endpoint epistemes concern different exact entities. It does not admit a durable U.EpistemicRetargeting kind. The A.6.0 FormalSubstrate signature that declares the class, one arrow r, a bounded-use assertion q, a current-case judgement, and any actual operation application remain different objects.
For one receiving use, q states one proposition with affirmative or negative polarity: whether r preserves the named invariant and makes the stated loss acceptable under named conditions. A separate current-case judgement compares exact current facts with that proposition and reports satisfies, fails, or cannot decide. The same r can have different q assertions and case results for different uses without changing arrow identity. A missing deciding fact yields cannot decide, names that fact, and states what would reopen the question; it does not create unresolved assertion polarity or require an assurance record.
Use A.20 only when the proposition is an internal constraint, A.10 only when an evidence-use claim is current, and B.3 only when an actual named assurance claim is current. Otherwise the named predicate and direct facts supply the case judgement. If the case also asserts a semantic relation between exact F.17 local senses, F.9 defines that separate Bridge and its bounded-use claim.
A system may perform exact retargeting work. Identify its enacted method, any exact A.6.1 operation application and binding, affected or newly constituted episteme, and actual change facts separately. The arrow itself performs no work, and the mathematical statement r : X -> Y infers no bare result or universal production relation.
Examples include retargeting from a module to a function it realizes, or from observations to a learned model, when the independently identified source and receiving entities really differ. A Fourier representation change is not automatically retargeting: use C.29 first to decide whether the signal remains the EntityOfConcern and only its representation changes. This test prevents mathematical notation from deciding ontology.
Multi-view description and publication (normative)
C.2.1 identifies each candidate episteme E and each viewpoint episteme P separately. E.17.0 then asks whether E conforms to P; its formal name for that relation is EpistemeViewpointConformanceRelation(E,P). Only when the relation obtains is the same E a U.View under P. For one named describing use, say that the use selects P. Keep E, its EntityOfConcern, the use, and P distinct. Selection changes neither episteme identity nor conformance and does not make E a view. If another receiving use selects an already identified view, name that use and the pattern that defines or constrains it separately.
Several conforming views remain a plurality. Recover an exact C.13 collection only when a receiving use depends on that plurality as a collection. Recover an exact A.22 U.Structure only when the use additionally depends on organization among those views, and state the exact direct organizing relations. A shared EntityOfConcern, package, table, heading set, diagram, or carrier creates neither a view family, a collection, nor that structure.
A.6.3 governs only an obtaining source-to-receiving viewing construction when that history is current; direct authoring and query generation require no such relation. A system performs any viewing, authoring, query, comparison, or repair work. Neither that work route nor an A.6.1 result position grants U.View membership or identifies a multi-view family.
E.17 governs multi-view publication forms and uses, while E.24.PUB governs publication occurrences, forms, and carriers. The same recognized view can participate as the selected episteme in several publication occurrences without changing identity or conformance. Publication establishes no view membership and no cross-view subject relation.
When cross-view correspondence, consistency, realization, trace, or change impact matters, name the exact participants and apply the exact direct subject-relation governor. A C.2.1 assertion or description episteme may carry that claim; it does not make the relation obtain. If no direct governor is recoverable, return an exact missing-relation blocker naming the participants, required predicate and use, and missing governor; do not invent a relation. E.17, a matching heading, graph edge, diagram position, or shared carrier invents no correspondence relation.
Archetypal Grounding — Worked Cases
These cases ground the pattern in practice; only a case that names an obtaining EpistemeEmpiricalGroundingRelation asserts empirical grounding.
Physical engineering
A pump-maintenance specification has a claim graph about exact pump P under a reference scheme that resolves part names, states, units, and measurement procedures. Those three participants identify the episteme. For test bench B, exact covered claim subgraph C_B contains the discharge-pressure-tolerance and leakage claims. Its claim-to-world mapping names the direct pressure-measurement and leakage-inspection relations involving B; a maintenance-interval claim outside C_B is not grounded by those measurements. The grounding relation over (E,B), with covered=C_B, continues for the maximal interval during which every required mapping obtains. If that coverage continues while an evidence archive or inspection-work log becomes unavailable, only a separately governed support, warrant, confidence, or evidence-use assertion may change. A publication occurrence makes the episteme available through a rendered checklist form borne by an exact carrier. For each maintenance or inspection Work recorded by checklist marks, use A.13 to identify the actual performer and A.15.1 to admit the dated occurrence independently. If the checklist account must also identify the assignment under which that Work was performed, check that relation separately through F.6. A separately current assertion that P satisfies the constructive U.System criterion is another episteme about P; renaming or republishing the governing FPF pattern does not change P or create its systemhood.
The classification assertion changes only when its own claim content or reference scheme changes. Pump continuity is judged instead under the A.1 reidentification rule; a changed or unchanged assertion does not establish that continuity.
Medicine
A diagnostic model concerns one patient-state entity or one admitted patient cohort under a scheme that defines observations, measurements, and diagnostic interpretations. For each precise clinical Work claim, use A.13 to identify the actual performer and A.15.1 to admit the dated occurrence independently. If the clinical account must also identify the assignment under which the Work was performed, check that relation separately through F.6. The assignment neither participates in nor performs the Work, and a failed check leaves Work intact. Neither the Systems nor assignments are absorbed into the model's EntityOfConcern. Each EpistemeEmpiricalGroundingRelation identifies the exact covered diagnostic-claim subgraph, grounding holon, mapping to the required current observation, measurement, or test relations, and maximal continuous interval of complete coverage; it grounds no unlisted claim. If a threshold revision changes claim content or the effective reference scheme, that changed discriminator identifies another episteme; moving the unchanged model to another screen changes only the exact publication or representation object that actually changed.
Competence claims, teaching Work, and learner-facing views
When claim-bearing learning, teaching, taught, or learned wording still hides the changed subject or returned result, use E.10.LRN first and return each recovered claim to its direct pattern. A curriculum model concerns an exact competence structure under a scheme that relates exact assessment or performance evidence to competence claims. Teaching, coaching, practice-support, assessment, and learner inquiry may designate different Methods or dated Work occurrences. Recover those objects separately; none is the competence structure or the holder's capability. “Was taught” foregrounds an intervention received, while “learned to perform X” ordinarily foregrounds a capability claim and leaves teacher, self-directed inquiry, practice, tools, peers, and environment underdetermined. One exact admitted course-cohort holon or one exact admitted learning-environment holon may participate in a separate grounding occurrence without becoming the competence structure.
A learner-facing episteme is a U.View when it conforms to an exact learner-facing viewpoint under E.17.0. If it was constructed from the source curriculum-model episteme, use A.6.3 to state that separate viewing relation. For lesson-session or receiving-episteme authoring or construction Work, use A.13 to identify each actual performer and A.15.1 to admit each dated occurrence independently. If an account must also identify the assignment under which that Work was performed, check it separately through F.6. A lesson, public construction, recalled text, score, or observed performance has only the result established by its direct result pattern. If a later claim relies on that result, use A.10 separately to classify the named bounded reliance; none of those items by itself establishes authorship, capability, transfer, or retention. None is required merely to identify the learner-facing episteme from its claims, exact subject, and effective scheme.
Episteme about an episteme
Simulation model M is one episteme. Review R concerns M, so the EntityOfConcern in R is the episteme M, not the physical system modeled by M. Claims in either episteme may cite separately governed evidence-use relations concerning the simulated or physical system. Publishing R does not revise M.
A theory episteme is recognized through its claim-bearing constitution and whole-level inferential characteristics. A textbook publication can make one edition of that theory available, but the publication occurrence, form, and carrier are not constituents of the theory and do not establish its holonhood.
Edition succession
Episteme E1 is the exact source used to produce candidate edition E2. The applicable continuity policy says that the EntityOfConcern remains the same, specified core claims must remain traceable, listed claims may be corrected, and a translation into another reference scheme counts as a derivative rather than an edition. The current case identifies the preserved core claims, deliberately corrected claims, unchanged EntityOfConcern, and source-to-revision use. Those facts satisfy the policy, so the positive EpistemeEditionRelation(E1,E2) assertion is available.
If the same Work instead retargets the claims to another EntityOfConcern, translates them under a rule that the policy classifies as a derivative, or reconstructs similar content without using E1 as source, the edition predicate fails even when the Method is named “revision.” Work, Method, provenance, change facts, evaluation, and evidence remain outside the two-participant relation. Later repackaging or publication establishes neither another episteme nor edition continuity.
Grounded identity across two observations
A morning-observation episteme concerns observed object M under one reference scheme; an evening-observation episteme concerns observed object E under another. The exact direct identity or reidentification pattern for the observed entity must define the predicate and identity rule. The physically testable trajectory and observations supply the current case facts; they may satisfy or fail that predicate but the pattern itself establishes neither result. A separate identity-assertion episteme states affirmative or negative polarity, and exact evaluation or evidence-use relations make supported, refuted, or unresolved reliance inspectable. Only after positive case facts satisfy the predicate may its identity rule individuate an occurrence for designation. If no current direct governor is recoverable, keep reliance unresolved and return an exact missing-relation blocker naming M, E, the required predicate and use, and the missing governor. Even after both designations resolve to the same exact entity, the two observation epistemes need not merge: their claim graphs or effective reference schemes can keep their C.2.1 identities different. A shared label or grounding holon alone establishes neither world-side identity nor episteme identity.
Readable wiring diagram as a proxy
Wiring-model episteme E1 concerns exact harness H under reference scheme S1, which resolves connector designators, pin identities, and connection predicates. A system performs exact diagram-redrawing work; any operation application, binding, or declared result position is governed separately by A.6.1. If only layout changes in a C.29 wiring-diagram representation, identify the exact representation transition and preserved connector, pin, and connection correspondence; E1 remains the same. If instead only an exact publication form, carrier, or rendering changes, identify that E.17/E.24.PUB object and relation; E1 again remains the same. If a connection claim is omitted or the legend changes the effective reference scheme, the changed claim graph or scheme identifies episteme E2. These three branches are settled by the changed object and C.2.1 discriminators; diagram-redrawing work and an A.6.1 result position establish none of them by themselves.
For the C.29 lens-use statement, the target phenomenon is the connectivity of H; the candidate mathematical object is the wiring-diagram representation under its stated diagram scheme; the mapping resolves connector marks and pin marks to the independently identified connectors and pins. A layout-only transition preserves connector identity, pin identity, and connection predicates. An omitted connection loses one predicate, while a changed legend loses the earlier mark-to-connector reference. The diagram remains admissible for maintenance diagnosis only while the connections on which that diagnosis depends are preserved and recoverable; stop that use or return to the source relation structure when they are not. This representation statement does not prove that the diagram is the harness, that visual similarity preserves claims, or that a higher readability score preserves episteme identity.
A readability score can therefore improve while diagnosable connectivity becomes worse. When that score is used as the practical value, apply E.13: name the intended diagnostic value, the readability proxy, and what became worse. Use C.29 and A.6.3.RT for the representation transition and its preserved or lost structure; under the C.2.1 identity rule, a changed claim graph or effective reference scheme identifies another episteme.
Trained or probe-derived representation and tool-using inference
When learned representation is load-bearing and its subject is not already explicit, use E.10.LRN to separate training Work, trained model edition, system-side phenomenon, probe-training Work, decoded rendering, representation relation, and any later inference or capability claim. For any asserted inference or tool-call Work, use A.13 to identify the actual language-model or tool-using performer and A.15.1 to admit the dated occurrence independently. Add F.6 only if the account must also identify the assignment under which that Work was performed. That Work is not the earlier model-training occurrence or the resulting trained model.
First recover a distributed activation pattern as an exact system-side phenomenon observed during the inference Work. A probe's trained decoder or decoded rendering may represent that phenomenon for a declared use under C.29 and A.6.3.RT; causal influence, decodability, or a readable label does not by itself make the activation pattern or its representation a U.Episteme. A probe result or decoded rendering is admitted as an episteme only when recoverable claim content concerns an exact EntityOfConcern under an effective reference scheme. Training loss, probe accuracy, recovered claim content, tool-use success, and deployed-system capability remain different results with different evidence.
Keep the other entities and claims separate through their exact direct relations. A tool-call trace may fill an exact A.6.1 result position or another declared participant position for the call work. If a receiving claim additionally asks when that trace first existed, apply the shared 4.9 boundary; otherwise its result position and work history add no inception claim. If the trace itself carries claims about that work, it may also be identified as another episteme through the C.2.1 triple. An answer entity identified at an exact declared result position and a separately identified evaluation-report episteme can have different kinds and EntitiesOfConcern; neither is a generic work result by wording alone. Tool availability, a successful call, or a high evaluation score establishes neither claim truth nor empirical grounding. When tool integration changes or degrades reasoning, locate the change in the enacted method, inference work, call work, operation binding, representation use, evidence relation, or empirical-grounding occurrence. Reidentify an episteme only when its claim content, EntityOfConcern, or effective reference scheme changed.
Bias-Annotation (informative)
C.2.1 deliberately favors explicit aboutness and interpretation because claims without an exact EntityOfConcern and effective reference scheme are difficult to compare or test. The mitigation is the A.6.REL minimum-current-object rule: ordinary use adds another object only when the reader's next sentence or action requires it, and states that object's direct relation to an already recoverable object.
The pattern also resists representation bias. Formal calculi, diagrams, learned representations, and interactive tools can materially change available reasoning operations, but their convenience or geometry cannot establish subject identity. State those differences under the exact C.29 lens-use or selected transition predicate and use the corresponding pattern descriptions only as locators.
Finally, the pattern has a claim-bearing-holon bias. Decodability alone does not make the decoded entity an episteme. The decoded entity is admitted as an episteme only when claim content, an exact EntityOfConcern, and an effective reference scheme are recoverable and together satisfy the constitution relation.
Conformance Checklist (normative)
- Episteme identity. Claim content, exact EntityOfConcern, and effective
U.ReferenceSchemeare recoverable, and the text states what changes each discriminator. A dependent episteme kind such asU.MethodDescriptionorU.Viewadds a governed membership judgment for the same individual, not another identity discriminator. - Direct constitution and case judgment.
EpistemeConstitutionRelationhas its three identified participants, obtaining predicate, and participant-determined occurrence-identity rule. C.2.1 defines that rule; current case facts satisfy or fail the predicate; an assertion states affirmative or negative polarity; and evaluation or evidence use states reliance only when needed. Designate an occurrence only after positive case facts and the identity rule individuate it. - Declaration identity and Slot discipline. Each of the three named relation declarations is first a C.2.1 episteme whose exact EntityOfConcern is its direct relation kind; the fixed
A.6.0predicate gives that same individualU.Signaturemembership andRelationSignatureis its relation-facing use. Its complete declaration carries the direct predicate, occurrence identity, applicability, exact A.6.5 SlotSpecs, and only actual dependencies and provided names. Signature-local SlotKinds never become participants, and a one-off assertion needs no signature or manifest. - Classification discipline.
A.1governs recognition under an admitted holon kind,C.3.2governs local-kind membership, andE.24.UKgoverns public U-kind admission. A separately current classification assertion is a C.2.1 episteme about the exact candidate; it states affirmative or negative polarity for the exact classification predicate and keeps supported, refuted, or unresolved reliance separately governed. It neither creates the candidate nor changes the kind's admission. - Empirical-grounding discipline.
GroundingHolonSlotoccurs only insideEpistemeEmpiricalGroundingRelationSignature. Each occurrence names one exact nonempty covered claim subgraph and maps every empirical claim in it to the required current direct observation, intervention, measurement, or test relations involving the grounding holon. Unlisted claims receive no grounding from that occurrence. One occurrence is reidentified from the episteme, covered claim subgraph, grounding holon, and maximal continuous interval during which the complete coverage predicate is true; demonstrated coverage failure followed by restoration yields another occurrence. Evaluation counts in the empirical base only when its exact direct relation and use in the test are stated; otherwise evaluation and evidence support or challenge an assertion. Availability or loss of a report, store, or Work log alone neither makes nor unmakes grounding. - Edition discipline.
EpistemeEditionRelationhas exactly the earlier and later epistemes as participants and is acyclic in that direction. Positive continuity requires exact source use, an applicable edition policy or rule, and preserved and deliberately changed claim, EntityOfConcern, and scheme features satisfying that rule. Fork, translation, retargeting, and independent reconstruction are explicit failure branches. Work, Method, provenance, and change facts supply case facts but no label makes continuity true. - View and neighboring-relation discipline. C.2.1 identifies epistemes; E.17.0 alone tests the conformance of fixed E to fixed P and the resulting same-individual
U.Viewmembership. One named describing use may select one exact viewpoint P, but that selection creates no context value, selects no view, and remains separate from A.6.3 source-to-receiving construction. Several views remain a plurality. Recover a C.13 collection only when the use depends on that plurality as a collection, and an A.22 structure only when it depends on their organization. Cross-view claims use the pattern for their direct subject relation or return an exact blocker naming the participants, required predicate, use, and missing defining or constraining pattern. Use E.17 for view or publication form and E.24.PUB for publication occurrence, form, and carrier, not for view membership or correspondence. - Description boundary. The EntityOfConcern and any Description episteme about it remain distinct, including self-description and episteme-about-episteme cases.
- Specification use. Specification force is admitted only when the E.10.D2 conditions obtain: checkable claims and a named harness or validation relation. A selected viewpoint is preserved or updated only for the named describing use whose reliance depends on it. Naming and appearance do not grant specification force.
- Agency, work-result, and identity-inception boundary. Only systems perform authoring, evaluation, revision, publication, viewing, query, redrawing, and use work.
A.6.1declares typed argument and result positions; neither a position nor its binding says when the bound entity first existed. When a current claim asks that question, the subject's direct inception pattern must define the predicate and identity rule, and the exact work and change facts must satisfy them. If no such governor exists, return onemissing-governorblocker naming the entity, facts, required predicate, and receiving use. Otherwise do not open the inception boundary. No morphism, heading, representation, form, bare A.6.1result, generic work result, or universal production relation supplies that fact. - Publication boundary. Episteme, publication occurrence, publication form, view, and carrier keep separate identities. Plain
published epistemenames a contingent relation use, not another durable kind. - Representation boundary. Tuple components, graph elements, schema fields, and notation tokens remain representation elements. An explicit correspondence may relate one to an independently recovered object without identifying the two or changing the represented direct relation's participants.
- Transformation and Bridge-use boundary. A morphing, viewing, or retargeting declaration states which C.2.1 identity discriminators are preserved or changed and names the exact correspondence or retargeting relation used. For cross-context sense use, F.9 separately establishes the exact Bridge; one C.2.1 assertion about that Bridge carries
<u,d,r,t>and polarity; A.10 handles ordinary evidence reliance; B.3 adds a result only when an actual named assurance claim is current; and the direct receiver defines or tests any actual Work, assertion, publication, relation, or operation application. The mathematical morphism performs no work, and none of these objects authorizes another. - Recursive assurance. Self-reference and meta-description do not form a minimal justification cycle; assurance terminates in independently governed evidence, observation, or formal derivation.
- Minimum current object. Readable prose adds no object beyond the current use's dependency and states the direct relation to an already recoverable object.
Common Anti-Patterns and How to Avoid Them
Consequences (informative)
Benefits. Episteme identity becomes stable across carrier and publication changes. Description, empirical grounding, viewing, edition, and representation questions can be repaired locally because each has a direct relation. Self-description and multi-view use need no second ontology. The same pattern works for physical engineering, medicine, learning, formal work, and computational modeling.
Costs. A load-bearing episteme use has a recoverable exact EntityOfConcern and effective reference scheme rather than relying on a title or file. Empirical-grounding and edition claims depend on their own obtaining and identity evidence. Existing record-shaped schemas sometimes need to distinguish their fields from actual relation participants.
Limits. C.2.1 does not decide whether an epistemic claim is true, sufficient, current, or authoritative. It does not prescribe a file format, graph database, proof calculus, or publication layout. Those questions remain with evidence, evaluation, temporal, representation, and publication patterns.
Rationale
Adding empirical grounding, viewpoint, scope, edition, and publication to every identity would instead collapse distinct relations and make ordinary use needlessly heavy.
Separating the episteme from its constitution relation is equally important. The direct relation explains how the identity-bearing participants are organized. The episteme is the resulting holon with a whole-level capacity to carry interpretable claims. A relation declaration is first its own C.2.1 episteme; A.6.0 independently recognizes that same individual as a U.Signature, and RelationSignature names its relation-facing use. Its claims declare the direct relation for typed reuse; an assertion claims that the relation obtains, and a publication occurrence makes a selected episteme edition available. None replaces another.
SoTA-Echoing
These sources discipline different parts of the same working problem; they do not jointly define U.Episteme. Constructional ontology disciplines the separation among accepted constituents, constitutive organization, and resulting identity without turning the relation into work. Rodin disciplines evidence-backed identity across different observations, while the bounded BORO comparison stresses temporal recurrence without supplying FPF construction rules. Formal-language and material-engagement work explains why representation and grounding matter. RDF 1.2 remains a representation standard, while gUFO remains an ontology comparator for relational aspects; neither graph terms nor reifiers establish the direct relation occurrence. PROV-O motivates keeping the earlier episteme, revision work, exact source-to-revision use, actual change or local inception claim, and later episteme distinct while C.2.1 keeps only the two epistemes as participants of the edition relation. Current learned-representation and tool-integration research makes the same separations necessary for computational epistemes. In every case, C.2.1 retains the minimum-current-object rule: add only the object and direct relation needed by the receiving use, without collapsing either into the episteme or its carrier.
Relations (overview)
- Builds on:
A.1for holon recognition,A.6.RELfor direct relation occurrences,A.6.0for independent same-individualU.Signaturemembership and relation-facingRelationSignatureuse,A.6.5for declaration-local SlotSpecs and participant designations,A.7for entity-description distinction, andC.29for mathematical representation. - Coordinates with:
A.3.2forU.MethodDescriptionmembership without a second episteme identity;C.3.2for local-kind membership judgments;E.24.UKfor ontology-level U-kind admission;E.10.D2for Description and specification-use discipline, including selection that creates neither conformance nor membership;A.6.1for typed operation positions and exact current application bindings;A.6.2,A.6.3, andA.6.4for morphing, source-to-receiving viewing construction, and retargeting;A.6.3.RTfor representation transitions;E.17.0for conformance of fixed E to fixed P andU.Viewmembership;C.13andA.22for separately current multi-view collections and structures; the pattern for the exact direct subject relation, or an exact missing-relation blocker naming the participants, required predicate, use, and missing defining or constraining pattern;F.9for exact Bridge semantics when a claim concerns a bounded cross-context use;E.13when a visible representation-quality proxy is used as practical epistemic value;A.2.6for claim scope;A.1.1for bounded model-use structure;A.10andB.3for evidence and assurance;A.14only when a phase or separately selected edition collection is current;C.2.P,A.3.1, andA.3.4when source use, revision method, or actual change is current in edition-continuity evaluation; C.2.1:4.9 only when a local claim separately asks when a new entity began;E.17for multi-view publication forms and uses;E.24.PUBfor publication occurrences, forms, and carriers; andG.11for currentness. - Used by: every pattern that identifies, describes, classifies through an explicit assertion, compares, grounds, transforms, views, publishes, or refers to a
U.Episteme.
C.2.1:End
Epistemic Precision Restoration
Type: C.2 precision-restoration pattern for episteme, publication, source wording, and source-relation wording Status: Stable Normativity: Normative unless a section is explicitly informative
Use this when
Use C.2.P after an E.10 wording check only when one unresolved distinction still prevents the reader from selecting or safely using the direct pattern. The unresolved point must concern a source expression, claim-bearing episteme, publication, publication unit, view, carrier relation, source-to-use relation, or use disposition.
Recognizable situation. A sentence is readable, but it leaves the reader unable to tell whether it refers to claim content, a publication or bounded unit, a carrier or display, a source-bearing relation, or a project-side use of one of those objects.
First useful move.
- Say what the sentence is doing: defining, claiming, instructing, comparing, locating a source, describing a publication, or supporting a project use.
- Recover the one unresolved episteme, publication, source-to-use, carrier, or use-disposition distinction.
- Rewrite the sentence, or hand the remaining claim to the exact pattern that defines, constrains, or tests it. Then stop.
Not this pattern when. If E.10 already makes the exact receiving pattern and its current field recoverable, apply that pattern directly. A clear ordinary phrase needs no C.2.P record. Use A.6.P for a relation problem whose publication or source-expression side is already clear, F.18 for a stable reusable name, A.7 for EntityOfConcern-description-carrier separation, and E.17 or E.24.PUB for an already identified publication relation.
Smallest outputs.
- Direct repair: the repaired sentence plus one plain reason or non-use boundary. No record.
- Compact row: the exact sentence, its function, one recovered kind or relation, the selected wording or disposition, and the reader's remaining use.
- Full check: only when several recovery fields interact, a source-to-FPF use is contested, or a reusable ontological or naming decision is being made.
- Non-use result: reduced-use cue, blocked use, incomplete rewrite, or not triggered.
Changing an FPF pattern is not by itself a reason to use the full check. Use the cheapest product that preserves the live distinction.
Source-expression boundary. External or ordinary prose may be clarified without forcing all of its vocabulary into FPF. If no FPF-governed use is recoverable, keep the phrase as source-local wording, a source-finding cue, or a blocked claim-bearing use.
Source-to-use continuity. Do not close a repair merely by replacing the word source. Name the source expression or selected source episteme, the publication occurrence only when availability matters, the relation or path that carries it into the current use, the permitted use, and the condition that requires return to the source. Keep physical raw material with its constituent, resource-use, supply, transfer, or transformation relation.
Ordinary-language survival. Words such as source, view, support, route, and display may stay ordinary when they make no FPF kind, relation, authority, evidence, gate, work, decision, or reliance claim. Repair by sentence function and consequence, not by trigger word.
What this buys. The practitioner recovers the one distinction that matters without building a second ontology or a second review procedure. The final wording still tells a cold reader what to do and where to stop.
What goes wrong if missed
Episteme-publication-heavy text starts to build a parallel ontology. A generic publication face becomes a U.View, a file becomes an episteme, a dashboard tile becomes evidence, a pattern name becomes a procedure, or a slash list becomes a group kind. A broad word such as source is especially dangerous because it can hide several different recovery fields: an FPF pattern or DRR; a publication field; a document named for source, evidence, architecture, or review use; a reviewed publication, review packet, review record, or review state; a project-side FPF kind and reference named by value; or a relation.
The immediate cost is not only ugly terminology. Engineers and FPF authors start making action, evidence, gate, decision, or engineering-justification claims from the wrong entity, publication, record, relation, or carrier.
What this buys
C.2.P gives one small epistemic precision-restoration move: recover the FPF kind and relation set first, then write wording that preserves the needed distinction without adding another claim. It prevents string-replacement cleanup, keeps FPF-side and project-side episteme and publication work separate, and blocks unclear wording from having FPF-governed use by guesswork.
Successful repair condition. Type-correct wording is not enough. A repair must satisfy the E.2 Pillars, especially P-2 Didactic Primacy, together with E.12 and the register rule in E.10:6.2. It closes only when the text preserves or restores a usable action, a recognition reason that tells the working reader why the distinction matters, or a named FPF pattern application that carries the claim. When Tech and Plain registers are both current, the Tech interpretation remains recoverable and the Plain or didactic line maps back to it. An ordinary or metaphorical Plain line may stay light when it carries no FPF-governed use; if it carries an ontological, evidence, causal, assurance, bridge, gate, work, decision, or use-boundary claim, that claim must be recoverable through the Tech fields, named FPF kind, recovered relation, project-side reference, or disposition. A repair to a Problem frame, recognition text, example, or worked slice is incomplete if it improves typing but hides the working situation, why it matters, or the first useful action; name the applicable FPF pattern when that pattern carries the claim. Overread removal is only half of the repair; the other half is remaining action guidance under the Pillars.
Recovery focus in plain terms. The use being made is one episteme-publication-heavy wording use inside conformant text: the word or phrase, the sentence function it carries, the FPF kind or relation it must recover, and the remaining declared use boundary after recovery.
Primary working user. The first user is a practitioner maintaining conformant FPF-style or project text: an author, reviewer, or engineer-manager who must repair wording without losing ontology. The downstream user is the practitioner who will rely on the repaired pattern or project text in a working situation.
Anti-overread payoff question. A repair is useful only if the text can say in ordinary prose what false downstream interpretation is blocked, what useful action remains, and when the reader must apply another named FPF pattern because evidence, gate, decision, work, assurance, bridge, release, or reliance is current. If the repair blocks an overclaim but leaves no useful action, it is probably becoming ceremony rather than guidance.
Problem frame
FPF already has episteme, publication, view, carrier, presentation, relation, naming, and pattern-application concepts. FPF-governed project, review, draft, pattern, and architecture prose, plus source prose being unpacked for possible FPF use, can still introduce convenient intermediate words that survive into final guidance without their kind and relation set recovered.
The recurring situation is simple: a sentence is understandable enough to feel worth keeping, but its head kind is not recovered. If it is repaired by replacing one broad word with another broad word, the ontology gets worse while the text looks cleaner.
Purpose and Scope
This pattern gives the current glossary and rewrite rules for terms around epistemes, publications, views, publication forms, generic publication faces, MVPK faces under E.17 constraints, carriers, records, and bounded publication units.
It exists because episteme-publication-heavy texts can use locally convenient heads that collapse EntityOfConcern, publication unit, publication face, carrier, record, source relation, and project-side FPF kind and reference. Those words may be useful recognition handles, but they are not safe FPF heads when they carry ontology, authority, or authority-changing meaning.
The rewrite discipline here is ontological and use-facing, not lexical; in this pattern the repair is bounded to episteme, publication, source wording, and source-relation precision:
- do not replace one broad token with one new broad token by string substitution;
- first recover the FPF kind and relation set, whether the wording carries a claim, the publication, view, carrier, or relation construction, and any work, action, or authority crossing;
- then choose the smallest wording that preserves the FPF-governed distinction without creating a second ontology.
This pattern uses the E.10 trigger result as its entry condition, then works in the C.2.1 and E.17 epistemic-publication ontology rather than in a lexical registry.
Problem
Without an epistemic precision-restoration discipline for episteme-publication-heavy wording:
- broad publication words hide which field family is current: episteme or view, publication form or face, bounded publication unit, carrier relation, named document use, review-state use, or project-side FPF reference;
- FPF pattern-application claims and project-side fields for work occurrence, work plan, decision, action invitation, method, record, carrier relation, or front-end relation get mixed in one sentence;
- slash lists and heterogeneous rows become false group kinds;
- unclear source meaning is guessed into FPF-governed wording rather than blocked or assigned to an accepted FPF extension;
- authors copy the same loose wording into
DRRs, patterns, source-relation notes, source-ref target notes, or project texts.
Forces
Solution
Repair episteme-publication-heavy wording by epistemic precision restoration, not by dictionary replacement.
A successful rewrite satisfies these field-validity constraints:
- the head kind and sentence function are recoverable under
E.10; - a stable reusable name has an
F.18naming result; - a relation, comparison, dependency, support, sameness, grounding, mapping, or endpoint claim has
A.6.Prelation precision, with use-boundary and project-side reliance questions split into their own fields; - a claim-bearing episteme, episteme species named by value, episteme-lane view, or project-side FPF kind and reference named by value has the needed
C.2.1typing or named FPF claim or declared-use boundary named by value; - publication, view, face, and carrier distinctions satisfy
E.17.0,E.17, and MVPK; - the repaired text satisfies
E.2Pillars, especiallyP-2 Didactic Primacy, by preserving or restoring one remaining reader use: a usable action, a recognition reason that tells the working reader why the distinction matters, or a named FPF pattern application that carries the claim being made; when both Tech and Plain registers are current, the Plain or didactic line maps back to the recovered Tech kind, relation, or FPF pattern application underE.10:6.2; ordinary Plain wording and intentional didactic metaphor stay light when they carry no FPF-governed use, but ontological, evidence, causal, assurance, bridge, gate, work, decision, or use-boundary claim in a more expressive Plain line must be recoverable through the repaired Tech fields; FPF-governed Problem frames, Problem sections, recognition texts, examples, and worked slices must still show the broad working situation and first useful move, or the rewrite is incomplete; - the final phrase preserves the distinction without adding another claim;
- unrecoverable meaning, kind, register mapping, or remaining reader use fails closed.
The detailed solution below carries the glossary and rewrite rules as ordinary pattern subsections. It is not an external container: these subsections are the pattern's detailed epistemic precision-restoration guidance.
Progressive recovery products
An ordinary application ends with the repaired sentence and one plain reason or non-use boundary. It creates no record.
Use a compact row only when another reader must later inspect the recovery:
Add a source identity, publication occurrence, carrier relation, declared-use boundary, project-side reference, naming decision, evidence relation, or assurance reference only when that exact claim is live. Optional fields do not become a common schema.
Use a full check only when several unresolved fields interact, the source-to-FPF use is contested, or a reusable ontological or naming decision is being made. A full check records the original sentence, the competing interpretations, the selected kinds and relations, the exact neighboring-pattern contributions, rejected overreads, selected wording, remaining reader use, and reopen condition. It does not repeat empty trigger flags or every possible downstream field.
When the wording exposes a field defined elsewhere, name the contributingPattern and the concrete definition, constraint, or test it supplies. The pattern does not own the sentence or act on it.
Carrier-specific recovery. Words such as carrier, file, dashboard, screen, front-end, and rendering are recognition cues. First say what the carrier is being used for. If the next pattern is not already clear, use the compact category-to-contribution route in §4.1.3 for publication, evidence or currentness, generated results, framework packages, Work or reliance, architecture or structure, and base or support questions. Do not close on the word carrier alone.
General Recovery Check
Run this check only after E.10 has left one C.2.P distinction unresolved.
- Name the sentence function. State what the sentence would let a reader claim or do.
- Recover one blocking distinction. Separate source expression, episteme, publication, bounded publication unit, carrier relation, source-to-use relation, or project-side use. Use A.6.P as a separate step only when the remaining problem is relation precision.
- Select the next result. Rewrite directly, write the compact row, perform the full check under its material conditions, or return a non-use result. If another pattern now supplies the needed definition, constraint, or test, name that contribution and stop C.2.P.
Fail closed when the kind, relation, use, or remaining reader action cannot be recovered. A type-correct sentence that no longer shows the working situation or useful action is an incomplete rewrite.
Slash Discipline
In conventional abbreviations, source titles, mathematical notations, standards, URLs, file paths, and ordinary notations, a slash can be part of an accepted designation rather than a hidden FPF kind. In FPF-facing episteme and publication ontology, a slash is still a recovery trigger before it is a synonym marker unless the mark is part of such accepted notation, carrier syntax, or conventional designation.
Before leaving a slash expression in current prose, classify the expression as one of these cases:
- accepted notation or conventional designation: a standard name, source name, discipline abbreviation, established compound name, formula, ratio, fraction, unit, path-like quoted source token, title, product name, file path, URL, or quoted source wording where the slash is part of the accepted designation or carrier syntax; keep
ISO/IEC,ISO/IEC/IEEE,1/2, URLs, conventional abbreviations, and similar forms when the sentence uses them as notation; - a plain-language synonym pair with no ontology, authority, evidence, or use-boundary claim;
- a lazy
and/or-style join that must be split or recovered before FPF-governed use; - a composite-kind candidate that needs
F.18andA.6.Precovery; - a relation claim that needs a
RelationKind, aQualifiedRelationRecord, or a multi-term relation phrase with typed endpoints, slots, qualifiers, scope, time, and viewpoint; - a tuple-like record that needs a named record kind and named slot semantics;
- a failed ontology signal where the sentence lists unlike values because the FPF kind under repair, relation record, relation phrase, tuple-like record, alternative-case disposition, or not-triggered disposition has not yet been recovered.
If the expression is not one of the safe notation, conventional-designation, carrier-syntax, quoted-source, or plain-language cases, do not keep the slash as final wording. Do not repair it by replacing the slash with one equally vague grouped word. Write the recovered FPF kind, relation record, relation phrase, tuple-like record, alternative-case disposition, or not-triggered disposition by value.
Unclear Source Meaning and FPF Extension Candidates
Sometimes the problem is not a bad word but one of two different cases:
- the intended claim cannot be determined from the surrounding source, current
FPFkinds, or current FPF episteme and publication ontology; - the claim is understandable, but current
FPFdoes not yet contain the kind, pattern, relation record, or method guidance needed to carry it.
Do not merge those cases.
An unclear claim is not current architecture truth merely because deleting it feels risky, and it must not be rewritten by guessing a likely author intention.
An understandable uncovered claim may be retained as a candidate FPF extension only when the problem situation, tempting overread, rejected current uses, current FPF gap, and the first user action that would improve are stated by value.
Classify the case explicitly:
- recovered by value: the text now names the current
U.Episteme, selectedEntityOfConcern,U.View, publication form, generic publication face, MVPK face under E.17 constraints,PublicationUnit, carrier relation, relation record, relation phrase, tuple-like record, FPF pattern, document named for source, evidence, architecture, or review use, reviewed publication, review packet, review record, or review state, project-side FPF kind and reference named by value whenprojectSideFPFRefis current. The selected value is one current value, not the list:C.11ChoiceResult;C.11decision record;A.6.Aaction invitation;A.15U.WorkPlan;A.15.1datedU.Workoccurrence;U.Method;U.MethodDescription;A.20constraint or adjudication decision record;A.21GateDecision;A.21DecisionLogRef;A.10evidence path; typed evidence record;B.3AssuranceResult; an engineering-justification result under its direct pattern; typed status record whose FPF status pattern is named; carrier relation; front-end relation; or not-triggered alternative; - understandable FPF extension candidate: the thought is clear enough to state as a candidate new or amended FPF kind, pattern, relation record, method guidance, accepted
DRRcontent decision, or campaign-scoped content question, but it does not carry current authority, evidence, or use-boundary claim until an accepted architecture decision, acceptedDRR, or accepted FPF pattern supplies that authority; - source wording without FPF-governed use: the phrase has no current authority, evidence, or use-boundary claim;
- reduced-use cue: the phrase is kept only as a recognition cue or anti-case, not as a claim-bearing architecture decision;
- blocked use: the phrase is blocked for claim-bearing architecture, pattern, or project text while the needed meaning, kind, or relation is missing.
- rewrite incomplete: the repaired wording may be kind-correct, but it does not yet state a remaining reader use, recognition reason, Tech-to-Plain mapping when both registers are current, or FPF pattern application, or a Plain or didactic line carries ontological, evidence, causal, assurance, bridge, gate, work, decision, or use-boundary claim that cannot be recovered from the Tech interpretation; continue repair or demote to a non-use disposition before the text has FPF-governed use.
These dispositions are recovery results, not a meta-governance authority over all of FPF.
When recovery names another FPF kind, use the pattern that defines or constrains that kind, its declared use boundary, and its conformance checks.
C.2.P may identify that A.10, A.15, A.15.4, A.20, A.21, B.3, C.11, F.9, E.17.EFP, E.17.ID.CR, or another FPF pattern applies.
After that identification, C.2.P no longer defines or constrains the recovered kind.
C.2.P only makes the kind under repair, relation, and use boundary explicit enough to apply the appropriate pattern.
No other disposition is closed. In particular, "seems to mean", "probably about", a cleaner paraphrase, or a broad umbrella replacement is not a successful recovery.
Keep source, return, work, and next-pattern questions separate
When source data or source material is epistemic, identify the source expression and selected source episteme. Add a publication occurrence only when availability matters. Then name the relation or path that carries the source into the current use.
Treat source-use as a cue, not as a relation name. Do not call an endpoint value unless the direct pattern actually declares a value slot.
If the wording also makes a claim about a Method, Work, transformation, evaluation, transfer, or receiving use, use its direct pattern. Use A.6.P.WMR only while the work-side relation or what is being claimed about it remains hidden. Physical raw material stays with its constituent, resource-use, supply, transfer, or transformation relation.
Use source-return only for a reverse or escalation move from a derivative, coarsened, extracted, compressed, rendered, or reused object to a named source. Such a move is current when a stronger use, dispute, freshness change, hidden loss, or missing distinction requires the source again. For ordinary movement from a source into current use, say source-to-use path or name the actual relation. Name a rule-bearing ClaimGraph only when later comparison or reuse depends on the identity of that rule.
C.2.P does not decide whether Work may proceed. Use A.15.4 only after the wording repair shows that a publication, display, or other appearance is being relied on as a reason for intended Work and the exact project-side object or relation is still unresolved. If the direct pattern is already known, use it without an intermediate reliance-repair branch.
Once the remaining question is clear, stop C.2.P and choose the direct branch:
A.6.Pfor relation precision;F.18for a reusable name;C.30.Pfor a hidden architecture or structure distinction;C.16.PorC.16.Qfor a hidden characteristic, scale, or evaluative-quality distinction;- the applicable episteme or publication pattern for an already identified episteme or publication question.
These are alternatives, not a mandatory sequence. C.2.P may expose a naming or authority question, but it neither renames an accepted FPF pattern nor admits a reusable head; use F.18 and the applicable accepted decision source for that change.
Carrier-like words are only recognition cues. Once the category is clear, use one row below and stop C.2.P as soon as that contribution closes the question.
Core Glossary
Cross-Side Fields That Must Stay Split
These fields are current episteme-publication precision vocabulary for DRR, architecture, and pattern-drafting work.
They exist to prevent one sentence from mixing FPF-side use-boundary, project-side records, actual work or action, method selection, carrier access, and authority records.
They are local recovery aids, not FPF kinds, not record kinds, and not a universal record ontology.
Each field closes only by naming the FPF kind named by value, relation record, relation phrase, project-side FPF kind and reference named by value, or explicit non-use disposition that is current in the sentence.
The same local-aid rule applies to neighboring field names such as sourceRelationClass, explanationSourceRelationClass, comparativeRelationClass, representationValidityUseBoundaryValue, allowedUse, misuseRisk, and worldContactPolicy: they help record a local recovery or reader-use boundary, but they do not become kinds. These local fields do not instantiate evidence, gate, assurance, work, commitment, speech act, decision, release, authority, representation kind, world-contact kind, or policy kind. Read allowedUse as a local reader-fit field under declaredUseBoundary, not as permission, evidence relation, or authority.
Episteme, Publication, and Carrier Distinctions
Trigger Boundary
Use E.10:0.2, E.10:0.2a, E.10:0.2b, E.10:0.2c, and E.10:0.2d for lexical trigger scanning and selection of an already known applicable pattern.
This pattern is applicable after that scan only when one C.2.P-specific source-expression, episteme, publication, carrier, source-to-use, or use-disposition distinction is still needed to select or safely use the direct receiving pattern. When the exact pattern and current field are already recoverable, apply it directly.
When this pattern is applicable, do not restart from word taste. Keep the E.10 trigger result as input and recover source-expression clarification, FPF-governed use, current episteme-publication relation set, use disposition, and remaining reader use.
Current Preferred Vocabulary
Use PublicationUnit when the intended entity is a bounded, human-inspected unit inside a publication.
Do not use it for UI behavior, carrier behavior, front-end behavior, file identity, dashboard behavior, or export behavior; use A.7, specific carrier or front-end wording, or the applicable named FPF pattern instead.
Use the current cluster names directly: PublicationUnit Stability Discipline, Local Head Restoration, and PublicationUnit Primary EntityOfConcern Discipline.
When the current entity is a bounded unit inside a publication, use PublicationUnit; when the current entity is authoring or editing work, name that work directly.
Use EntityOfConcern, EntityOfConcernRef, and publicationUnitPrimaryEntityOfConcern when local wording means the EntityOfConcern named by a claim-bearing episteme or episteme-lane view, or the primary entity of concern stabilized by one bounded publication unit over that carried value.
For describedEntity, DescribedEntityRef, primary described entity, EntityOfInterest, or EoIClass, use the exact EntityOfConcern participant, its applicable entityOfConcernRef or EntityOfConcernRef, EntityOfConcernChangeMode, EntityOfConcernClass, publicationUnitPrimaryEntityOfConcern, or the local FPF kind named by value. Use EntityOfConcernSlot only while inspecting the exact reusable C.2.1 constitution RelationSignature; it is not an episteme field. If no claim-bearing episteme or same-individual U.View is current, use a non-claim-bearing kind named by value or plain topic or subject instead of inventing an EntityOfConcernRef.
Use ordinary topic, subject, or local referent only in non-normative explanatory prose where no episteme constitution or neighboring direct relation, publication construction, or authority relation is being asserted.
Do not mint any other reusable FPF name from this pattern alone. The E.17.AUD cluster PublicationUnit Stability Discipline defines and constrains PublicationUnit; this pattern only recovers bounded-publication-unit wording into that head and points to the cluster for its tests. FPF-governed uses keep the nearby definition or explicit publication relation set.
PublicationUnit use and non-use boundary
PublicationUnit means one named, bounded unit inside a publication that a person inspects as one unit: for example, one pattern body, section, table, note, card, sheet, or screen block inside that publication.
Use it when the unit boundary matters to authoring, review, navigation, or a claim about what that bounded unit exposes. Do not use it for the underlying episteme, a view, publication form, whole publication, carrier, file, interface behavior, dashboard behavior, authoring Work, or review process. Name those objects and relations directly.
The bounded unit may carry or expose claim-bearing content, but it is not identical with that content. PublicationUnit keeps the inspected publication-side boundary visible without mixing the unit with authoring action or reader action.
Epistemic Precision Restoration After E.10
Keep the E.10 result as input. Apply C.2.P only while a source-expression, episteme, publication, carrier, or use-disposition distinction is still needed to select or safely use the direct receiving pattern. If the exact pattern and field are already known, apply them directly.
Rewrite execution modes
Direct repair
Use this mode for the ordinary case. Rewrite the sentence and state one plain reason or non-use boundary. No row or note is required.
Example result: “The note helps the reader find section 4.2.” Reason: this is navigation, not evidence or assurance. Stop.
Compact row
Use the five-field row in 4.0a when the recovered distinction must remain inspectable. Add only the optional fact that changes the current claim.
Full check
Use a full check only when:
- several unresolved fields interact;
- the source-to-FPF use is contested; or
- a reusable ontological or naming decision is being made.
The full check records the exact span and function, competing readings, selected kinds and relations, direct pattern contributions, rejected overreads, final wording, remaining reader use, and reopen condition. It is not required because the text is an FPF pattern or because a source is cited.
Publishing the compact row as a local note
When the five-field compact row must remain beside the repaired text, publish that same row as a local note. This changes only its presentation: it adds no fourth execution mode, no extra required field, and no durable FPF record kind.
Completion and reopen boundary
The application is complete when the smallest selected product:
- preserves the E.10 result rather than restarting from word taste;
- names the recovered kind, relation, or non-use disposition;
- hands any remaining relation, naming, publication, evidence, work, decision, or assurance claim to its exact pattern;
- leaves the reader a clear action or stop condition.
Reopen when a replacement head hides another umbrella, a later use adds a material field, the direct receiving pattern changes, or the repair becomes technically exact but hard to use.
Also reopen when an entry cue, summary, dashboard, retrieval snippet, or source note still carries the pre-repair reading. Do not reopen merely because a larger form could be filled.
Archetypal Grounding
Cheap case: ordinary reader help
Starting sentence: “The note supports the reader.”
Questions: What does the note let the reader do? Does the sentence claim evidence, authority, gate passage, work permission, or assurance?
Result: It only helps navigation. Rewrite: “The note helps the reader find section 4.2.” The recovered function is ordinary reader help. No FPF kind, relation, compact row, or full check is needed. Stop after the sentence.
Mixed case: display and decision
Starting sentence: “The dashboard approves launch.”
Questions: Is the dashboard the decision, or does it display one? Which exact project object carries the approval claim?
Result when a decision exists: “The dashboard shows GateDecision GD-17 for release candidate R; the decision, not the display, records that the gate passed.” E.17 and E.24.PUB keep the dashboard on the publication side; A.21 supplies the gate-decision meaning. The reader may find and cite GD-17, but must use the direct release or permission rule for launch. Stop.
Result when no decision resolves: “The dashboard is only a cue; launch approval is unresolved.” Block approval-bearing use until the exact decision exists.
Boundary and Anti-Cases
Transfer Coverage
C.2.P is intentionally narrow but must transfer across three recurrent publication situations:
- FPF-side drafting: pattern text, DRR text, source-relation notes, review-use notes, and pattern draft prose;
- project-side publication: dashboards, explanations, cards, documents, front-ends, rendered files, and generated summaries used around evidence, work, gates, decisions, assurance, or methods;
- external source-expression clarification: seminar fragments, papers, reviews, standards, and tool outputs being clarified before possible FPF use.
In all three situations the same invariant holds: before accepting the wording as current FPF text, recover the distinction between source wording and current FPF wording, claim-bearing episteme, publication construction, carrier-relation construction, relation-like slice, the applicable neighboring pattern for any non-C.2.P field, and remaining reader use.
Bias-Annotation
Conformance Checklist
Current Scan Boundary
Use E.10:0.2, E.10:0.2a, E.10:0.2b, E.10:0.2c, and E.10:0.2d for lexical trigger scanning.
C.2.P conformance begins only when the E.10 result is epistemic precision restoration required or combined precision restoration required and one C.2.P distinction remains unresolved. This same condition covers non-FPF source text being unpacked before possible FPF transfer; source status creates no separate entry branch.
Do not copy the E.10 trigger list into this pattern as a second registry. Use the E.10 result as input and recover source-expression unpacking mode, FPF-governed use mode, current episteme-publication relation set, use disposition, and remaining reader use. When the relation-bearing slice is current, A.6.P remains a separate required precision-restoration pattern.
Common Anti-Patterns and How to Avoid Them
Consequences
Operating consequence
For each repair:
- start from the sentence's function and practical consequence, not from a word list;
- preserve the E.10 result and recover only the one still-hidden episteme, publication, carrier, source-to-use, or use-disposition distinction;
- use the direct pattern as soon as it is known;
- choose direct repair before a compact row, and a compact row before a full check;
- keep the final sentence readable to a cold practitioner and state what action or non-use remains;
- reopen only when a material field or use changes.
Do not perform global lexical replacement. Do not treat every FPF pattern edit as a full epistemic-restoration case. Do not retain a compatibility field whose only function is to remember a previous internal schema.
Rationale
FPF already contains the relevant ontology. The recurring defect was not lack of concepts but ad hoc wording that bypassed them: source, target, display, object, host, route, supported use, and similar trigger terms packed several FPF kinds and relations into one convenient phrase; they are examples of wording to unpack, not current replacement vocabulary.
The correct repair is therefore not a new umbrella. Start with E.10, then use only the pattern whose field remains unresolved: F.18 for a reusable name, A.6.P for relation precision, and A.7, C.2.1, E.17.0, E.17, or MVPK for the relevant EntityOfConcern, episteme, view, publication, or carrier distinction. C.2.P stops as soon as the direct pattern and field are known.
Because every normative FPF pattern must satisfy E.2, epistemic precision is not a value apart from P-2 Didactic Primacy. A stricter repair has not landed if it turns reader-facing problem text into a kind inventory with no working situation or first useful move. The remedy is recognition wording whose claim remains recoverable through the Tech interpretation or a named FPF pattern application, with a declared-use boundary when that boundary matters.
The detailed rules remain in ordinary pattern sections, so the pattern is usable as FPF guidance rather than as an external glossary container.
SoTA-Echoing
C.2.P does not claim to replace semiotics, terminology science, document engineering, or ontology engineering. Its claim being made is narrower: episteme-publication-heavy conformant text must recover accepted FPF kinds and relations before it is rewritten, so that episteme, publication, view, carrier, naming, relation, and project-side records are not replaced by ad hoc words.
A full external SoTA comparison is not needed for this bounded architectural precision-restoration pattern. A reduced external practice set is still required to check terminology drift and epistemic precision restoration. It sharpens only the recovery discipline, creates no new ontology, and does not outrank the FPF patterns named below.
In this section, SoTA-Echoing means compatibility with current FPF ontology and selected external practice anchors, not that those anchors are sufficient SoTA for every field. ISO terminology entries are standards anchors for designation practice; SHACL-style validation is only a fail-closed constraint analogy; word-sense and ambiguity-resolution practice is used only for context-sensitive sense recovery. If one of those domains becomes the object of a future claim, use its current SoTA pattern or source review.
External-practice boundary. External traditions enter only through the local FPF invariant named by value they sharpen. Object-oriented modeling and OWL-style ontology modeling do not become the default repair for vague FPF wording. Architecture-description standards help keep views, viewpoints, concerns, and descriptions explicit. Explainability and NLP faithfulness work helps prevent explanation laundering. RAG evaluation helps separate retrieval evidence, source availability, and answer trust. Quality-diversity and multi-objective search help avoid premature scalarization in candidate selection. None of these traditions becomes FPF ontology, FPF authority, or a universal pattern-quality benchmark.
Relevant FPF Patterns
The current FPF corpus already has patterns that contribute to this discipline:
E.10supplies the head-kind, term, morphology, register, and forbidden-umbrella discipline.E.10.D2gives the "thing vs words vs rules" discipline and the carrier humility rule.F.18gives the local-first naming protocol: governed value and kind; the pattern and contribution that define or constrain them; by-value scheme; local-sense claim; intended use; candidate comparison; and any separately obtaining relation.A.6.Pgives the relation-precision restoration method: restore generic head kind, build candidate sets for endpoint kinds and relation kinds, select kind-explicit slots and qualifiers, then allow guardrailed wording.C.2.1gives episteme identity through exact claim content, EntityOfConcern, and effective ReferenceScheme and keeps empirical grounding and edition continuity as distinct direct relations.A.7keeps EntityOfConcern, Description episteme, and publication carrier distinct.E.17.0,E.17distinguish views, viewpoints, MVPK faces, publication forms, and publication projections.A.15.4shows how to keep an encountered publication, display, or low-articulation cue distinct from the project-side FPF kind and reference used for work or reliance.A.16,A.16.0,A.19,B.2.5,C.27, andA.3.3provide the movement, control, and temporal machinery used when episteme-publication prose talks about route, trajectory, movement, cadence, or dynamics.E.19already treats terminology and sentence-level precision restoration as required review checks, not editorial polish.A.6.Acarries action-invitation discipline when a publication, representation, or cue invites an action without itself becoming authority, evidence, gate passage, or work completion.C.11carries decision-making and decision-record discipline when the question under repair is a decision rather than generic action.A.15andA.15.4split system-role kind and assignment, Method, WorkPlan, and actual-Work alignment from appearance-based reliance repair; do not useA.15as a universal repair for episteme-publication wording.E.9is the campaignDRRpattern for campaign-level content decisions;E.11is only for entry-discoverability situations and must not organize an episteme and publication repair by default.
These internal FPF patterns remain primary:
This reduced external-practice set changes the Solution in one practical way: epistemic precision restoration cannot close merely because the replacement sounds cleaner. The FPF kind, relation, declared use boundary, and any needed pattern application must be recoverable by value; otherwise the wording is blocked or becomes a candidate for a separate FPF-kind decision.
E.19 Review Profile Carry-Through
Run PCP-TERM when the repair changes episteme-publication-heavy naming, umbrella words, slash compounds, trigger-word replacements, or relation wording.
Run PCP-BRIDGE when the repair imports terms, claims, norms, or authority expectations between named sources, practices, disciplines, reference schemes, publication forms, or project record kinds.
Run PCP-ENTRY only when the repair changes which FPF pattern a working reader should apply in a problem situation. Do not use PCP-ENTRY as a substitute for the epistemic precision restoration itself.
Run PCP-PRAG when the repair changes reader action, practical payoff, or what the working reader can safely do next. A type-correct but inert repair fails this line even when every recovered kind is technically right.
When the repair changes evidence, proof, witness, grounding, explanation, gate, release, or engineering-justification claims, apply the relevant FPF pattern (A.10, E.17.EFP, A.20, A.21, B.3, or another applicable pattern) and select the current E.19 profile by the changed claim. Do not mint a local evidence-review profile inside C.2.P.
Relations
- Builds on:
E.2Pillars, especiallyP-2 Didactic Primacy;E.10,E.10.ARCH,A.7,F.18,A.6.P,C.2.1,E.17.0,E.17, MVPK, andA.6.A. - Coordinates with:
E.6,E.7,E.8,E.9,E.12,E.19,A.10,A.15,A.15.4,B.3,A.20,A.21,A.6.F,A.6.P.WMR,A.6.3.CSC,A.6.3.CR,A.6.3.RT,C.30.P,C.16.P,C.16.Q,E.17.EFP, andE.17.ID.CR. - Does not replace:
E.10general lexical rules,F.18naming protocol,A.6.Prelation precision, or local episteme and publication patterns. It says when those patterns must be applied to episteme-publication-heavy wording.
C.2.P:End
Reliability R in the F–G–R triad
Reliability (R) is a conservative, evidence-bound warrant signal for a typed claim under an explicit claim scope (G). When reuse changes scope, kind, reference plane, notation, source-local meaning, model-use basis, or evidence basis, name the actual relation or operation and route only its declared congruence loss to R.
Type: Architectural (A) Status: Stable
Problem frame
KD‑CAL asks a simple operational question: “Where can I safely use this claim?” FPF answers with a minimal “epistemic location” built from three coordinates. Any relations traversed by a justification path are named separately:
-
F (Formality) describes how the claim is expressed and how strongly it supports verification workflows (C.2.3).
-
G (Claim scope) describes where the claim is asserted to apply as a set-like object (A.2.6).
-
R (Reliability) describes how strongly the claim is warranted by linked evidence under that scope.
-
CL / CL^k / CL^plane (Congruence Levels) describe fit or loss for the relation families that define them—for example, a semantic relation, kind relation, or reference-plane relation (B.3, C.3, F.9). A CL value belongs to the declared relation or traversal used by the path, not to the claim as a fourth coordinate. Shared wording about a "context" creates no relation and no loss value. In practice, the triad is frequently used before it is made explicit:
-
Authors implicitly “average” disparate evidence and report a single confidence.
-
Teams treat higher formality (F) as if it automatically implies higher warrant (R).
-
Scope growth is smuggled in through phrasing instead of explicit scope operators (A.2.6).
-
A claim or its evidence is reused after a change of scope, kind, plane, notation, source-local meaning, model-use basis, or evidence basis without naming the actual relation and routing its declared loss into R.
This pattern makes R explicit in KD‑CAL and fixes the triad discipline required by Kind‑CAL (C.3) and the Trust & Assurance calculus (B.3).
Problem
FPF needs a reliability coordinate that is:
- Auditable. A reader can trace R to concrete evidence and see how reuse penalties were applied.
- Composable. R can be propagated through claim graphs conservatively, without illegal scale arithmetic.
- Orthogonal. R is not conflated with F (expression) or G (scope).
- Relation-aware. Any loss declared by an actual scope-translation, kind, plane, notation, source-local, model-use, or evidence-reuse relation is explicit and affects R only.
- Minimal. The solution does not introduce new core types or new face-kinds.
Forces
Solution
Canonical triad relation
Definition DEF‑C2.2‑1 (Epistemic location).
An epistemic location for a claim c is the tuple:
Loc(c) = ⟨F(c), G(c), R_eff(c)⟩
where:
F(c)is Formality (C.2.3), treated as an ordinal.G(c)is Claim scope (A.2.6), treated as a set-like scope object.R_eff(c)is Effective reliability forc, treated as a ratio-scale scalar in[0,1](or an ordinal proxy at [M‑0/M‑1]; see §4.5.A).R_effis computed pathwise (DEF‑C2.2‑3): when more than one admissible justification path exists, publish multiple path records (PathId rows) and cite which PathId(s) a guard/decision consumed (see §4.8.A / G.6). Any collapse to a single scalar is an explicitly declared Γ‑policy (no implicit averaging).
A location always concerns one exact claim. G carries its U.ClaimScope; any stance, reference plane, effective scheme, model-use basis, working situation, evidence basis, or validity window is stated separately when it changes interpretation or use:
- No generic
Kor Context value is part of epistemic-location identity; the exact subject-specific values above remain independently governed. S ∈ {design, run}is the claim’s stance carrier (no DesignRunTag chimeras).ReferencePlaneis declared where applicable; plane crossings applyCL^planeand penalize R only.- When the claim is published on the Working‑Model surface, the author also declares
validationMode ∈ {postulate, inferential, axiomatic}(E.14 / B.3).
Mode-to-lane hint (informative). validationMode sets the default expectation for which assurance lane carries the initial support load (B.3.3 or B.3.5).
It does not add a new characteristic and does not change the meaning of R:
axiomatic→ VA-dominant (constructive grounding or proof carriers); ifReferencePlane=world, LA may still be required.inferential→ VA+TA-dominant (reasoned chain + typing/alignment assurance); LA is optional and scope-bound.postulate→ LA-dominant (empirical validation with freshness/decay); VA is optional. In all modes, R remains warrant, not ontological truth; “proof ⇒ R=1 in the world” is a category error.
Profile note (informative; fold compatibility). Some profiles treat empirical R as N/A for strictly axiomatic lines and use a tagged proxy R_proxy := F (line=formal) for folding, as an explicit proxy rather than an implicit “F⇒R” rule (B.1.3).
⟨F,G,R⟩ is an assurance tuple, not a U.CharacteristicSpace; do not draw “trajectories” in ⟨F,G,R⟩.
What Reliability R means in KD‑CAL
Definition DEF‑C2.2‑2 (Reliability as warrant).
R is a conservative, evidence-bound indicator of how strongly the claim "holds as stated" under its declared U.ClaimScope and the separately named evidence and use conditions. It is interpreted as warrant strength, not as truth.
Prophylactic clarification.
- A higher
Rmeans “the evidence and its relevance supports relying on this claim under this scope.” - A higher
Fmeans “the claim’s form is amenable to higher-formality checking and wider reuse,” but does not itself imply the claim is warranted. - A larger
Gmeans “the claim applies to more cases,” but does not itself imply the claim is warranted in those cases.
Pathwise weakest-link propagation (series vs parallel)
KD‑CAL’s default Γ‑fold is weakest‑link on the entailment spine (the premises/lemmas actually needed), computed per justification path. It is conservative, monotone, and auditable.
Definition DEF‑C2.2‑3 (Pathwise weakest-link fold).
Let P be a justification path for claim c. Let SpineClaims(P) be the required supports on the entailment spine, and let SpineRelations(P) be the exact scope, kind, plane, notation, source-local, model-use, or evidence-reuse relations actually traversed on that spine.
Define the raw warrant of the path as:
R_raw(P) = min_{i ∈ SpineClaims(P)} R_eff(i)
and compute the effective warrant of the path by applying congruence penalties (see §4.5 for policy shape):
R_eff(P) = Π(R_raw(P); Φ(CL_min(P)), Ψ(CL^k_min(P)), Φ_plane(CL^plane_min(P)))
Spine discipline. The min is taken over the entailment spine only (no satellites, no “nice-to-have” citations).
This matches the KD‑CAL propagation rule (C.2:4.3) and the Trust & Assurance skeleton (B.3): weakest-link on the spine, penalize only by the worst (lowest) congruence encountered on the path (no averaging).
Parallel support (optional, declared).
If the same claim c has multiple independent justification paths {P_j} (OR‑style support), the default is:
R_eff(c) = max_j R_eff(P_j)
Independence is recorded as an explicit note (e.g., separate rigs/datasets/proof lines), per CC‑C.2.2‑10 and the KD‑CAL composition rule (C.2:4.3).
If the “multiple paths” actually cover different scope slices, do not use max to hide weaker slices; instead publish distinct G_path (SpanUnion‑style coverage) and keep per‑path R_eff traceable (A.2.6 / C.2:4.3).
Conflict detection (no averaging).
If the evidence graph supports both p and ¬p with overlapping scope, do not average. Separate the claims by the exact source, scheme, scope, model use, situation, or evidence basis that distinguishes them, or mark the claim provisional with explicit conflict edges until resolved.
Relation-specific congruence penalties route to R only
A reused claim may traverse more than one independently governed relation. Before calculating R_eff, state what actually changed and use the rule for that change. A.2.6 owns claim-scope operations; C.3/C.3.3 owns kind relations; F.9 owns a semantic Bridge between exact local-sense cells; notation, reference-plane, model-use, and evidence-reuse relations keep their own definitions. None is a universal crossing relation.
Invariant INV-C2.2-1 (R-only penalty routing). For each traversed relation r whose rule declares a congruence loss:
F_out = F_in
G_out = translate(r, G_in) only when r is an applicable A.2.6 scope translation; otherwise G_out = G_in
R_out ≤ R_in, with the exact penalty determined by r and the cited policy
A scope translation may narrow or re-express G; it never widens the claim silently. A change in formality is a new episteme or explicit ΔF move, not a transport penalty. A semantic Bridge changes neither kind nor scope by itself. A kind or plane relation supplies no semantic correspondence unless that separate relation also obtains. Evidence reuse changes warrant only through its own evidence-use or reliance claim.
There is no implicit crossing. If a reuse depends on a changed value and its required relation or operation is absent, unresolved, or outside its applicability, the reuse is non-conformant. This keeps guard macros simple: each path records the relations it actually traverses and routes their declared losses to R, while every other coordinate changes only under its own rule.
Worked micro-example: scope revision and evidence reuse
A materials-lab claim says:
c_lab:"Adhesive X retains ≥85% tensile strength on Al6061 for 2 h at 120–150 °C."
Its declared scope is G_lab := {substrate=Al6061, temp∈[120,150]°C, dwell≤2h, evidenceWindow=1y, rig=Calib-v3}. A plant engineer proposes a narrower claim for Plant B. Two different moves are required.
- State the plant claim and its scope. Under A.2.6 the engineer explicitly narrows the temperature interval to
[122,148]°Cbecause the plant calibration rule reports a ±2 °C bias. This changesG; it is not an F.9 semantic Bridge and is not inferred from the words "lab" and "plant". - Judge reuse of the lab evidence. The exact A.10 or B.3 evidence-use and reliance claim names the lab evidence, plant claim, calibration edition, validity window, and intended use. If that relation's declared fit is
CL=2under policyΦ_v1, computeR_eff := max(0, R_lab − Φ_v1(2)). The penalty reduces warrant; it does not perform the scope edit.
If lab and plant use distinct local meanings for a material term, F.9 separately tests a Bridge between their exact F.17 cells. Its semantic loss is not the calibration correction or the evidence-reuse result. A further safety narrowing to [125,145]°C is another explicit A.2.6 ΔG− decision.
The example therefore preserves one simple rule: name each changed value and relation once, change G only through the scope rule, and reduce R only through the loss rule that actually applies.
Effective reliability under transport (policy-defined, monotone, bounded)
When a claim is reused through declared relations, R_eff is computed by applying the penalties those relations assign to their congruence levels.
Definition DEF‑C2.2‑4 (Effective reliability under transport). Let:
CLbe the congruence level declared by the applicable scope, semantic, notation, model-use, or evidence-reuse relation (B.3 and its direct subject pattern).CL^kbe the congruence level of an applicable kind relation (C.3/C.3.3).CL^planebe the congruence level of an applicable reference-plane relation (B.3 / plane patterns).
Let Φ, Ψ, and Φ_plane be policy-defined, monotone, bounded, table-backed penalty policies applied on the relevant edges:
Φ(CL)— penalty declared for the applicable scope, semantic, notation, model-use, or evidence-reuse relation.Ψ(CL^k)— penalty declared for an applicable kind relation.Φ_plane(CL^plane)— plane-crossing penalty whenReferencePlanediffers.
Important (direction of monotonicity). Congruence ladders are “polarity up” (higher CL = better fit). Per CC‑G0‑Φ and the Trust & Assurance skeleton, penalty tables are monotone decreasing in their CL ladders (if CL1 < CL2 then Φ(CL1) ≥ Φ(CL2), analogously for Ψ and Φ_plane) and bounded so that R_eff remains within [0,1] after clipping. Penalty magnitudes are not required to lie in [0,1] (tables may exceed 1 to force R_eff → 0 under the subtractive default); what matters is monotonicity, boundedness, and published policy identifiers.
Define:
R_eff(P) = clip_0^1( Π(R_raw(P); Φ(CL_min(P)), Ψ(CL^k_min(P)), Φ_plane(CL^plane_min(P))) )
where each *_min(P) is the lowest congruence level encountered on the entailment spine of P for that dimension (a bottleneck; no averages), and clip_0^1(x) truncates to [0,1].
Default (safe) instantiation (subtractive). When policies are expressed as subtractive penalties, a safe default is:
R_eff(P) = max(0, R_raw(P) − Φ(CL_min(P)) − Ψ(CL^k_min(P)) − Φ_plane(CL^plane_min(P)) )
This generalises the B.3 skeleton to multiple congruence ladders (scope vs kind vs plane) without introducing new penalty characteristics. If a dimension is not present on the path, its penalty term is treated as neutral (0 in the subtractive default).
Provisional marking.
Default admissibility thresholds for reuse are set by the relevant relation-calibration profile (e.g., G.7). Typically, CL=1 requires an explicit waiver to proceed and CL=0 is inadmissible; this pattern only specifies that such thresholds gate reuse before any numeric penalty is meaningful.
Math-by-level gating (B.1.3:4.3)
- [M‑0/M‑1] allow ordinal comparisons only (no arithmetic on
R_eff); Φ/Ψ/Φ_plane may be qualitative (“low/med/high”). Publish evidence links + lane tags. - [M‑2/L1] numeric
R_effrequires referencing numeric, table-backed policy identifiers for Φ/Ψ/Φ_plane (and Π if not default), plus reproducibility tags for empirical legs; otherwise treat the claim as [M‑1] semantics.
Evidence lanes are not new characteristics
KD‑CAL does not add new global coordinates beyond F–G–R. Instead, it requires that reliability be explainable via assurance lanes (B.3.3):
- TA (Typing assurance): semantic/type alignment sufficient for transport and composition.
- VA (Verification assurance): logical/algorithmic checking, proof, model checking, static guarantees.
- LA (Validation assurance): empirical adequacy under declared conditions, tests, benchmarks, telemetry.
Lane reporting is how KD-CAL supports the common research distinction between logical soundness and empirical adequacy without introducing new global characteristics. Lanes remain separable in SCR/Notes; they are not averaged into a “single tradition score”.
Scope operations are kind-safe (and use the ClaimScope algebra)
Reliability is meaningless if scope operations are applied to ill-typed entities.
Well-formedness constraint WFC‑C2.2‑1 (Type before scope).
Let G1 and G2 be claim scopes for claims about entities of kinds K1 and K2. A scope operation that combines them—such as G1 ∩ G2 for serial intersection or SpanUnion({G_i}) for parallel coverage—is defined only if:
K1 = K2; or- an exact C.3/C.3.3 kind relation or cast makes the operation well typed for these participants and this direction.
An A.2.6 scope translation changes G only under its own rule. A kind relation does not translate scope. If distinct source-local meanings also matter, an actual F.9 Bridge and its bounded-use claim are separate; neither repairs an ill-typed scope operation.
This constraint prevents “type-by-scope” anti-patterns where scope manipulation is used to hide type mismatch.
Minimal authoring recipe
A minimal, conforming KD‑CAL authoring flow for reliability is:
- Fix the typed claim. State the claim as a typed proposition about a EntityOfConcern (Kind‑CAL, C.3).
- Declare claim scope. Write
Gexplicitly using A.2.6 operators; avoid scope-by-wording. - Declare interpretation conditions. State design or run stance,
ReferencePlane, effective scheme, model-use basis, working situation, andvalidationMode ∈ {postulate, inferential, axiomatic}only where each changes this claim or its use.Galready carries claim scope; do not add a generic Context identifier. - Bind evidence. Attach evidence stubs and lane tags (TA/VA/LA) and validity windows / decay policy where applicable (B.3.3, B.3.4).
- Choose Γ-mode. Declare whether the support is series (required) or parallel (independent lines to the same claim).
- Compute R_raw. Use the weakest-link fold on the entailment spine; for parallel support, use
maxonly with an explicit independence note. - Name actual relations on reuse. Use A.2.6 for an applicable scope translation, C.3/C.3.3 for a kind relation, F.9 for a semantic relation between exact local-sense cells, and the direct pattern for notation, plane, model-use, or evidence reuse. Record the fit or loss declared by each traversed relation. If a required relation is absent or unresolved, stop that reuse; a generic cross-context Bridge cannot substitute for it.
- Compute R_eff. Apply the declared penalty policies into
R(never intoForG), and publish⟨F,G,R_eff⟩with traceable references and policy identifiers.
A reliable claim is not a loud claim; it is a claim that can be carried.
Authoring template: Path summary row (copy/paste)
When publishing R_eff for a claim, authors SHOULD include a compact, claim-local path summary. This is intentionally shaped so it can be turned into tooling later (EvidenceGraph/PathId in G.6) without introducing new Core types or face-kinds.
Notes:
CL_*_minvalues are bottlenecks on the relevant path/dimension (no averaging).valid_untilis the earliest expiry across empirical legs (or—/ “fenced to TheoryVersion” for non-decaying proof legs).- If you publish multiple admissible paths, include multiple rows and cite which PathId(s) your decision/guard consumed.
Archetypal Grounding
Informative; non-binding.
System illustration
System. A brake controller S has a claim:
c1:“For road friction μ ∈ [0.2, 0.9] and vehicle mass m ∈ [900, 2200] kg, wheel slip stays in [0.05, 0.25] under ABS control.”
-
F(c1)=F5because the controller and constraints are expressed as a machine-checkable model plus executable test harness (C.2.3). -
G(c1)is the declared operating envelope (A.2.6) as a product set in(μ, m, speed, tire)space. -
Evidence:
- VA: model-checking of a simplified plant/controller model (strong, but only for the simplified plant).
- LA: HIL simulation + track tests under sampled conditions with recorded telemetry windows (freshness required).
- TA: typed alignment between “μ” in simulations, “μ” in the estimation pipeline, and “μ” inferred from real-world sensors.
If track telemetry is used as evidence for the road claim, establish the exact A.10 or B.3 evidence-use and reliance claim, including the road claim, telemetry edition, operating scope, validity window, and intended use. Apply only the fit or loss declared for that evidence reuse; G(c1) changes only through a separate A.2.6 scope revision.
Episteme illustration
Episteme. A paper asserts two claims about an algorithm A:
c2:“A terminates for all inputs in domain D.” (axiomatic / proof-carrying)c3:“A achieves ≥ 0.92 F1 on dataset family F under deployment preprocessing P.” (empirical)
c2 can achieve high VA with a proof carrier; its LA lane may be N/A, but its TA lane remains relevant because the intended meaning of “domain D” must align with the implementation’s input model.
c3 requires LA evidence and a freshness or shift policy because dataset and preprocessing drift can change both scope and warrant. For production use, state the exact dataset/preprocessing relation and the A.10 or B.3 evidence-reuse claim, then apply its declared loss to R_eff; change G separately if the production claim has another scope.
Bias-Annotation
Informative; non-binding.
Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal.
- Onto/Epist bias: High formality is often mistaken for high warrant (“proof therefore true in the world”). This pattern mitigates by forcing LA/TA visibility and by routing transport loss into R rather than mutating the claim.
- Prag bias: Teams may Goodhart R by narrowing scope or selecting easy tests. This pattern mitigates by requiring explicit scope declaration and by making scope changes first-class (A.2.6).
- Gov bias: Overconfident reuse after a changed scope, scheme, model use, evidence basis, kind, or plane is a recurring failure. This pattern requires the actual relation and its declared loss instead of one generic crossing label.
- Did bias: A single scalar is seductive; it hides what kind of warrant exists. Lane reporting keeps the scalar honest.
Conformance Checklist
Normative.
Common Anti-Patterns and How to Avoid Them
Informative; non-binding.
Consequences
Informative; non-binding.
Rationale
A triad only works if each coordinate has a single job.
- G carries entitlement. It states where the claim is asserted to apply. If G is implicit, teams argue about “what was meant” instead of updating scope.
- F carries checkability. It states how much the claim’s form supports mechanised scrutiny and reuse. If F is conflated with R, formalisation becomes a rhetorical weapon.
- R carries warrant. It states how much evidence supports relying on the claim under G. If R is not conservative, evidence with a low
Rcoordinate can be laundered into high confidence.
Routing a traversed relation's declared congruence loss into R only prevents a subtle failure: a change of scope, kind, plane, notation, source-local meaning, model-use basis, or evidence basis cannot silently rewrite the claim or carry its old warrant forward.
Weakest-link propagation is chosen because it is the simplest rule that is monotone, conservative, and auditable. When better combination rules exist, they can be introduced as explicit Γ‑policies, but the default must be safe.
SoTA-Echoing
Normative.
SoTA pack binding note. If a G.2 SoTA Synthesis Pack has sources that bear on reliability under the exact changed claim scope, kind, reference plane, notation, source-local meaning, model use, or evidence basis in this case, cite the relevant ClaimSheet IDs and CorpusLedger entries. Cite a BridgeMatrix row only when the current path actually uses an F.9 cross-local semantic Bridge represented by that row. Otherwise record SoTA-Pack: TBD/none and treat this section as the seed; neither a generic Context nor a generic transport package is required.
Relations
Builds on: C.2 (KD-CAL overview), A.2.6 (claim scope and scope revision), C.2.3 (Formality F), B.3 and B.3.3/B.3.4 (assurance, evidence lanes, and refresh), B.1.3 (Γ-fold patterns), C.3.3 (cross-kind use), G.6 (EvidenceGraph PathId discipline), C.29/A.6.3.RT (notation and representation relations), A.1.1 (selected model-use structure), and A.10/B.3 for exact evidence-use and reliance relations. F.9 is used only when an obtaining relation between distinct local meanings, reference schemes, or reference planes is part of the path.
Coordinates with: C.16 for measurement claims, E.14 for working-model assertions, F.17 for optional local-meaning addresses, and E.18/E.17/A.21 when their own transfer, publication, or gate objects are current. G.2 supplies relevant source-pack entries; G.7 remains the conditional calibration path for its declared cross-Tradition/F.9 Bridge use, not a universal calibration owner.
Used by: C.3.3 for cross-kind reuse discipline, guard macro bundles in C.3.A and C.21, and acceptance or gating logic that consumes R_eff while preserving F and G.
Clarifies: the KD-CAL meaning of reliability implicit in C.2:4.1 and the relation-specific reuse claims referenced across B.3 and C.3; it does not create a universal transport relation.
C.2.2:End
U.LanguageStateSpace - Language-state chart over U.CharacteristicSpace
Type: Architectural (A) Status: Stable Normativity: Normative unless marked informative
Plain-name. Language-state space.
Builds on.
A.19, E.10, F.18.
Used by.
C.2.LS, C.2.3, C.2.4, C.2.5, C.2.6, C.2.7, A.16.0, A.16, A.16.1, A.16.2, B.4.1, B.5.2.0, F.9.1, A.6.P, C.16.Q, A.6.A.
Use this pattern when. A team is about to route, compare, or publish a note by calling it early, ready, or settled, and the next action depends on what is actually known.
First question. What is known or uncertain about each of these five aspects, which readings clear the local threshold, and what may happen next: formality, articulation, closure, anchoring, and representation?
What goes wrong if missed. Teams flatten those five aspects, the grounds for judging them, and the publication lane into one maturity adjective. A polished document can then look ready although the claim is still open, or a useful early cue can be rejected because it is not yet polished.
What this buys. One small chart row that shows only the distinctions needed by the next action while keeping the episteme publication separate from its grounds, form, face, and carrier.
First useful chart
Start with the smallest row that can change the next action:
- the exact episteme publication being positioned;
- only the currently relevant facet values or intervals; mark a decision-relevant unknown as
unknown; - the grounds for those readings;
- the local threshold used by the named next action and the action now allowed, blocked, or still undecided;
- publication form, face, or carrier only when that distinction changes interpretation, preservation, or the next action.
Filled example. Pump-alert-17 is the alerting episteme publication being positioned. Its affected asset and discrepant reading are visible, but the claim structure is not yet complete; rival diagnostic routes remain open; the alert is anchored in the operator loop; and its representation mixes text with telemetry. Formality is omitted because the present routing decision does not depend on it. The grounds are trace T-17 and operator note N-4. The local rule permits routing to the diagnostic-question seam once the affected asset and discrepant reading are explicit; it does not yet permit treating the alert as a Work record. Form, face, and carrier are omitted because none changes that decision.
Non-use. If a pinned inherited chart already supplies the current values and threshold for the same next action, cite it instead of publishing another row. If early or ready is only ordinary prose and no routing, comparison, publication, or threshold decision depends on it, leave it as ordinary prose rather than creating a governed position.
Practical result. The row tells the practitioner whether to continue, stop, or route the publication to the pattern that governs the next question; it does not itself authorize that action.
Problem frame
In engineering, inquiry, operator, and management practice, teams often need to say where a governed U.Episteme publication currently stands before it has reached an endpoint subject pattern. That governed publication may appear through several cue-bearing, route-bearing, or endpoint-bound publication forms, but the chart claim remains about the governed U.Episteme publication rather than about a local alias or a carrier lane.
Cue packs, routed cue sets, abductive prompts, typed route-bounded projection publications, partial normal forms, and endpoint-bound records are not rival positioned items in the space. They are publication forms through which a current position claim is made visible. MVPK faces may render those forms, but faces are not themselves the forms. By contrast, a service disturbance, a model-vs-observation discrepancy, a bodily tension, a telemetry trace, a model output, or a carrier document may trigger, witness, or carry that episteme, but none of those is itself a coordinate in the space.
Practitioners, including engineers, operators, researchers, managers, and engineer-managers, still have to decide where such an episteme currently stands, which thresholds matter next, which publication form is admissible, and what must not yet be claimed. If this domain is described only with folk labels such as raw, early, settled, or ready, the real geometry disappears.
Problem
Without an explicit language-state chart:
- teams collapse several facets into one maturity story;
Fis silently misused as a surrogate for articulation, closure, anchoring, and representation factors;- thresholds are published as vague readiness statements instead of explicit facet conditions;
- source phenomena, governed epistemes, publication forms, publication faces, and carriers are conflated;
- bridge and endpoint work inherit under-described upstream states.
Forces
Solution
U.LanguageStateSpace is the cluster-local name for the declared language-state chart over U.CharacteristicSpace as disciplined by A.19.
It is not a second kernel state-space apparatus beside A.19. It is the particular declared U.CharacteristicSpace whose basis slots are the language-state facets used in this cluster.
Kind and chart boundary
U.LanguageStateSpace is a dependent durable chart value under U.CharacteristicSpace and the episteme language-state boundary, not a new root state-space U-kind. Its identity is the declared characteristic-space chart for governed episteme publication positions. Score tables, publication forms, local route maps, and carriers can publish or use the chart, but they are not the chart.
Core use
U.LanguageStateSpace gives FPF one explicit declared chart for answering five questions:
- which basis slots define where the governed episteme stands;
- what a position claim in that chart means;
- which thresholds are locally declared over those slots;
- what comparisons are admissible without cross-facet collapse;
- and how the same position claim stays distinct from the publication form currently expressing it.
Position reading under A.19
A language-state position is a partial, slot-explicit coordinate claim in the declared language-state U.CharacteristicSpace.
Each basis slot publishes a ValueSet(slot), interval, or other admissible set-valued claim. Early seam publications may leave some slots unknown or wide, but that uncertainty must be declared rather than hidden inside one stage word.
position language is therefore admissible here only as shorthand for such slot-explicit A.19 coordinate claims. It does not authorize a rival process-sequence or feature-vector story.
Facet basis
The language-state chart is coordinated by explicit facet subject patterns rather than by an informal master progression. In the current cluster the basis is formed by:
C.2.3forF;C.2.4for articulation explicitness;C.2.5for language-state closure degree;C.2.6for language-state anchoring mode;C.2.7for the language-state representation-factor bundle.
C.2.2a states that these basis slots together define the chart. It does not govern the internal scale semantics of the individual facets.
Ontological slot groups
Within this cluster, keep five slot groups distinct:
- positioned episteme publication - the governed
U.Epistemepublication whose current position is being claimed; - grounds / witnesses - disturbances, discrepancies, traces, model outputs, bodily tensions, exemplars, or contrasts that justify the current reading;
- publication forms - cue packs, routed cue sets, prompt forms, typed route-bounded projection publications, partial normal forms, and endpoint-bound records through which the episteme is published;
- publication faces - the existing MVPK faces on which those publication forms are rendered when face typing matters;
- carriers - documents, console notes, cards, trace files, or model carriers that hold or render a publication.
U.LanguageStateSpace governs only the coordinate reading of the position claim. It does not collapse that claim into the grounds, publication form, publication face, or carrier.
Position publication rule
A published position states the exact episteme publication, the facet readings that matter to the present use, and the grounds for those readings. A decision-relevant unknown is stated as unknown; unrelated facets need not be filled merely to complete a form.
Add the local threshold and named next action only when the row is used for movement, routing, comparison, or endpoint entry. Add publication form, MVPK face, carrier, or SCR/RSCR lane only when that distinction affects interpretation, preservation, distribution, or the next action.
The position is reviewable when the named or inherited episteme publication, relevant readings, grounds, and any relied-on threshold are recoverable, and when any form, face, or carrier actually mentioned remains distinct from the positioned episteme publication. A polished note or better carrier does not by itself prove a new chart position.
Non-substitution of F
F remains one basis slot in the chart, not the whole chart.
A conforming account shall not infer:
- closure from formality alone;
- anchoring from publication-face format alone;
- representation factors from articulation alone;
- or routing admissibility from a lone
Fstatement.
Where operationally meaningful thresholds exist, they must publish on the relevant slots rather than being disguised as informal F sublevels.
Position versus publication form
A position claim in U.LanguageStateSpace is distinct from:
- the underlying governed
U.Episteme, - the source disturbance, discrepancy, or witness,
- the current publication form,
- the MVPK face that renders that publication,
- the carrier that stores or displays it,
- or the endpoint-subject-qualified publication that may result from it.
Those publication lanes are coupled but distinct. U.LanguageStateSpace keeps the position claim readable without collapsing it into any one bearer lane.
Threshold publication discipline
If a threshold is used to justify a move or endpoint entry, that threshold shall be stated on explicit basis slots in the chart. Statements such as this is now ready, this has matured, or this is still too early are non-conformant when they substitute for undeclared slot conditions.
Comparison and bridge note
Positions may be compared directly only under one shared chart meaning and the applicable local comparison rule. For cross-context use, first recover the two exact F.17 local senses and test the direct F.9 predicate. Cite a Bridge only when that predicate obtains. State the proposed bounded use and any reliance separately; a loss note is optional and belongs to that use, not to the fact that the contexts differ.
If no Bridge obtains, preserve both local positions. Name the actual comparison or translation relation needed by the receiving use, or return the applicable missing-governor result instead of inventing correspondence.
What changes after the row exists
Compare the relevant readings with the local threshold named by the next action. The result can keep the publication where it is, route it through a seam or prompt pattern, open a facet or endpoint question, or stop because a required reading is unknown. The receiving pattern governs the actual route, comparison, or publication decision; the chart row supplies only the position facts that decision uses.
Archetypal Grounding
Tell. One note can have high operator-loop anchoring yet still low closure. Another can be document-mediated and symbol-heavy while still open on route choice. Both are positions in one language-state chart, but not on one maturity progression.
Show (System). A service disturbance is a system-side phenomenon. The positioned governed U.Episteme publication is the alerting episteme published from that disturbance; its position claim may be moderately formal, low-closure, high in operator-loop anchoring, and mixed in representation because terse codes and natural-language hints coexist.
Show (Episteme). A model-vs-observation discrepancy is a witness-level tension, not the positioned episteme publication itself. Once preserved as a cue pack, the resulting governed U.Episteme may be low in articulation, low in closure, trace-anchored, and only partly symbolic even when rendered into prose.
Bias-Annotation
The pattern deliberately biases authors toward decomposable coordinate claims and away from folk stage vocabularies. That costs some brevity, but it prevents collapse of genuinely different state facets into one adjective.
Conformance Checklist
CC-C.2.2a-1U.LanguageStateSpaceSHALL be treated as the declared language-state chart overU.CharacteristicSpace, not as a rival kernel space and not as a disguisedFprogression.CC-C.2.2a-2Published positions SHALL cite explicit facet subject patterns when those positions matter for movement, routing, or endpoint entry.CC-C.2.2a-3Position claims SHALL use slot-explicit values,ValueSetclaims, or intervals; uncertainty SHALL NOT be hidden inside stage words such asready,early, ormature.CC-C.2.2a-4A position claim in the chart MUST NOT be conflated with the current ground, witness, publication form, publication face, or carrier.CC-C.2.2a-5Cross-context use SHALL recover the two exact F.17 local senses and test the direct F.9 predicate. Cite a Bridge only when it obtains; keep the bounded-use claim, reliance, and any optional loss note separate. If it does not obtain, keep the local positions distinct and name the missing comparison or translation governor.CC-C.2.2a-6Corridor and navigation notes MUST NOT be read as relocation of facet, seam, bridge, or downstream subject-pattern semantics into the chart subject-pattern set.CC-C.2.2a-7If a position claim is used for routing, endpoint entry, or gate-adjacent reasoning, the threshold note and the bearer-lane distinction between positioned episteme publication, publication form, face, and carrier SHALL remain explicit or explicitly inherited from a pinned upstream publication.
Common Anti-Patterns and How to Avoid Them
- Maturity monism. Replace five facets with one stage word. Repair by publishing explicit slot placement.
- Formality capture. Use
Fto stand in for articulation, closure, or anchoring. Repair by naming the actual facet subject pattern. - Carrier collapse. Treat a document, cue pack, or routed note as if it were the position itself. Repair by separating carrier lane, publication form, publication face, and position claim.
- Threshold folklore. Speak of readiness without any explicit threshold declaration. Repair by publishing relevant local threshold notes on explicit slots.
- Bridge by vibe. Similar stage language is treated as equivalence. Recover the two exact F.17 local senses and test F.9; cite a Bridge only when its predicate obtains. Otherwise keep both positions local and route the actual comparison or translation question.
- Corridor inflation. Treat the navigation cluster or corridor map as if it were the subject-pattern set for all downstream semantics. Repair by naming whether the current statement belongs to the chart subject-pattern set, a seam publication form, or a downstream subject pattern.
Consequences
The benefit is that practitioners, including engineers, operators, researchers, managers, and engineer-managers, can speak about where a governed U.Episteme stands without hiding the reasons inside vague maturity language. The trade-off is that publication must carry explicit slot and threshold information when decisions depend on it.
Rationale
Language-state work needs one explicit statement of what this chart is before individual facet, move, and endpoint patterns start using it. Without that statement, readers have to reconstruct the same geometry from scattered local rules and examples.
SoTA-Echoing
SoTA note. This section does not mint a second rule source. It is a load-bearing alignment statement: the Solution, Conformance Checklist, and bearer-lane discipline of this pattern must match the stance stated here or explicitly justify divergence.
Traditions covered. This pattern binds itself to architecture-description governance, model-based systems engineering, and risk/governance profiling practice.
Architecture-description governance. C.2.2a adopts the discipline that positions, publication forms, faces, and carriers stay explicitly distinct, even when one local rendering makes them look aligned.
Characteristic-space and profile discipline. The multi-facet chart is grounded in FPF A.19 and the current C.2.3–C.2.7 facet patterns; it is not imported from an external modeling language. Current governance practice contributes the narrower discipline of publishing scoped profiles and thresholds.
Local stance. The load-bearing architecture decision is FPF-native: governed language-state is a multi-facet chart with explicit thresholds and bearer-lane distinctions, not one maturity progression or one polished publication face. The external rows support the narrower view, publication, profile, and threshold disciplines stated above.
Relations
- Builds on:
A.19,E.10,F.18. - Coordinates with:
C.2.LS,C.2.3,C.2.4,C.2.5,C.2.6,C.2.7,A.16.0,A.16,F.9,F.9.1,E.17.1. - Constrains: threshold publication, positional claims, and anti-collapse discipline across the language-state cluster.
Worked Examples
Inquiry cue before endpoint capture
A research cue note may occupy a position claim with:
- moderate
F, - low articulation explicitness,
- low closure,
- strong embodied or trace-based anchoring,
- and mixed representation factors.
That position explains why the note should remain upstream of A.6.P or C.25 even if its prose happens to look polished.
Routed operator alert note
A routed operational alert may have:
- moderate formality,
- medium articulation,
- low closure because several responses remain live,
- high operator-loop anchoring,
- and mixed symbolic and natural-language representation.
That position explains why the alert belongs in a route-bearing seam publication before it hardens into an endpoint-subject-qualified work record or reliance record.
Viewpoint-bound adequacy note
A document-mediated adequacy note about an architecture description may be relatively high in formality and articulation, mid-level in closure, document-mediated in anchoring, and symbolic in representation. That position remains within the same language-state chart even though its carrier lane differs from an embodied inquiry cue.
Polished prose is not closure
A prose rewrite may look cleaner, more compact, or more manager-readable than the source cue and still remain low in closure or articulation explicitness. If the underlying slot values, uncertainty, and route plurality remain unchanged, then publication polish changes the rendering or carrier lane, not the chart position by itself.
Position Publication Package Discipline
A publishable row contains the exact episteme publication, the decision-relevant facet readings or intervals, their grounds, and any local threshold used by the named next action. Add form, face, carrier, freshness, or inherited pins only when the receiving use relies on them.
Minimum self-check:
- Does the row name the positioned episteme publication rather than a ground, form, face, or carrier?
- Does it state every facet that can change the named next action and mark a relevant unknown honestly?
- Are the grounds and any relied-on local threshold recoverable?
- Does the row say what action is allowed, blocked, or still undecided without pretending to authorize it?
- For cross-context use, was F.9 tested on two exact local senses rather than inferred from similar wording?
Extended corridor map
After the first useful row is understood, the wider Language-State & Semantic Routing Corridor can be read as a distributed overlay over C.2.2a, C.2.LS, C.2.4–C.2.7, A.16, A.16.0–A.16.2, B.4.1, and B.5.2.0.
A.16.1 / U.PreArticulationCuePack is the earliest durable seam publication form in that corridor. B.4.1 is the explicit route-bearing seam after cue preservation, and B.5.2.0 is typed prompt entry. C.16.Q, A.6.A, A.6.P, B.5.2, A.15, and C.25 are downstream subject patterns, not members of the language-state chart. The map explains navigation only; it relocates none of their semantics into C.2.2a.
C.2.2a:End
Unified Formality Characteristic F
Type: Definitional (D) Status: Stable Normativity: Normative unless marked informative
Plain-name. Formality characteristic.
One-line summary. C.2.3 defines Formality (F) as one ordinal U.Characteristic with polarity up, anchored by the default ladder F0...F9, and declared as the F coordinate of the typed F-G-R assurance tuple.
Problem frame
Transdisciplinary work needs one shared way to speak about rigor of expression. A research hypothesis in constrained natural language, a software interface specification with explicit invariants, a controller model checked against hybrid obligations, and a proof-bearing formal development are not comparable by domain lore alone. They are comparable by how strictly the content is expressed.
Historically, that distinction drifts. Teams mix editorial maturity, organizational status, notation choice, proof support, and scope narrowness into one vague story about something being more formal. C.2.3 removes that drift by giving FPF one explicit U.Characteristic for rigor of expression.
Problem
Without one unified F characteristic:
- Rigor is narrated inconsistently. Different contexts invent local mode/tier language with no shared comparability.
- Status and rigor collapse. Something accepted, published, or approved is mistaken for something precisely expressed.
- Expression changes are hidden. A move from sketch to predicates or from executable model to proof is not recorded as a distinct content change.
- Composition becomes unsound. A composite episteme is treated as highly formal because one segment is highly formal, even when essential support still depends on less formal parts.
- Other characteristics are misused as surrogates. Authors quietly use scope, evidence, or language-state facets as if they were part of one master formality characteristic.
Forces
Solution - U.Formality as one ordinal characteristic
C.2.3 defines U.Formality as the single governing characteristic for rigor of expression in FPF.
Identity and typing
- Name:
U.Formality(abbreviatedFin the assurance tuple) - Type:
U.Characteristic - Scale kind: ordinal
- Polarity:
up - Carrier: any
U.Episteme - Default value family:
F0...F9
F states how strictly the content is expressed. It does not state whether the content is true, well evidenced, widely applicable, or organizationally accepted.
Place in the typed F-G-R tuple
F is the formality coordinate in the assurance tuple. Its interaction rules are strict:
Fis notG; scope remains governed byU.ClaimScopeand other USM structures.Fis notR; evidence, warrant strength, and decay remain assurance concerns.CLand bridge losses affectR, notF.- Changes in notation, carrier, or rendering form do not change
Fif the formal content is preserved.
Extensibility and local anchors
FPF provides the default anchor ladder F0...F9. A context may define sub-anchors or intermediate anchors such as F4[OCL] or F6.5, but only if:
- global order is preserved,
- the local anchor is explicitly docked to a parent anchor,
- the context does not invent a rival ladder or proxy scale.
Usage obligations
- Every normative episteme shall declare one
Fvalue. - Thresholds that depend on rigor should be written explicitly as
F >= Fkconditions. - Any raise or lowering of
Fis a content change, not a status-only change. Fremains declaration and reasoning infrastructure; it is not itself a governance process.
Archetypal Grounding
Tell. F does not ask whether a claim is correct. It asks how strictly the claim is expressed.
Show (System). A system requirement written as controlled natural language with unambiguous acceptance conditions may be F3; the same requirement rewritten as explicit typed invariants may become F4; a machine-checked proof of a critical invariant may raise the relevant claim core to F7 or above.
Show (Episteme). A research conjecture can begin at F1-F3, then gain explicit predicates at F4, executable semantics at F5, and proof-bearing core content at F7-F8, while remaining recognizably the same evolving claim family.
Bias-Annotation
The pattern biases FPF toward one explicit rigor characteristic and against stories that mix formality with status, publication quality, scope width, or evidence support. That bias is intentional. The price of explicit declaration is smaller than the cost of comparing rigor through folklore.
Conformance Checklist
CC-F-1Every normativeU.EpistemeSHALL declare exactly oneU.Formalityvalue, either a default anchor or a local sub-anchor explicitly docked to one.CC-F-2FSHALL be treated as an ordinal characteristic; arithmetic overFvalues is invalid.CC-F-3HigherFSHALL mean greater or equal strictness of expression, not greater truth, trust, or scope.CC-F-4Contexts MUST NOT publish alternative "formality modes" or "tiers" as surrogates forF.CC-F-5Local sub-anchors SHALL preserve the global ordering and the parent anchor meaning.CC-F-6The episteme-levelFof a composite episteme SHALL be bounded by the least-formal essential support on the relevant support path.CC-F-7Implementations MUST NOT averageFvalues numerically.CC-F-8Changes inG,R, orCLSHALL NOT changeFunless the expression form itself changes.CC-F-9Cross-context transport SHALL preserve the attributedF; if the receiving context rewrites the claim materially, it becomes a new episteme with its ownF.CC-F-10Translation loss, bridge loss, and plane crossings SHALL affectRrather than being hidden asFchanges.CC-F-11AssignedFvalues SHALL be justifiable by observable content such as explicit predicates, executable semantics, or machine-checked proofs.CC-F-12Declaring a tool or notation SHALL NOT by itself justify a higherFunless the content satisfies the target anchor semantics.CC-F-13Status labels such asDraft,Approved, orPublishedMUST NOT substitute forF.CC-F-14A context that usesFin gates or policies SHALL write those thresholds explicitly.CC-F-15Language-state facets such as articulation or closure MUST NOT be hidden as pseudo-levels ofF.
Common Anti-Patterns and How to Avoid Them
Consequences
Rationale
FPF needs a rigor characteristic that is portable across mathematics, software, systems, policy, and research. The smallest stable answer is one ordinal characteristic with clear anchors and explicit composition rules. Anything more fragmented breaks comparability; anything more compressed hides the substantive differences between sketch, predicate, executable model, and machine-checked proof.
SoTA-Echoing
Post-2015 practice across formal methods, software architecture, safety engineering, verification, computational science, and typed proof environments converges on one broad lesson: rigor is not binary. It rises through explicit structuring, predicate expression, executable semantics, and machine-checked obligations. C.2.3 adopts that gradient while keeping the characteristic notation-agnostic and transdisciplinary.
Relations
- Defines: the
Fcoordinate of the typedF-G-Rassurance tuple. - Builds on: characteristic machinery from
A.18/A.19and episteme-level characteristic assignment from Part C. - Coordinates with:
C.2.2,B.3,F.9,C.2.LS,A.16,C.2.4,C.2.5,C.2.6, andC.2.7. - Coordinates with:
C.19.2when a declared use asks whether increasing rigor of expression or selecting/configuring a formal apparatus repays application work.Fmeasures expression rigor; it does not select the apparatus, plan the work, or establish the problem-facing result. - Constrains: any pattern, gate, or editorial rule that speaks about rigor of expression.
Canonical Anchors F0...F9
Reading rule. Anchors are ordinal. They say what is minimally true of the expression form, not what is true of the world.
F0 - Unstructured prose
Free natural language with unstable vocabulary, implicit assumptions, and no stable internal structure.
F1 - Scoped notes
Still informal, but with stable topic focus and more consistent terminology. Scope is named even though criteria are not yet operationalized.
F2 - Structured outline
A recognizable template or full section shape exists. The expression is coherent end-to-end, but acceptance criteria are still largely placeholders or informal.
F3 - Controlled narrative
Claims are expressed in constrained prose with stable interpretation. Acceptance or refusal conditions are visible in language, even if not yet fully predicate-like.
F4 - First-order constraints
Critical claims can be rendered as explicit predicates or invariants over typed entities. Consistency and conflict are at least checkable in principle.
F5 - Executable math / algorithmics
The expression has declared executable semantics. Running the model, algorithm, or simulation is part of its meaning.
F6 - Hybrid formalism
Several formal layers are coordinated explicitly, typically discrete plus continuous or several tightly coupled formal subsystems, with declared obligations between them.
F7 - Higher-order verified
Core claims are encoded in a proof-capable higher-order setting and machine-checked against that logic kernel.
F8 - Dependent / constructive proofs
Programs-as-proofs or dependent-type expressions carry the relevant property in their types or proof terms.
F9 - Univalent / higher foundations
Higher-equality foundations are load-bearing. The expression relies on a frontier-grade setting where equivalence is handled as structure-level identity.
Cross-anchor cautions
- Execution is not proof.
- Surface structure is not yet semantics.
- Publishing or approval is not an anchor.
- A local sub-anchor does not erase its parent anchor's meaning.
Assigning F in Practice
First-pass questions
- Can a competent reader misread the claim materially?
If yes, the expression is likely at
F0-F2; if not, it may beF3or above. - Are the critical claims visible as explicit predicates or invariants?
If yes, the expression is at least
F4. - Does the expression have declared executable semantics?
If yes, it is likely in the
F5-F6region. - Would a logic kernel or type checker reject an incorrect change to a core claim?
If yes, the expression is likely
F7-F8, orF9if higher-equality machinery is essential.
Quick rubric
- No full structure ->
F0-F1 - Full structure but mostly placeholder criteria ->
F2 - Controlled prose with one stable reading ->
F3 - Explicit predicates / invariants ->
F4 - Declared executable semantics ->
F5 - Hybrid / layered formal obligations ->
F6 - Machine-checked proof core ->
F7 - Dependent proof-carrying core ->
F8 - Higher-equality foundations are essential ->
F9
Typical delta-F moves
F2 -> F3: replace loose prose with controlled phrasing and explicit acceptance statements.F3 -> F4: recast acceptance into typed predicates or invariants.F4 -> F5: give the expression declared executable semantics.F5 -> F6: make multi-layer obligations explicit.F6 -> F7/F8: move critical claims into machine-checked proof or dependent-type form.
Composition and Interaction
Weakest-essential-support rule
For a composite episteme, the effective F is bounded by the least-formal essential support on the relevant support path. A highly formal annex does not lift an informal essential claim core.
Relation to G
F concerns expression form; G concerns applicability or claim scope. Tightening scope may accompany a raise in F, but it is a separate change and must remain visible as such.
Relation to R
Higher F often makes evidence easier to formulate, test, or prove, but it does not create warrant strength by itself. Empirical freshness, corroboration, and bridge penalties remain R concerns.
Relation to CL and Bridges
A bridge may expose loss or mismatch across contexts. Those losses affect R; they do not silently lower or raise the attributed F. If the receiving context must materially rewrite the claim, it should publish a new episteme with its own F.
Worked Examples
Research hypothesis
A short note proposing a new scaling law with one stable reading and explicit acceptance conditions in prose is typically F3. Rewriting the acceptance conditions as typed predicates would move it toward F4.
Interface specification
An interface specification with explicit preconditions, postconditions, and invariants is typically F4. Adding declared executable semantics in a faithful reference model may move it toward F5.
Safety controller
A controller coupled to a plant model with explicit hybrid obligations is typically F6. If key invariants are then machine-checked in a higher-order proof environment, those claims move toward F7.
Decision policy
A decision policy with controlled prose may remain F3. If thresholds and conditions are published as typed predicates, it becomes F4.
Proof-bearing algorithm
A dependent-typed algorithm whose central property is carried by the type itself is typically F8.
Executable ML recipe
A fully explicit training-and-evaluation recipe with declared execution semantics is typically F5. It does not become F7 merely because the surrounding execution machinery is sophisticated.
Authoring and Review Guidance
For authors
Declare F honestly and early. A low F declaration is not a defect; it is often the correct statement about an early expression. Raise F by changing the expression form itself, not by applying prestige language or by pointing to surrounding machinery.
For reviewers
Review the actual claim core. Ask whether the target anchor semantics are visibly satisfied, whether essential support contains segments with lower R, lower F, or missing witness coverage, and whether status or other characteristics have leaked into the F declaration.
For integrators and assurance leads
Use F explicitly in gates and composition analysis, but do not let it absorb work that belongs to G, R, CL, or C.2.LS. Large F gaps across collaborating epistemes are signals for explicit formalization work, not excuses for wishful leveling.
Glossary and Notation
U.Formality/F. The rigor-of-expression characteristic governed by this pattern.- Anchor. A named ordinal milestone on the
Fladder. - Sub-anchor. A context-local refinement docked to one parent anchor.
- Delta-
F. A content change that alters expression rigor. - Essential support. The support without which the central claim does not stand.
- Example notation.
F = F4,F = F7[HOL],requires F >= F6.
Change Log and Patch Notes
Supersession of legacy ladder language
This pattern supersedes deprecated wording that speaks about alternate formality modes, tiers, or editorial ladders. Forward-looking use should speak in F directly.
Migration guidance
When refreshing legacy material, assign an initial F from observable content, rewrite local maturity labels into explicit F declarations, and keep provenance notes only as historical annotations rather than live rigor surrogates.
Boundary to language-state facets
For the language-space extension, F does not govern U.ArticulationExplicitness, U.LanguageStateClosureDegree, U.LanguageStateAnchoringMode, or U.LanguageStateRepresentationFactorBundle. Contexts MUST NOT hide thresholds for those facets as pseudo-levels or submodes of F; those facets remain explicitly governed by C.2.LS and its subordinate patterns.
C.2.3:End
U.LanguageStateFacetProfile - Thin profile bundle for language-state facets
Type: Definitional (D) Status: Stable Normativity: Normative unless marked informative
Plain-name. Language-state facet profile.
Use this pattern when. Use C.2.LS when a U.Episteme publication needs one explicit profile that keeps formality, articulation, closure, anchoring, representation factors, and local thresholds visible together.
What goes wrong if missed. Teams replace the facet profile with a maturity adjective such as ready, raw, or stable, then use that label to choose routes, decide whether to reopen, interpret Bridges, or make publication decisions. The label hides the actual facet values.
What this buys. A thin, decomposable profile bundle: each facet keeps the definition and tests supplied by its own pattern, while the profile gives authors, assurance readers, and integrators one place to publish a threshold-relevant language-state position.
Problem frame
Once position claims in the declared language-state chart over U.CharacteristicSpace must be published and compared, teams need one thin profile bundle that keeps the relevant facets visible as one explicit facet profile without turning that profile into a second characteristic calculus or a surrogate maturity progression.
Problem
Without a dedicated profile bundle, authors blur articulation, closure, anchoring, and representation into one vague maturity story, or they silently reuse F as a surrogate. That blocks admissible threshold publication, undercuts A.16 move guards, and makes school-to-school bridge work harder than it needs to be.
Forces
Solution
U.LanguageStateFacetProfile is a typed profile bundle that names the facets by which position claims in the declared language-state chart over U.CharacteristicSpace are published and interpreted:
formalityRef->U.FormalityfromC.2.3articulationExplicitnessRef->U.ArticulationExplicitnessfromC.2.4languageStateClosureDegreeRef->U.LanguageStateClosureDegreefromC.2.5languageStateAnchoringModeRef->U.LanguageStateAnchoringModefromC.2.6languageStateRepresentationFactorBundleRef->U.LanguageStateRepresentationFactorBundlefromC.2.7thresholdRefs?-> context-local threshold declarations over the named facetsrouteNotes?-> informative notes that help interpret routing or reopening decisions
C.2.LS therefore defines only the profile bundle; it defines neither an individual characteristic nor a trajectory. A.18/A.19 supply characteristic semantics, A.16 defines admissible moves, and E.18 describes publication of explicit transition structures.
Kind and profile-bundle boundary
U.LanguageStateFacetProfile is a dependent durable profile-bundle value under the declared U.LanguageStateSpace and U.CharacteristicSpace boundary, not a root U-kind. Its identity is the explicit bundle of language-state facet refs used for position reading and threshold publication. A local dashboard, table, route note, or maturity label is a publication or interpretation over the bundle, not the bundle itself.
Contribution boundary
C.2.LS defines only profile composition and requires the language-state facets to remain explicit and non-collapsed. It does not:
- redefine
F; - invent a second formality progression;
- redefine the scale semantics of
AE,CD,LanguageStateAnchoringMode, orU.LanguageStateRepresentationFactorBundle; - define reopen/backoff moves;
- define endpoint classification or bridge kinds.
Threshold publication discipline
Any threshold used to choose a next question, constrain an admissible move, or begin A.6.P recovery shall be published on explicit named facets in the profile. Do not describe hidden sub-levels of F when the real issue is articulation, closure, anchoring, or the representation-factor bundle.
Local profile-reading witness
For this pattern, a published facet profile is reviewable when:
- the facet refs are explicit or explicitly inherited from an already pinned upstream publication;
- any threshold-bearing use names the facet whose threshold is being invoked;
- route notes or local overlays remain informative and visibly docked to the explicit facet bundle;
- and the profile does not smuggle move rules, bridge rules, gate state, or downstream definitions and tests into the bundle record.
A polished label, one strong facet, or one memorable route note does not by itself yield an admissible profile reading. The profile remains conformant only when the named facets stay explicit and decomposable.
Composite readings
A language-state judgement may be composite, but the composite shall be decomposable. For example, a cue may be:
- low
AE, - medium
CD, AM.TraceAnchored,- and representation-wise mixed rather than purely symbolic.
A conforming profile makes this decomposition visible rather than hiding it under one poetic label such as "early" or "raw".
Corridor map note
C.2.LS participates in the current Language-State & Semantic Routing Corridor, but contributes only the thin facet-profile bundle. Readers who need one map of the full language-state pattern set should read the corridor note in C.2.2a.
That map does not change this boundary: C.2.LS still does not define cue preservation, route-bearing publication, prompt entry, or downstream endpoint use.
Archetypal Grounding
Tell. A team may say a draft is "still forming" for different reasons. U.LanguageStateFacetProfile forces the team to say whether the issue is low articulation, low candidate-space closure, an anchoring mismatch, or an unresolved representation-factor bundle.
Show (System). An operator alert note can be AM.OperatorLoop anchored and low-closure without being low-formality in every respect.
Show (Episteme). An inquiry note can be low articulation yet already tightly anchored to exemplars and traces.
Bias-Annotation
The pattern biases authors toward keeping facets explicit and away from master-scale stories. That cost is intentional: the goal is to prevent surrogate progressions from entering the Core.
Conformance Checklist
CC-C.2.LS-1A language-state facet profile SHALL reference the patterns that define its facets rather than invent local unnamed factors.CC-C.2.LS-2C.2.LSMUST NOT redefineFor create a second formality progression.CC-C.2.LS-3Thresholds that matter for routing, reopening, or lexical repair SHALL be published on explicit facets.CC-C.2.LS-4Trajectory accounts that rely on facet profiles SHOULD reuseA.16move kinds andE.18transition-structure publication rules.CC-C.2.LS-5Composite labels such asearly,settled, orreadySHALL NOT stand in for the explicit facet bundle when those states matter operationally.CC-C.2.LS-6Composite readings, overlays, and route notes SHALL remain decomposable into named facets and MUST NOT behave as hidden master factors.CC-C.2.LS-7A profile bundle MUST NOT smuggle move rules, bridge rules, gate state, or downstream definitions and tests into what should remain a thin facet-profile record.
Common Anti-Patterns and How to Avoid Them
- Shadow progression. Treating
early/lateas a master scale. Split the judgement into the named facets. - Formality capture. Letting
Fstand in for closure or articulation. Publish those facets explicitly. - Bundle inflation. Turning
U.LanguageStateFacetProfileinto a secondA.19. Keep it thin and referential. - Opaque readiness. Using words such as
readyormaturewithout naming which facet justifies the claim. - Route-note capture. Letting an informative route note act as a move rule, gate state, or endpoint rule. Keep route notes informative. Use
A.16for admissible moves, the applicable pattern for a downstream definition or test, the applicable gate or Work pattern for those claims, and anauthoritySourceRefonly when an external authority actually supplies the rule.
Consequences
The benefit is clearer source and rule references: early cue work, bridge annotations, and reopen moves can all refer to one explicit facet profile. The trade-off is more explicit profile authoring and threshold publication.
Rationale
The pattern gives the declared language-state chart over U.CharacteristicSpace one stable record through which its facet bundle can be published together, without taking over definitions and tests supplied elsewhere in FPF.
SoTA-Echoing
SoTA note. This section does not mint a second rule source. It is a load-bearing alignment statement: the Solution, Conformance Checklist, and boundary discipline of this pattern must match the stance stated here or explicitly justify divergence.
Source boundary. The exact facet meanings and profile rules come from A.18/A.19 and the neighboring FPF patterns. External sources are used only when they change a rule or case.
SysML v2 is deliberately excluded from the positive SoTA basis and from useful lineage for this question. Search prominence and official status do not show that it solves the facet-profile problem, and no demonstrated use here changes a rule or worked case. Treat it as a historical dead end for this comparison. Do not add a replacement citation merely to fill the removed row.
Local stance. The useful bounded result is a small explicit facet profile with local thresholds and decomposable readings, not one maturity adjective or one route-coloured bundle label.
Relations
- Builds on:
A.18,A.19,C.2.2a,C.2.3. - Coordinates with:
C.2.4,C.2.5,C.2.6,C.2.7,A.16.0,A.16,A.16.1,A.16.2,B.4.1,B.5.2.0,E.18,F.9for any Bridge and bounded-use claim, andF.9.1only for an optional stance note about that claim. - Constrains: language-state threshold publication and profile composition.
Worked Examples and Composition Notes
Operator-facing early alert
A console alert note may be published with a language-state facet profile such as:
F = F2/F3because the note is structurally controlled but still lightweight;AE = AE2because candidate anchors are visible but not yet fully relation-shaped;CD = CD1because several routes remain live;LanguageStateAnchoringMode = AM.OperatorLoopbecause the note is directly anchored to operator intervention/work;RepresentationFactorBundle = {local, sparse, mixed-symbolic}because alert text and compact codes coexist.
This example shows why no one facet can replace the others. The note is not simply early; it is early in a specific, decomposable way.
Research cue before lexical repair
A felt or trace-anchored mismatch cue in an inquiry note may be:
- low
AE, - very low
CD, AM.EmbodiedFelt,- and representation-wise mixed because the cue is partly verbal, partly kinesthetic, partly exemplar-based.
That profile explains why the cue should remain in A.16.1 rather than being forced into A.6.P or B.5.2 immediately.
Architecture-description case
A viewpoint-bound note about the adequacy of an architecture description may be moderately high in F, moderately high in AE, still mid-level in CD, document-mediated in AM, and symbolic in its representation-factor bundle. The profile keeps description-side adequacy distinct from system-side engineering quality.
Same F, different profile
Two notes may share the same rough F band and still differ sharply in articulation, closure, anchoring, and representation factors. One may be operator-loop anchored and low-closure; another may be document-mediated and comparatively closed. The profile bundle keeps that difference visible instead of letting F behave like a master factor.
Authoring and Review Guidance
For authors
When publishing a language-state facet profile:
- start from the local authoring problem rather than from a memorized progression;
- name the facet refs explicitly;
- add threshold refs only when a threshold changes routing, repair, or another operative decision;
- avoid global labels such as "mature", "raw", or "ready" unless the profile decomposition is already visible.
For assurance readers
An assurance reader should ask:
- is any facet silently replaced by
F? - is a threshold published on an explicit facet rather than on a poetic surrogate?
- do route or reopen claims actually match the published facet bundle?
- are profile notes genuinely informative, or are they smuggling definitions or tests from elsewhere?
For integrators
Integrators should preserve profile references rather than rephrasing them into local slang. A local alias is acceptable only if the underlying facet docking remains explicit and stable.
Extension and Migration Notes
Local extension rule
Contexts may extend the profile with local threshold refs, route notes, or additional descriptive aids, but they shall not add a new master facet that collapses the named facet set into one summary factor.
Migration from surrogate prose
Older prose often says:
- "the episteme is still early",
- "the issue is not mature enough",
- "the note is ready",
- "the cue is still raw".
A conforming migration rewrites such statements into explicit facet talk: which facet is low, which is high, which threshold is or is not met, and which move that fact justifies.
Boundary reminder
U.LanguageStateFacetProfile is a coordination record. If authors put move rules, bridge rules, scale rules, or bundle semantics into the profile itself, that content belongs with the pattern that defines the move, Bridge, scale, or bundle.
Profile Publication Package Discipline
Minimal publishable profile package
A publishable U.LanguageStateFacetProfile should normally carry:
- the declared facet refs for
AE,CD,LanguageStateAnchoringMode, andLanguageStateRepresentationFactorBundle; - any threshold refs that substantively affect routing, repair, bridge interpretation, or review load;
- the local relation to
Fwhen readers might otherwise treatFas a surrogate; - any omission note when a facet is intentionally unpublished, unknown, or locally irrelevant.
One-line publication is admissible only if the facet definitions and tests remain legible.
Partial-profile rule
A partial profile is admissible only when omission is explicit. Publishing AE and CD while deferring LanguageStateAnchoringMode is acceptable; silently omitting it and then speaking in scalar prose such as "early" or "ready" is not.
If only one facet is published, either explain why the others are not included in the current note or point to the note where they are already published.
Overlay discipline
Local overlays such as "explicit-but-open", "trace-heavy", or "operator-tight" are admissible only when they dock to explicit facet refs. Overlays remain secondary to the declared profile and must not replace the facet bundle.
Cross-Facet Reading Rule
No master-facet reading
Do not infer the whole language-state profile from one facet. High AE does not entail high CD; strong AM.OperatorLoop does not fix AE or CD; symbolic representation does not entail high F; low CD does not imply low operational consequence.
Threshold interaction rule
When a threshold is expressed over one facet, say whether the other facets are merely informative or also constraining. A Context may allow entry into B.5.2.0 once AE suffices for an explicit open question while still capping CD so rival answers remain live; it may allow entry into A.6.P at AE3+ while still capping CD so the move remains exploratory rather than endpoint-binding.
Transition reading rule
Read profile transitions facetwise. A note may become more explicit without becoming more closed, more document-mediated without changing closure, or more symbolic without becoming more formal. A.16, A.16.1, A.16.2, B.4.1, and B.5.2.0 should therefore cite the facet transition that actually justifies the move.
Review Matrix and Migration Tests
Review matrix
An assurance reader should ask:
- does each published facet keep the definition and test supplied by its own pattern rather than by surrogate prose;
- does any overlay smuggle a hidden scalar or gate decision;
- are threshold claims tied to the facet that really bears them;
- do cited moves in
A.16,A.16.1,A.16.2,B.4.1, orB.5.2.0actually match the facet bundle; - if the profile crosses a Bridge or viewpoint boundary, did the author use
F.9for the Bridge, bounded-use claim, and loss account, and keep any optional F.9.1 stance note separate rather than importing it as a fake facet?
Migration test for source prose
Source phrases such as "still immature", "not ready yet", or "already stable enough" should be unpacked into: which facet is claimed, which anchor or bundle member justifies it, which threshold or route consequence follows, and which cited rule or external authoritySourceRef justifies that consequence.
Comparative profile use
Compare profiles facetwise unless a Context has published an explicit local aggregation for reporting. Such an aggregation remains secondary and must not replace the profile in norms, thresholds, or bridge claims.
C.2.LS:End
U.ArticulationExplicitness
Type: Definitional (D) Status: Stable Normativity: Normative unless marked informative
Plain-name. Articulation explicitness.
Use this pattern when. Use C.2.4 when the next move depends on how much of a governed U.Episteme publication's meaning a reader can already recover.
What goes wrong if missed. A formal-looking sentence is treated as semantically ready, a real early cue is discarded as too vague, or every partly explicit note is forced through relation repair even when it is a plan, MethodDescription, Work claim, representation, question, characteristic, or ordinary domain statement.
What this buys. One branch-neutral ordinal characteristic: a stable cue can grow into recoverable governed structure, a complete form for its actual semantic branch, and a stable receiving use without confusing articulation with formality, closure, truth, trust, or endpoint authority.
Problem frame
A governed U.Episteme can matter while its semantic shape is only partly explicit. The declared language-state chart over U.CharacteristicSpace therefore needs one basis-slot pattern for how much of that shape a reader can recover, without assuming in advance whether the direct branch is relational, planning, method, Work, representation, prompt, characteristic, or ordinary domain content.
Problem
When articulation explicitness stays implicit, authors either overstate readiness for a receiving pattern or hide useful early structure. Reusing F for this judgement creates a category error: formality concerns rigor of expression, while articulation concerns whether the meaning needed by the actual receiving use is explicit. A relation-shaped ladder creates a second error by scoring other well-formed claim kinds as immature merely because they are not relations.
Forces
Solution
U.ArticulationExplicitness is an ordinal characteristic of how much of a governed episteme publication's semantic shape a reader can recover for publication, routing, repair, or direct use. The common direction is independent of the semantic branch.
Kind and characteristic boundary
U.ArticulationExplicitness is a dependent durable characteristic value under the declared U.LanguageStateSpace / U.CharacteristicSpace boundary, not a root U-kind. Its identity is the articulation-explicitness basis slot and ordinal scale discipline for governed episteme publication positions. Local thresholds, route labels, and score-table columns may reference it, but they do not create a separate U-kind.
Characteristic specification
- Kind: CHR characteristic.
- Scale discipline: ordinal.
- What rises: semantic shape becomes more explicit.
- What does not follow automatically: truth, trust, closure, admissibility, or formality.
AE is therefore independent from F, from LanguageStateClosureDegree, and from endpoint authority.
Starter anchor set
The anchors are a starter set. A local use may refine them, but it shall keep the common direction and the distinction from F intact. A refined anchor may be branch-relative; it may not make relation structure the universal measure of articulation.
Use discipline
AEmay state an entry threshold for the direct semantic branch named by the current use.A.6.Pis only the relational branch. A note does not enter it merely because a table, arrow, or sentence looks relation-shaped.AEmay justify why an episteme remains inA.16.1orB.4.1while its branch or required structure is still unresolved.- A local threshold shall name both the intended receiving pattern and the branch-appropriate structure it requires.
AEshall not stand in for closure, confidence, truth, trust, or authorization. HighFdoes not imply highAE, and highAEdoes not imply highF.
Change discipline
Raising AE requires additional recoverable anchors, participants, actions, conditions, bounds, or stable receiving-use structure appropriate to the current branch. Lowering AE is admissible under A.16.2 when a prior articulation proves over-committed, misleading, or routed to the wrong branch.
Archetypal Grounding
Tell. “Something is off” may be a real cue even before its relation participant, field meaning, representation position, bearer, intended activity or plan, actual Work occurrence, reliance use, evaluator, or ordinary domain meaning is explicit. If the cue says only “role,” route it through E.10.ROLE; do not presume a work-facing kind or assignment.
Show (System). An operator alert cue grounded in a disturbance trace may be stabilized as a candidate intervention cue before a full work relation or reliance relation specification exists.
Show (Episteme). A research note may name a contrast and exemplars before it has a clean proposition.
Bias-Annotation
The pattern legitimizes early cues. The counter-bias is explicit: low AE never licenses hidden semantics or unreviewable leaps.
Conformance Checklist
CC-C.2.4-1AESHALL NOT be treated as a synonym forF.CC-C.2.4-2A route change SHOULD require the local articulation threshold declared for that receiving branch;A.6.Papplies only to a current relational branch.CC-C.2.4-3AEjudgements that drive routing or use SHALL cite the anchors, participants, actions, conditions, bounds, or other branch-appropriate structure that justifies the chosen level.CC-C.2.4-4RaisingAESHALL NOT be described as if it automatically settled closure, truth, trust, authority, or admissibility.CC-C.2.4-5Relation-shaped notation SHALL NOT raise the level or selectA.6.Pwhen the actual claim belongs to another branch.
Common Anti-Patterns and How to Avoid Them
- Formal-looking but semantically thin. High
F, lowAE. Declare both. - Mystical cue immunity. Low
AEis presented as exempt from authoring discipline. Preserve it, but state what remains unresolved. - Ready-by-tone. A sentence sounds precise, so authors assume
AE3+. Publish the actual recoverable structure. - Relation-shaped shortcut. Arrows, columns, or grammatical subjects and objects are treated as proof that the claim is relational. Recover the actual claim kind and route its branch before assigning the higher level.
Consequences
The benefit is admissible publication of early cues and branch-aware threshold setting. The trade-off is that authors must distinguish not yet explicit from already formal and must name the receiving branch rather than treating relation repair as the universal destination.
Rationale
AE is one basis slot in the declared language-state chart over U.CharacteristicSpace. Without it, A.16.0, A.16.1, and B.4.1 cannot state crisp entry, seam, and completion conditions.
SoTA-Echoing
The distinction echoes work on sketching, focusing/TAE, embodied cue capture, and representation probing: a cue can be real and operationally relevant before it becomes fully explicit.
Relations
- Builds on:
A.18,C.2.2a,C.2.LS. - Coordinates with:
C.2.1,C.2.5,A.16.0,A.16,A.16.1,A.16.2,A.3.1,A.6.P,A.6.3.RT,A.15,A.15.1,B.4.1,B.5.2.0,C.2.P.DR, andC.16.P. - Constrains: articulation thresholds for routing and repair.
Worked Examples and Edge Cases
High formality, low articulation
A template may be syntactically precise and therefore high in F, yet still low in AE because the actual participants, field meanings, bearer, planned action, admitted Work occurrence, reliance move, evaluator, or ordinary domain meaning remains unclear. A local system-role kind, classification, or assignment is selected only after evidence supports that branch. Formal-looking language does not make its semantic route recoverable.
Plain plan, high articulation
The note At 14:00, Maintenance Team 2 will isolate Pump P-17, replace Seal S-4, and restore service only after Leak Test LT-9 passes uses ordinary language and little formal notation. It can still reach AE4: the planned actor, affected entity, ordered actions, time, and completion condition are explicit enough for the planning branch. It routes to A.15; it is not yet an A.15.1 Work occurrence and needs no relation repair merely to count as explicit.
Relation-looking but wrongly routed
A row Maintenance Team 2 | Pump P-17 | isolate | 14:00 looks slot-shaped. If it records intended action, however, it is a compact plan row rather than proof of a durable relation. Its layout does not raise AE until the planning meaning and conditions are recoverable, and it does not select A.6.P.
Threshold edge case
A cue with a stable trigger and candidate anchors may still sit between AE2 and AE3 because its direct branch is unresolved. Keep it in B.4.1 or A.16.1, state what is missing, and apply the threshold of the branch eventually selected rather than a universal relation threshold.
Authoring and Review Guidance
Author prompt
To assign AE, ask:
- is a stable cue, question, or contrast nameable;
- which anchors, participants, actions, fields, or meanings are visible;
- is the direct semantic branch recoverable;
- is a complete form for that branch publishable;
- can the named receiving use interpret it without reconstructing the meaning from the source?
Review prompt
A reviewer should reject an AE claim based only on rhetorical confidence or relation-shaped presentation. The claimed level should be supported by the branch-appropriate anchors, participants, actions, fields, meanings, conditions, bounds, or stable receiving-use structure.
Threshold publication reminder
If AE determines whether an episteme stays in A.16.1, passes through B.4.1, or enters a direct receiving pattern, publish the local threshold and name that branch. Use A.6.P only for the relational branch; do not borrow its threshold for plans, methods, Work, representations, prompts, characteristics, or ordinary domain claims.
Extension and Migration Notes
Local anchor refinement
Contexts may refine the starter anchor set with subanchors, but the refinement must preserve the ordinal direction and the distinction from F and CD.
Migration from vague articulation prose
Statements such as "still vague", "more explicit now", or "ready for formalization" should be migrated into explicit AE claims plus the corresponding move or routing claim.
Boundary reminder
AE does not govern closure, confidence, or warrant. If authors want those meanings, they must publish them through their own governing patterns.
Articulation Publication Package Discipline
Minimal articulation package
An AE claim that changes routing or use should publish more than a level token. State:
- the exact episteme publication being judged;
- the stable cue, question, or contrast;
- the candidate anchors, participants, actions, fields, or meanings relevant to the current branch;
- the branch-appropriate structure already recoverable and any decision-relevant gap;
- the grounds for the level;
- the named next use and its local threshold when the level is used to change route.
Unresolved claim-bearing role wording goes first to E.10.ROLE. A bare AE3 label is insufficient when the supporting structure and intended receiving branch are absent.
Threshold package for route change
When AE controls a route change, publish the intended receiving pattern, its semantic branch, the minimum recoverable structure it requires, and the current evidence that the publication meets or misses that threshold. A relational route may name A.6.P; another branch names its own receiving pattern.
Evidence-limited rise rule
AE may rise only as far as the published anchors, slots, and contrasts warrant. Stylistic polish, templates, or rhetorical confidence do not raise AE on their own.
Threshold Crossing and Split Handling
Branch-aware high-articulation exits
At AE3+, use the local threshold of the direct branch rather than one universal destination:
- for an actual relation claim, use
A.6.Pto restore relation precision and then return the claim to its direct relation pattern; - for a plan or intended activity, use
A.15; - for a Method, use
A.3.1, while its MethodDescription remains an episteme underC.2.1; - for an admitted dated Work occurrence, use
A.15.1; - for a representation claim, use
C.2.P.DR, addingA.6.3.RTonly when a representation transition is current; - for an abductive prompt or explicit open question, use
B.5.2.0or the direct question pattern; - for a Characteristic or Scale claim, use
A.17andA.18, withC.16.Pwhen its scalar wording hides the construction; - for an ordinary domain claim, keep the episteme publication under
C.2.1and use the direct domain pattern that governs its subject.
If the branch or threshold is unresolved, keep the episteme in B.4.1 or A.16.1 and state what is still missing. AE reports recoverable articulation; it does not itself choose the branch or authorize the receiving use.
High-articulation, low-closure cases
A note may reach AE4+ while remaining low or mid in CD. In such cases state that articulation is sufficient for precise handling while closure still leaves rival routes or frames live.
Split-publication rule
If one note contains a high-AE fragment and a low-AE remainder, split the publication rather than assigning one averaged level that hides the actual route structure.
Review Matrix and Endpoint Boundary Tests
Review matrix
A reviewer should ask:
- are the named anchors genuinely present rather than presupposed;
- does the level rest on recoverable meaning rather than tone, formatting, arrows, or columns;
- is the direct semantic branch explicit, or is a relation route being inferred from presentation alone;
- are the participants, actions, fields, meanings, conditions, bounds, or ordinary wording required by that branch still hidden;
- has an intended activity or plan been mislabeled as Tech
Workbefore an occurrence is admitted; - if
AEjustifies a route change, is the named receiving pattern actually ready to receive this publication?
Endpoint-boundary test
High AE does not by itself authorize endpoint claims, gate claims, or quality ascriptions. If such consequences appear, show which downstream governing pattern takes over.
Migration note for false precision
Rigid templates, capitalized labels, or tidy sentence rhythm can simulate articulation. Migration should therefore test whether anchors and slots are really present; if not, the articulation level should drop.
C.2.4:End
U.LanguageStateClosureDegree
Type: Definitional (D) Status: Stable Normativity: Normative unless marked informative
Plain-name. Language-state closure degree.
Use this pattern when. Use C.2.5 when a governed U.Episteme publication must say how fixed its candidate space, route space, or frame space has become before endpoint use, reopening, or retreat.
What goes wrong if missed. A confident tone is mistaken for closure, closure is mistaken for truth or gate authority, or a closure drop leaves endpoint expectations and route commitments silently hanging.
What this buys. A separate ordinal characteristic for closure degree, so teams can distinguish exploration, stabilization, selected route, guarded fixation, and admissible retreat without collapsing closure into formality, articulation, warrant, or obligation.
Problem frame
A governed U.Episteme may already be explicit enough for publication while its declared position claim remains intentionally open to rival routes or frames. The declared language-state chart over U.CharacteristicSpace therefore needs a separate basis-slot governing pattern for how fixed or closed the current candidate space has become.
Problem
Closure is often hidden inside vague words such as "ready", "settled", or "open". When closure is not explicit, teams cannot reason cleanly about reopen, sketch-backoff, or the admissibility of endpoint docking.
Forces
Solution
U.LanguageStateClosureDegree is an ordinal characteristic over how fixed the current candidate set, framing, and admissible next moves are in a published position claim in the declared language-state chart over U.CharacteristicSpace.
Kind and characteristic boundary
U.LanguageStateClosureDegree is a dependent durable characteristic value under the declared U.LanguageStateSpace / U.CharacteristicSpace boundary, not a root U-kind. Its identity is the closure-degree basis slot and ordinal scale discipline for governed episteme publication positions. Local route commitments, gate claims, or authority states remain neighboring claims unless their governing patterns make them current.
Characteristic specification
- Kind: CHR characteristic.
- Scale discipline: ordinal.
- What rises: the local state becomes more fixed or more binding.
- What does not follow automatically: truth, trust, formality, or quality.
Starter anchor set
Non-collapse rules
LanguageStateClosureDegree is not:
F;- articulation explicitness;
- gate decision;
- evaluator confidence;
- warrant strength.
A text may be highly explicit but low-closure, or low-explicitness but already high-closure by policy. Those states shall not be collapsed.
Change discipline
Increasing CD requires narrowing candidate space, route space, or frame space explicitly. Lowering CD is admissible only through a named move such as reopen, sketchBackoff, or respecify, with a retained-witness and discarded-assumption note.
Archetypal Grounding
Tell. Two notes may look equally explicit, but one is still intentionally open while the other is already committed to a single route.
Show (System). An incident cue can be routed to rollback while remaining reopenable if new evidence arrives.
Show (Episteme). A hypothesis sketch can be highly articulated but still low closure because rival explanations remain live.
Bias-Annotation
The pattern makes closure explicit, which resists hidden overconfidence but may feel heavy to authors who prefer implicit consensus.
Conformance Checklist
CC-C.2.5-1Closure SHALL be declared independently fromFandAEwhen it matters for routing, docking, or reopening.CC-C.2.5-2Reopen/backoff moves SHALL cite the prior closure state they are relaxing.CC-C.2.5-3Strong-closure states SHOULD name the guard,governingPatternRef, orauthoritySourceRefthat makes the closure binding.CC-C.2.5-4Endpoint authority SHALL NOT survive a closure drop silently when the supporting route or publication form no longer holds.
Common Anti-Patterns and How to Avoid Them
- Closure by mood. A sentence sounds decisive, so teams assume high closure. Publish
CDexplicitly. - Irreversible drift. Closure rises informally but no reopening condition exists. Use
A.16.2. - Authority smuggling. High closure is treated as if it were automatically a gate or obligation. Route those consequences through the proper governing patterns.
Consequences
The benefit is admissible handling of stabilization, commitment, and reopening. The trade-off is more explicit state declaration and more explicit retreat records.
Rationale
Closure is the route-governance basis slot that complements articulation within the declared language-state chart over U.CharacteristicSpace. A.16.0 and its seam species need both.
SoTA-Echoing
The facet aligns with iterative design, open-world reasoning, and exploratory search practices where closure is a governance choice rather than a hidden by-product.
Relations
- Builds on:
A.18,C.2.2a,C.2.LS. - Coordinates with:
C.2.4,A.16.0,A.16,A.16.1,A.16.2,B.4.1,B.5.2.0. - Constrains: reopen, backoff, and endpoint docking guards.
Worked Examples and Retreat Cases
Explicit but still open
A note may sit at AE4 yet only CD1 because rival explanatory frames are still live. The important lesson is that explicit publication does not imply settled closure.
Strong closure under policy guard
An operator rule may be only moderate in AE but high in CD because policy already fixes the next step under the current horizon. This shows why closure is governance-facing, not merely stylistic.
Reopen case
A route may move from CD4 back to CD2 when counter-evidence appears. A conforming publication does not hide this as embarrassment; it records the retreat as an admissible A.16.2 move.
Authoring and Review Guidance
Author prompt
To assign CD, ask:
- how many rivals remain live?
- is one route merely preferred, or actually fixed?
- what guard,
governingPatternRef, orauthoritySourceRefmakes the closure binding? - what would count as an admissible reopen trigger?
Review prompt
An assurance reader should ask whether closure is being inferred from tone, from hierarchy, or from social force rather than from an explicit narrowing of route or frame space.
Governance note
Whenever CD substantively affects gates, commitments, or late endpoint authority, the supporting guard, governingPatternRef, or authoritySourceRef should be visible.
Extension and Migration Notes
Local anchor refinement
Contexts may refine the starter closure anchors, but shall keep the ordinal progression and the explicit link to reopen/backoff discipline.
Migration from readiness language
Words such as "settled", "closed", "final", or "open" should be treated as migration prompts into explicit CD claims and, where needed, into named A.16.2 moves.
Boundary reminder
CD is not warrant strength and not a gate decision. It speaks only about the local fixity of the current episteme or publication position and its candidate space.
Closure Publication Package Discipline
Minimal closure package
A publishable CD claim should name what has narrowed:
- the rival routes or frames that remain live;
- the route, frame, or interpretation that is currently privileged or fixed;
- the guard,
governingPatternRef,authoritySourceRef, or policy that makes the narrowing binding; - the condition under which an admissible reopen or backoff would occur.
A bare claim such as "now settled" is insufficient when closure affects routing or authority.
Narrowing-source rule
Closure may rise because evidence eliminates rivals, governance temporarily binds a route, or protocol requires fixation under time pressure. State the source of narrowing because different sources imply different reopen expectations.
Partial-closure rule
Closure may be local rather than global. A note can be closed enough for one route while remaining open about broader explanation or classification; a prompt may be fixed enough to hold one question steady while still open enough that rival answers remain live. Publish that locality explicitly.
Continuing and Withdrawn Authority Handling
Authority retention rule
If higher CD carried endpoint expectations, guard claims, or route commitments, a closure drop must say which consequences remain and which are withdrawn.
Admissible retreat record
An admissible retreat through reopen, sketchBackoff, or respecify should retain:
- the prior closure state;
- the reason the prior fixation no longer holds;
- the assumption or route being relaxed;
- the still-binding remainder, if any.
This prevents false continuity after retreat.
Closure versus obligation boundary
High CD may coexist with obligations, but CD is not itself an obligation-bearing governing FPF pattern or authoritySourceRef target. When prose treats "closed" as "must now be done", name the actual governingPatternRef or authoritySourceRef for that claim.
Review Matrix and Reopen Tests
Review matrix
An assurance reader should ask:
- what was narrowed;
- by what
governingPatternRef,authoritySourceRef, or guard it was narrowed; - what would reopen it;
- whether any gate, release, work, evidence, assurance, policy, or adjudication authority survives the claimed closure level;
- whether the publication distinguishes local closure from whole-context finality.
False-finality test
Words such as "final", "settled", or "decided" should be challenged unless the route-governance and guard package is explicit. Final-sounding rhetoric often overstates actual closure.
Cross-facet reminder
Low CD does not imply low articulation, low anchoring, or poor representation. Reviewers should not treat openness as low seriousness.
Split-closure review case
A publication may be closed enough for immediate local work use or reliance use while remaining open about broader explanation, long-horizon consequences, or alternative classification. Allow the split when locality is explicit; reject prose that advertises whole-case finality when only one language-state segment is fixed.
C.2.5:End
U.LanguageStateAnchoringMode
Type: Definitional (D) Status: Stable Normativity: Normative unless marked informative
Plain-name. Language-state anchoring mode.
Use this pattern when. Use C.2.6 when a U.Episteme publication needs to say whether its current position is anchored in bodily enactment, traces, model state, document mediation, operator loop, or an explicit mixed regime.
What goes wrong if missed. A prose note hides an embodied, trace-based, model-latent, or operator-loop cue; bridge-loss notes disappear; and the final publication face is mistaken for the original anchoring regime.
What this buys. A nominal anchoring-mode characteristic that keeps source anchoring, publication face, carrier, bridge loss, evidence, and reliance claims separate while still letting teams compare language-state positions.
Problem frame
Published position claims in the declared language-state chart over U.CharacteristicSpace differ not only by articulation and closure, but by how the U.Episteme named in that claim is anchored to bodies, traces, model states, documents, or operator loops.
Problem
Without an explicit anchoring-mode declaration, embodiment and source anchoring are smuggled into informal prose or folded into representation terms. That makes cues harder to compare, hides bridge-loss notes, and leaves operator-facing language-state work without an explicit anchoring rule.
Forces
Solution
U.LanguageStateAnchoringMode is a nominal characteristic that states the primary anchoring regime of the U.Episteme named by the current position claim: bodily enactment, trace, model state, document, operator loop, or an explicit mixed regime. If source anchoring and current publication-face anchoring differ, both shall be distinguished rather than collapsed.
Kind and characteristic boundary
U.LanguageStateAnchoringMode is a dependent durable characteristic value under the declared U.LanguageStateSpace / U.CharacteristicSpace boundary, not a root U-kind. Its identity is the anchoring-mode basis slot and nominal family for episteme publication positions. This characteristic does not decide evidence, source-currentness, publication-face, carrier, Work, gate, or reliance claims; those claims retain their own definitions and tests.
Starter family
Contribution boundary
U.LanguageStateAnchoringMode is an anchoring-mode characteristic for one U.Episteme position claim. It is not a representation factor bundle, closure state, truth status, evidence relation, source-currentness relation, Work claim, gate claim, or reliance permission by itself. Model-latent, operator-loop, embodied, trace, and document-mediated cases name where the episteme is anchored for the current claim. A publication-face, carrier, source-currentness, bridge-loss, Work, evidence, or gate claim needs its applicable definition or test; anchoring mode alone does not decide it.
If embodiment matters, it shall be declared here or immediately beside this characteristic rather than being hidden inside representation talk.
Mixed-mode rule
AM.Mixed is admissible only when the component modes are named explicitly. "Mixed" shall not be a lazy escape from deciding whether the key anchor is bodily, trace-based, model-latent, document-mediated, or operator-loop based.
Bridge implications
An anchoring shift can matter when a published U.Episteme is translated across semantic contexts. A translation from AM.EmbodiedFelt to AM.DocumentMediated, or from AM.ModelLatent to prose, may provide evidence about an F.9 Bridge or bounded-use claim. Use F.9 to state the Bridge, claim, evidence, and loss account. Use F.9.1 only for a separate optional stance note about that claim.
Archetypal Grounding
Tell. A felt cue, a controller-side probe score, and a textual design note may all be early cues, but they are anchored differently.
Show (System). An alert tied to an operator console is AM.OperatorLoop, not just "text".
Show (Episteme). A model-probe cue grounded in latent state is AM.ModelLatent even when rendered into prose.
Bias-Annotation
The pattern pushes authors to declare anchoring rather than hide it in metaphors such as "the system wants" or "the note suggests".
Conformance Checklist
CC-C.2.6-1Anchoring mode SHALL NOT be inferred from publication phrasing alone when it matters for source use, reliance, or bridge interpretation.CC-C.2.6-2Embodiment-sensitive or operator-loop cases SHOULD declare the embodiment or operator anchor explicitly.CC-C.2.6-3U.LanguageStateAnchoringModeMUST NOT be collapsed intoU.LanguageStateRepresentationFactorBundle.CC-C.2.6-4Mixed-mode declarations SHALL list their component modes explicitly.
Common Anti-Patterns and How to Avoid Them
- Text-only illusion. Treating every cue as document-mediated because it has been written down.
- Representation capture. Using symbolic/distributed labels to hide world-anchoring distinctions.
- Embodiment mystification. Treating bodily or operator-loop cues as beyond explicit publication.
Consequences
The benefit is cleaner reasoning about embodied, operator-facing, trace-based, and model-latent cues. The trade-off is more explicit declaration work and more explicit bridge loss notes when modes shift.
Rationale
The declared language-state chart over U.CharacteristicSpace needs one explicit anchoring basis slot so that A.16.0, A.16.1, B.4.1, and F.9.1 can refer to anchoring regime without redefining it.
SoTA-Echoing
The facet is motivated by embodied cognition, operator-facing interaction practice, active inference, and modern model-probing practice, all of which distinguish cue content from anchoring regime.
Relations
- Builds on:
A.18,C.2.2a,C.2.LS. - Coordinates with:
A.7,A.16.0,A.16,A.16.1,B.4.1,B.5.2.0,C.2.7,F.9for any Bridge and bounded-use claim, andF.9.1only for an optional stance note about that claim. - Constrains: cue publication and bridge loss notes.
Worked Examples and Bridge-Loss Cases
Embodied-to-document shift
A bodily felt cue published as prose usually changes from AM.EmbodiedFelt toward AM.DocumentMediated. That shift is not harmless; it often introduces bridge loss and should be treated as such when cross-context equivalence is claimed.
Model-latent to operator-loop case
A latent probe score may first be AM.ModelLatent, then feed an operator-facing alert face where the working publication becomes AM.OperatorLoop. A conforming account should keep both anchoring modes visible rather than pretending the downstream publication wording fully captures the model-side cue.
Mixed-mode publication
An alert note may admissibly be AM.Mixed when it combines operator-loop anchoring, trace anchoring, and document mediation. But the mix must be named explicitly rather than used as a catch-all escape.
Authoring and Review Guidance
Author prompt
When declaring anchoring mode, ask:
- what is the primary anchor kind?
- does bodily or operator participation matter directly?
- is the key anchor trace-based, model-internal, or document-based?
- if multiple modes matter, which ones and why?
Review prompt
An assurance reader should watch for the common mistake where prose formatting tricks authors into forgetting the original anchoring mode.
Bridge note
If anchoring changes across publication or translation, use F.9 for the Bridge, bounded-use claim, and its evidence and loss account. Use F.9.1 only when a separate stance note about that claim helps replace silent equivalence language with a bounded reading.
Extension and Migration Notes
Local extension rule
Contexts may add local anchoring modes, but they should do so by extension of the starter family rather than by collapsing the family into a text-vs-world binary.
Migration from metaphorical prose
Statements like "the system wants", "the note suggests", or "the operator-facing publication says" should be repaired by naming the actual anchoring mode and the actual detector/enactor or witness structure.
Boundary reminder
U.LanguageStateAnchoringMode does not decide representation, articulation, closure, or trust by itself. It only names how the episteme is anchored.
Anchoring Publication Package Discipline
Minimal anchoring package
A publishable U.LanguageStateAnchoringMode claim should normally identify:
- the primary anchor kind;
- any directly relevant embodiment, operator, trace, model, or document witness;
- the transformation chain if the current note is not at the original anchoring site;
- any secondary modes that remain load-bearing.
This is especially important when the final wording is prose, because prose often hides the anchoring regime.
Source-versus-face rule
Distinguish the anchoring mode of the source cue from the anchoring mode of the current publication face. A bodily cue written into a document may still require AM.EmbodiedFelt as source mode and AM.DocumentMediated as publication face.
Mixed-mode decomposition rule
AM.Mixed is admissible only when its component modes are named and the reason for the mixture is operationally real. It must not become a convenience label for an episteme that has not yet been analyzed.
Anchoring Shift and Transport Discipline
Shift declaration rule
When an episteme crosses from one anchoring mode to another, state whether the shift is merely publication-level or whether it changes what can be preserved, compared, or trusted. A move from operator-loop enactment to report prose, for example, often drops timing, bodily load, and enactment friction.
Bridge-loss rule
If an anchoring shift matters across semantic contexts, use F.9 to state the Bridge, bounded-use claim, and loss account; add an F.9.1 stance note only when it helps explain that claim. C.2.6 only requires the shift to be noticed and not misrepresented as lossless.
Same-content illusion test
Two cues may be paraphrased into the same sentence while remaining differently anchored. If the anchoring regime differs, the cues are not automatically substitutable.
Review Matrix and Extension Tests
Review matrix
An assurance reader should ask:
- what the original anchoring regime was;
- what the current publication regime is;
- whether the transformation chain is explicit;
- whether any bridge loss or stance note is missing;
- whether a declared mixed mode is genuinely decomposed.
Local extension test
A new local anchoring mode is justified only when it answers a distinct anchoring question that the starter family cannot express without distortion.
Cross-facet reminder
Anchoring mode often correlates with representation and articulation changes, but it does not define or test them. Reject prose that uses AM.ModelLatent, AM.EmbodiedFelt, or AM.OperatorLoop as shorthand for being vague, early, trustworthy, or closed.
C.2.6:End
U.LanguageStateRepresentationFactorBundle
Type: Definitional (D) Status: Stable Normativity: Normative unless marked informative
Plain-name. Language-state representation-factor bundle.
Use this pattern when. Use C.2.7 when a governed U.Episteme publication needs to describe how its representation is organized through locality/distribution, sparsity/density, symbolicity/subsymbolicity, or an explicit local factor bundle.
What goes wrong if missed. One representation label such as symbolic, distributed, or encoding basis starts doing too much work: it hides articulation, closure, anchoring, bridge loss, or comparison assumptions.
What this buys. A factor-bundle account of representation that keeps representation organization separate from anchoring, articulation, closure, evidence, carrier, and admissible-use claims.
Problem frame
Published position claims in the declared language-state chart over U.CharacteristicSpace must distinguish representation factors such as locality, sparsity, and symbolicity without pretending they form one master factor.
Problem
Terms such as EncodingBasis collapse several independent choices. That makes comparison brittle and encourages one-factor stories such as distributed = informal or local = precise.
Forces
Solution
U.LanguageStateRepresentationFactorBundle is a factor bundle, not one scalar characteristic. The minimal core starter set is:
U.LocalityDistributionU.SparsityU.Symbolicity
A Context may publish a local alias such as EncodingBasis, but it shall dock back to the underlying factor bundle instead of replacing it.
Kind and factor-bundle boundary
U.LanguageStateRepresentationFactorBundle is a dependent durable factor-bundle value under the declared U.LanguageStateSpace / U.CharacteristicSpace boundary, not a root U-kind. Its identity is the bundle of representation factors used for governed episteme publication positions. Individual factors, aliases, dashboards, model probes, or publication forms do not become separate U-kinds unless another governing pattern admits them.
Minimal factor readings
Non-collapse rules
LanguageStateRepresentationFactorBundle is not:
LanguageStateAnchoringMode;ArticulationExplicitness;LanguageStateClosureDegree;- evidence, source-currentness, publication authority, work permission, or gate readiness.
A representation may be distributed yet have high trace anchoring; symbolic yet low-articulation; sparse yet low-closure. Those combinations shall remain visible. A model-state, embedding, vector-store relation, or operator-facing publication face may fill one or more representation factors, but the factor bundle does not decide the episteme, carrier, evidence, bridge, work, or gate relation by itself.
Extension rule
Contexts may add extra representation factors only if the extension is published as a factor addition rather than as a new master factor that erases the core factor bundle.
Archetypal Grounding
Tell. A model-state cue can be highly distributed but still trace-anchored; a symbolic note can be low articulation if its semantics are still vague.
Show (System). An operator decision aid may mix sparse alert codes and symbolic method-description text.
Show (Episteme). A research probe can move from distributed activation patterns to sparse symbolic hypotheses without any one-step formality story.
Bias-Annotation
The pattern resists folk theories that try to line up one representation factor with one stage or progression story.
Conformance Checklist
CC-C.2.7-1LanguageStateRepresentationFactorBundleSHALL be published as a factor bundle, not as a hidden scalar.CC-C.2.7-2Local aliases such asEncodingBasisMAY exist only with an explicit docking to the governed factors.CC-C.2.7-3Representation factors MUST NOT silently replaceLanguageStateAnchoringModeorLanguageStateClosureDegree.CC-C.2.7-4New local factors SHALL preserve the factor-bundle discipline.
Common Anti-Patterns and How to Avoid Them
- One-factor myth. Treating distributed/local or symbolic/subsymbolic as the whole story.
- Progression collapse. Equating representation shifts with formalization or closure.
- Alias capture. Letting
EncodingBasisor a similar local alias erase the factor bundle.
Consequences
The benefit is cleaner comparison across schools, substrates, and publication forms. The trade-off is that representation talk becomes more explicit and less slogan-friendly.
Rationale
The factor-bundle design keeps the representation basis-slot family in the declared language-state chart over U.CharacteristicSpace orthogonal to articulation, closure, and anchoring.
SoTA-Echoing
This factorization fits current work on sparse distributed representations, hybrid symbolic/neuro-symbolic representation practices, and interpretability practice.
Relations
- Builds on:
A.18,C.2.2a,C.2.LS. - Coordinates with:
C.2.6,A.16.0,A.16,A.16.1,B.4.1,B.5.2.0,F.9for any Bridge and bounded-use claim, andF.9.1only for an optional stance note about that claim. - Constrains: language-state position publication and bridge loss notes around representation shifts.
Worked Examples and Factor Interaction Notes
Distributed but explicit
A model-side summary may be representation-wise distributed and still highly explicit once published into a stable symbolic wrapper. This case matters because it blocks the folk myth that distributed implies vague.
Symbolic but still low-articulation
A glossary-like note may be fully symbolic while still low in AE because the semantic anchors are not yet stabilized. This blocks the opposite myth: symbolic therefore explicit.
Mixed representation publication
An operator-facing publication face may combine sparse alert codes, symbolic method-description text, and distributed back-end model summaries. The representation-factor bundle should make that mixture visible instead of compressing it into one label.
Authoring and Review Guidance
Author prompt
To publish a representation-factor bundle, ask separately:
- how local or distributed is the representation?
- how sparse or dense is it?
- how symbolic or subsymbolic is it?
- which additional factor, if any, genuinely matters enough to publish?
Review prompt
An assurance reader should reject any attempt to use one factor as if it summarized the rest. The factor bundle exists precisely to block that reduction.
Cross-facet reminder
Assurance readers should also watch for silent replacement of LanguageStateAnchoringMode, AE, or CD by representation talk.
Extension and Migration Notes
Local extension rule
Contexts may add extra factors, but each added factor should answer a distinct question rather than duplicating locality, sparsity, or symbolicity under another label.
Migration from alias-heavy prose
Aliases such as EncodingBasis or similar should be unfolded into explicit factor dockings before they are relied upon for comparison, bridge claims, or downstream use.
Boundary reminder
U.LanguageStateRepresentationFactorBundle describes representational organization only. It does not determine admissible use, closure, or anchoring by itself.
Factor-Bundle Publication Discipline
Minimal representation package
A publishable U.LanguageStateRepresentationFactorBundle should normally show the current factor settings for locality/distribution, sparsity/density, and symbolicity/subsymbolicity, together with any declared extra factor. If a factor is intentionally omitted, say so rather than hiding the omission under a compact alias.
No hidden scalar rule
Compact overlays such as "sparse-symbolic" are admissible only when they dock to the underlying factor bundle. No compact label may behave as a hidden master score for comparison, bridge comparison, or stage/progression talk.
Alias docking rule
Local aliases such as EncodingBasis are admissible only when their docking to the governed factors is explicit and stable. If an alias compresses several factors, the compression should remain visible.
Factor Interaction and Cross-Facet Reading Rule
Interaction rule
Representation factors may correlate, but they do not determine one another. Highly distributed cues can still be sparse; symbolic publications can still be locally dense; mixed symbolicity can coexist with either strong or weak articulation. Publish the actual factor bundle rather than narrating one factor as if it predicted the rest.
Cross-facet non-substitution
Representation talk must not silently replace AE, CD, or LanguageStateAnchoringMode. A shift from distributed to symbolic publication may change readability while leaving articulation low, closure open, or anchoring heavily operator-bound.
Bridge reminder
If a representation shift matters in transport across contexts, note that the shift may alter what is preserved or salient. Use F.9 for the Bridge and its bounded-use claim; use F.9.1 only for a separate optional stance note about that claim.
Review Matrix and Extension Tests
Review matrix
An assurance reader should ask:
- are all claimed factors visible in the publication or cited source;
- does any alias hide the factor bundle;
- is one factor being used as if it summarized the whole representation state;
- has representation talk started to replace articulation, closure, or anchoring claims.
Local extension test
An additional factor is justified only if it captures a distinct representational question that cannot be reduced to locality, sparsity, or symbolicity. The extra factor should extend the bundle, not become a rival master factor.
Migration test for source terminology
Source vocabularies often use "symbolic", "distributed", or "encoding basis" as if one term solved the whole classification problem. A conforming migration unpacks the term into explicit factor dockings and then checks whether any cross-facet claims were smuggled into the source label.
Bundle-comparison reminder
Representation bundles may be compared across contexts only after the compared factors are explicit. If one context uses a compact local alias and another publishes the full factor bundle, require explicit docking before treating the two descriptions as commensurable.
C.2.7:End
Declarative Representation Precision Restoration
Type: C.2.P precision-restoration child pattern for declarative-representation overread Status: Stable Normativity: Normative unless a section is explicitly informative
Use this when
Use this pattern when a declarative representation is about to guide action, reliance, gate, release, evidence, method, mechanism, work, or pattern-application claims by its shape alone.
First useful move. Recover the visible expression or artifact; exact current direct object or relation; any current representation or correspondence use; current source or publication relation; tempting stronger action claim; recovered subject pattern; retained use; blocked stronger action claim; and stop or reopen condition. Return the repaired wording and needed stop or subject-pattern return. Use a DeclarativeRepresentationRepair note only when the receiving use needs the repair to remain inspectable.
Quick example. A heat-flow graph in a reactor-cooling review can show preserved and lost flow relations. It does not authorize a valve change by graph shape. The repair keeps the graph path as graph structure, returns release or gate reliance to the gate, source, and evidence patterns, and blocks the hidden work-permission claim.
Use this pattern especially when:
- a graph path,
PathSlice, flow valuation, transformation-flow structure line, or graph expression over such a structure is overread as a prescribed work route or workflow; - an
A.10evidence path is overread as approval, permission, release, gate passage, or assurance; - a query, access path, query plan, table, dashboard, schema, checklist predicate, or API description is overread as method, work plan, performed work, gate, permission, or proof;
- a publication face, source-chain relation, carrier file path, mathematical representation, method-description representation, or FPF pattern relation is overread as call, dispatch, invocation, send, receive, route, or pattern application;
- method-like wording hides whether the current claim concerns
U.Method,U.MethodDescription, formal substrate, mathematical-lens use,U.Mechanism,U.WorkPlan, datedU.Work, evidence relation, source relation, or quote-only source wording.
What goes wrong if missed. The representation appears to do work it cannot do. A path "routes" a decision, a query "calls" a pattern, a dashboard "authorizes" release, a checklist predicate "runs" a process, an evidence path "permits" action, or a program-looking text becomes "the method" without recovering method semantics, method description, formal substrate, mechanism, work plan, work, evidence, or source-use relation.
What this buys. The working reader keeps a visible expression useful without making it magical or hiding its subject pattern. Graph paths and structures, evidence or provenance relations, queries and formal objects, publication faces, and pattern relations keep their own kinds. When a graph, file, tile, table, or face represents one of them, the exact representation or correspondence use is stated separately. For method-like wording, the reader identifies the direct object or relation, any represented object or claim, and the exact relation that gives the expression its current use before selecting method, method description, formal substrate, mechanism, plan, work, evidence, source, gate, or release guidance.
Not this pattern when.
- If the graph path,
PathSlice, or flow valuation is already current as graph structure, useE.18directly. - If the evidence relation or provenance relation for a claim is already current, use
A.10directly. - If the publication face or source-use relation is already current, use
E.17,E.17.EFP,C.2.P, or the direct publication pattern. - If the current claim concerns a semantic way of doing, use
A.3.1; if it concerns the description of that way, useA.3.2. - If the current claim concerns operation algebra, laws, admissibility predicates, transport, audit, or governing-definition assignment, use
A.6.1orE.20. - If the current claim concerns planned work or dated work, use
A.15.2orA.15.1. - If the word is only quoted source wording or ordinary navigation prose with no FPF-governed claim, keep it quote-only or ordinary.
Problem frame
FPF work meets many declarative-looking expressions and many direct objects or relations: graph and table artifacts; paths and selected structures; state predicates and values; dashboard and publication faces; evidence, provenance, source, and pattern relations; formal substrates; and method descriptions. Some visible expressions represent a separately governed object or claim; other named items are themselves the current direct object or relation. Their common declarative appearance does not make them peers in one kind.
The recurring failure is a category shift. Because some representations look like paths, pipelines, calls, dispatches, states, gates, or control programs, the prose starts granting them operational effects. A representation then seems to authorize work, pass a gate, enact a method, prove a result, release a system, or select a pattern by its shape alone.
This pattern repairs that shift. It does not build a general theory of representation. It only restores the exact FPF-governed object, relation, or claim and its subject pattern when declarative-looking wording is overread as imperative or operational.
Problem
Without this repair:
- Graph path becomes work route. A path or path slice in
E.18is treated as an ordered work narrative, even when no work occurrence, work plan, or method description is current. - Evidence path becomes permission. An evidence relation or provenance relation is treated as approval, gate passage, release, safety, or authority rather than as evidence for a named claim or effect.
- Query becomes method. A query, access path, query plan, or dashboard is treated as the semantic way of doing, rather than as a representation, method description, evidence relation, source relation, or ordinary source wording.
- Pattern relation overread as dispatch. Pattern application prose starts saying that one pattern exits to, routes to, calls, invokes, receives, owns, or dispatches another, hiding declarative pattern relations and subject pattern selection.
- Programming-paradigm label becomes ontology. Imperative, functional, logical, constraint, object-centric event, effect-handler, pipeline, orchestration, or workflow wording is treated as the FPF kind rather than as one representation style or source label.
- Mechanism, method, and work collapse. A method-like expression is repaired to
methodormechanismby vocabulary rather than by the current claim: way of doing, description, formal substrate, law-governed mechanism, plan, occurrence, evidence, or quote-only wording.
Forces
Solution
Repair declarative-representation overread by separating the visible expression, the direct object or relation, and any representation use before naming the subject pattern for the current claim.
The repair order is:
- Name the visible expression or artifact. Quote or identify the graph highlight, file, query text, predicate display, dashboard tile, table, publication face, path diagram, carrier path, mathematical expression, method-description expression, or pattern sentence that prompted the overread.
- Recover the exact current direct object or relation. Name the graph structure,
PathSlice, flow valuation, evidence or provenance relation, state predicate or value, query or formal object, publication face or occurrence, formal substrate, claim-bearing episteme, source relation, carrier-side object, pattern relation, or other direct outcome under its own governor. This is a list of alternative recovery outcomes, not representation kinds in one ontology. - Distinguish the direct object from any representation or correspondence use. When the visible expression represents a separately identified object or claim, name the exact relation and target. When the direct object or relation itself is current and no separate representation claim is needed, keep that direct use; do not relabel the direct object as a representation kind. Record
noneonly when the receiving use needs an inspectable account of that distinction. - Recover source or publication relation when current. If a face, source chain, generated explanation, copied text, dashboard, file path, or publication unit is current, use the publication pattern or source-use pattern governing that relation.
- Name the tempting stronger action claim. Say what the visible expression is being asked to do by resemblance: route, call, dispatch, invoke, run, flow, send, receive, authorize, release, prove, prescribe, execute, select, pass a gate, or record work.
- Select the subject pattern. Use the direct pattern when the object or relation is already recovered; otherwise use this pattern only long enough to recover the direct outcome, any representation use, and the blocked stronger claim.
- State retained use. Keep the weaker useful use: graph structure, evidence relation, source-finding, state predicate, publication face, exact representation use, formal-substrate input, candidate method reading, or pattern relation.
- State the blocked stronger action claim. Block only the stronger claim that is not recoverable.
- Stop or reopen. Stop when the subject pattern can carry the next claim. Before stopping, ask what claim, evidence relation, gate relation, safety relation, method relation, work relation, or source relation would become less reviewable if the visible expression were accepted as the stronger claim. Reopen if a later source changes the visible expression, direct object or relation, representation relation or target, source currentness, subject pattern, or intended use.
DeclarativeRepresentationRepair note
Use this compact note only when the receiving use needs an inspectable repair of FPF-governed wording:
The ordinary result is the repaired wording, exact direct outcome, any current representation use, retained use, blocked stronger claim, and needed stop or reopen condition. The optional note records these values when the receiving use needs them to remain inspectable. If the subject pattern already supplies a suitable record, use it without duplicating the repair note here.
Use four plain questions before the claim-and-pattern table: What visible thing am I looking at? What direct object or relation is current? What, if anything, does it represent? What stronger action claim must remain blocked?
Subject pattern selection
Legitimate path and route settlement
path is not banned.
A.10 evidence path for <claim, effect, or use> is legitimate when the evidence relation or provenance relation for the named claim, effect, or reliance use is current. E.18 graph path and PathSlice are legitimate when the graph object, path, slice, crossing, or flow valuation is current. Carrier file paths, URLs, mathematical paths, and quoted source paths are legitimate when their notation, source-use function, or use relation is current.
The defect is not the word. The defect is hidden ontology: the sentence treats a representation as if something literally ran, flowed, executed, authorized, released, proved, selected, or prescribed action without first naming the exact direct object or relation and its subject pattern.
When the representation is route-shaped, loop-shaped, graph-shaped, diffusion-like, or workflow-like, ask first which object is current:
Do not repair route-shaped wording by replacing it with another route-shaped word. Always recover the visible expression, exact direct object or relation, representation or correspondence use or none, retained use, blocked stronger action claim, subject pattern, and stop or reopen condition. When the representation use is none, that is enough to close the repair; do not require a represented target, preserved and lost structure, or a mathematical-lens admissible-use account. When an exact representation, mathematical-lens, or selected-structure use is current, also name its target, the preserved and lost structure, and the admitted and blocked uses required by C.29 or that structure's subject pattern.
Method, algorithm, mechanism, plan, and work settlement
Do not repair algorithm, program, solver, proof, recipe, method, workflow, process, procedure, access path, query plan, or control strategy by choosing one fashionable replacement.
Method-description membership guard. A code file, SOP, proof script, solver model, process model, protocol, recipe, diagram, or query plan is only a representation clue. First identify the claim-bearing episteme under C.2.1. Apply A.3.2 only when that same episteme has one admitted U.Method as its exact EntityOfConcern and at least one claim says how that method is done, such as its transformation or enactment concern, applicability, precondition, intended effect or preserved condition, bound, generic participant meaning, or internal method composition. A name, author, citation, approval, file form, runnable configuration, or representation correspondence alone is a near-miss. If the test fails, do not assign U.MethodDescription; keep the representation, publication, plan, dated work, result, formal substrate, mechanism declaration, evidence, or source use with its subject pattern. A representation or publication change does not decide membership. If claim content, exact method, or effective reference scheme changes, C.2.1 first identifies the resulting episteme; then apply A.3.2 to that individual.
Recover what the source is actually about and what it asserts:
Cooling contrast. A reusable cooling procedure can be U.Method only after the context-local way of doing, its transformation or enactment kind, transformed referent or structure, preconditions, and intended effects are recovered. “Required cooling effect” alone is claim content, not a method. If a later cooling episode actually changes the governed loop state, that occurrence remains a separate A.3.4 U.Transformation and needs its own changed referent, boundary, conditions, actual facts, and continuity or reidentification basis.
When the source label hides method, mechanism, formal-substrate, work, evidence, gate, result, or temporal claims, use E.10.ARCH:3.1 to state the project concern in ordinary words, then identify each exact object and claim separately. For this host, repair only the representation overread and name the subject pattern for the current claim; linked values remain under their own subject patterns rather than becoming one representation-repair claim.
Programming-paradigm and process-model settlement
Imperative, functional, logical, constraint, object-centric event, effect-handler, pipeline, orchestration, Declare-style, SQL-like, e-graph, hypergraph, or process-mining wording is a clue to identify the visible expression, direct object or relation, any representation use, and current claim. It is not a decision procedure by itself.
Current practice makes the old contrast between imperative and declarative labels too weak as a final ontology:
- constructor and process-theory lines keep computation, information, dynamics, and procedure close to possible or impossible transformations and compositional realization;
- scoped effects and handlers separate operation syntax, semantic handling, scopes, resources, equations, type information, and effect information;
- Declare-style process models and object-centric event logs distinguish constraints, events, objects, relations, ingestion, transformation, storage, and analysis;
- e-graph and monoidal-rewriting work shows that computation or process representation may be equivalence or composition structure rather than instruction order.
Use those lines as guardrails: recover the exact FPF-governed object, relation, claim, or representation use and its subject pattern instead of replacing one programming-paradigm label with another.
Worked slices
Graph path in a transformation-flow structure
Wording: "The P2W path routes the team from principle to work."
Repair:
A graph publication or pattern publication remains a separately governed publication object. If one is current, state its exact source or publication relation and participants in the neighbouring claim; neither publication object belongs in SourceOrPublicationRelation by mention alone.
Evidence path near release
Wording: "The evidence path authorizes release."
Repair: A.10 can state an evidence path for the claim or effect. Release, permission, or gate passage requires the authority, gate, or release pattern that defines or constrains that claim. This pattern is used only if path wording itself is causing the representation to be overread as a permission route.
Query plan and access path
Wording: "The query plan calls the production work sequence."
Repair: recover whether the query plan represents optimizer choices, expresses claims about an exact method, presents a formal substrate, supplies a source cue or evidence relation, states a work plan, or records an actual query run. If it only represents query-evaluation choices, stop at the representation. Use A.3.1 for a reusable semantic way-of-doing claim. Use A.3.2 only when the claim-bearing episteme passes the MethodDescription membership guard in 4.4. Use A.15.1 for a performed query run, together with the exact evidence or source-use relation when that later claim is current.
Dashboard predicate
Wording: "The dashboard green path lets the release move."
Repair: recover dashboard face, source relation, status or state bearer, value frame, source currentness, and gate or release claim. The dashboard may be a publication face and source cue; it is not release permission unless the gate or authority pattern consumes the source and states that effect.
Pattern relation
Wording: "This pattern exits to A.10."
Repair: if the current relation is "use A.10 when an evidence relation or provenance relation is current", write that declarative boundary. Do not use exit, receiver, route, owner, home, dispatch, or call language unless the pattern is actually about an action occurrence, work plan, control mechanism, or communication relation that has those semantics.
Solver algorithm
Wording: "The solver algorithm is the mechanism."
Repair: first identify what the solver expression represents and which claim is current. A solver configuration may represent claims carried by an episteme that qualifies as U.MethodDescription only after the 4.4 membership guard; the configuration is not that episteme by file form or executability. The reusable semantic way of solving may be U.Method; the MILP formulation may expose a formal substrate and mathematical-lens use; a reusable operation algebra with laws and admissibility predicates may be U.Mechanism; a solver run may be U.Work; and a run result may support another claim through its direct evidence relation. Select A.6.1 and E.20 only when their mechanism fields are present in the current claim.
Reactor-cooling flow graph
Wording: "The preserved heat-flow path authorizes the valve change."
Repair:
An engineering-review publication and a gate record remain separate objects. State any exact source or publication relation with its participants, and keep any gate relation under its subject pattern; neither object belongs in SourceOrPublicationRelation.
CRISPR guide-selection table
Wording: "The guide-selection table approves the edit."
Repair:
A lab notebook, protocol publication, source episteme, and review record remain separate objects. State an exact source or publication relation and its participants only when it obtains; none of these objects belongs in SourceOrPublicationRelation by mention alone.
Conformance checklist
Common anti-patterns
Relations
- Builds on:
E.10,E.10.ARCH,C.2.P,A.7,E.17,E.8, andF.19. - Coordinates with:
E.18,E.18.1,A.10,A.19.SPR,A.3.1,A.3.2,A.6.0,C.29,A.6.1,E.20,A.15.2,A.15.1,A.15.4,A.20,A.21,B.3, and direct publication, gate, authority, release, evidence, method, work, and assurance patterns when those claims are being made. - Specializes:
C.2.Pfor one recurring case: declarative representation and imperative-metaphor overread. - Used by:
E.10.ARCHapplicability-row distribution and full-pattern text precision restoration when route, path, workflow, call, or dispatch wording hides representation use.
Consequences
- FPF can keep useful graph, path, query, table, dashboard, publication, and pattern-relation vocabulary without banning ordinary words.
- The repair blocks hidden authority, release, gate, evidence, method, mechanism, work, and pattern-dispatch claims by requiring the subject pattern named by value.
- Method and mechanism claims become easier to compose because
E.10.ARCH:3.1keeps separately recovered values connected only by the exact direct relations and participant meanings supplied by their subject patterns, without treating source labels as alternate ontology. - The cost is a small recovery note when representation wording is actually carrying FPF-governed use. Ordinary navigation, source quotation, and already-governed graph or evidence paths do not need the note.
SoTA-Echoing
This pattern uses external sources only for the representation-overread repair question. They do not replace FPF ontology, and older famous sources are lineage or contrast unless a current source below supplies the contemporary payload.
C.2.P.DR:End
Kinds, Intent and Extent, and Typed Reasoning
Type: Typed reasoning discipline pattern Status: Stable Normativity: Normative unless a section is explicitly informative
Use This When
Use this pattern when a claim needs a reusable kind, a subkind comparison, a judgment about whether one exact candidate satisfies one kind, or an optional representation of the candidates that satisfy it in one exact context slice. A kind may be used locally without receiving its own public U.* name; “local” describes the bounded use, not an identity component.
What goes wrong if missed. A source type, practice label, programming class, schema label, mathematical set, or public U.* name starts doing several jobs at once. A source boundary splits one unchanged kind; several kinds inside one source collapse; the kind is confused with its declaration; evidence is treated as membership; a non-applicable request becomes unknown; or a current extension becomes ontology.
What this buys. A practitioner can recover the kind's membership distinction, the declaration used to classify, an admissibility result, one three-valued judgment when admissible, and any optional extension representation while leaving source provenance, direct world-side conditions, evidence, scope, Work, and public naming with their own patterns.
Primary EntityOfConcern. One typed-reasoning question: the exact U.Kind individual, its intended candidate domain and membership distinction, any U.SubkindOf comparison needed by the claim, and the C.3.2 candidate question the use actually asks. The exact KindSignature edition carries the effective U.ReferenceScheme in its claim content; the scheme and practice/source provenance are not stored on the kind.
First useful move. Write the ordinary conclusion first. For example: Pump #14 counts as a cooling pump in this plant slice because it satisfies the declared cooling-pump condition. Add a reusable declaration, admissibility detail, explicit judgment, support reference, or extension representation only when a named receiving use needs it.
Not this pattern when. Use E.24.UK when the question is admission of another durable public FPF U-kind. Use the direct subject pattern when the question is whether a physical quality, relation, registration, certification, publication occurrence, Work, or other governed condition obtains. Use A.2.6 for claim, work, or publication scope and C.29 for a claim-bearing mathematical representation.
Problem Frame
U.Kind is the admitted meta-kind whose individuals are reusable intensional classification distinctions. One kind individual is recovered by its declared candidate domain, the membership condition that distinguishes intended members from non-members, and the continuity rule for a material declaration change. A KindSignature states that content for repeated use but is not the kind itself. A current extension can change while the kind continues, and two different intensional kinds can happen to classify the same current candidates.
A practice, source, team, or locality tells a reviewer where meaning may have changed. It does not decide kind identity. When a typed use moves, compare the exact membership distinctions. Reuse the same kind when the candidate domain and operative distinction continue. If they differ, identify two kinds; only then can C.3.3 ask whether an exact directional KindBridge obtains. When local wording or interpretation also differs, F.9 may relate the corresponding F.17 cells, but it neither creates the kinds nor maps a U.ReferenceScheme as a whole. A changed scheme creates another KindSignature edition; C.3.1 separately decides kind continuity. A changed U.ContextSlice alone creates neither a kind nor a bridge.
Problem
A project often needs classification before it needs another public ontology name. If the kind, its definition, the classified candidate, a record about the candidate, and a displayed set of current members are treated as one object, a label classifies by itself, evidence creates its subject, missing information proves non-membership, a table becomes an entity set, or a plan row becomes actual Work. If locality is made an identity key, the same kind also fragments across teams and sources. C.3 keeps each conclusion at its direct pattern.
Forces
Four Objects and a Pre-judgment Check
Keep these four objects separately recoverable:
Before the judgment, C.3.2 returns admissible or not-applicable. Candidate mismatch with the declared ValueKind, or a slice outside declared applicability, is not-applicable and no three-valued judgment is formed. Missing support or an unavailable dependency for an admissible candidate instead yields unknown.
Scope is not a fifth part of the kind. A KindSignature episteme may carry its own U.ClaimScope, and a separate classification assertion carries the scope of that assertion. The U.ContextSlice is an evaluation input.
Solution
Use the lightest object that answers the current typed-reasoning question.
- Recover the kind. Name the candidate domain and the operative membership distinction: what an intended member must satisfy and what separates a relevant non-member. Record the continuity rule used when that distinction changes. Keep practice/source provenance as a cue to compare definitions, not as an automatic identity key. Do not store the current use, ClaimScope, context slice, or reference scheme on the kind.
- Use C.3.1 for subkind and continuity. A
U.SubkindOffact obtains through exact criterion entailment under an aligned interpretation or through exhaustive evaluation over a deliberately closed finite domain. The facts form a preorder. Opposite facts between distinct kinds may express classification equivalence for that applicability; a consumer may order the resulting equivalence groups without identifying the kinds. - Use C.3.2 for declaration and admissible judgment. A repeated condition may justify a
KindSignature. First check candidateValueKindand applicability. Only an admissible application returnstrue,false, orunknown. - Let the governed criterion condition decide. A direct quality, relation, construction, episteme, registration, certification, publication occurrence, legal status, or other governed condition makes the criterion hold when the criterion actually names it. An observation, record, or source used merely as evidence does not constitute an independently governed condition. Use each condition's direct pattern.
- Keep four outcomes distinct.
not-applicablemeans the judgment should not be formed. For an admissible candidate, a satisfied criterion givestrue, a known failed criterion givesfalse, and missing support or an unavailable required dependency givesunknown. A guard may decline use without rewriting any of these results. - Materialize an extension only for use. A query, quantification, comparison, or review may need
KindExtension(k, slice). It represents admissible candidates judgedtrue; notation, rows, or set membership do not create an ontic collection or classification relation. - Keep scope, formality, Work, and publication separate. Formality characterizes the declaration episteme. Scope belongs to claims or capabilities.
U.Workis a kind andW : U.Workis one independently grounded dated work occurrence. Plans, logs, cards, field bundles, carriers, and rows remain their own objects.
Typed reasoning composes with F-G-R and USM in this order: recover kind compatibility; check classification admissibility and, when admissible, the exact judgment; separately check claim-scope coverage; then apply support, assurance, freshness, and any justified bridge consequence required by the receiver.
Decision Split
When typed reasoning is part of a structural construction-to-representation passage from a constructive representation or working model to a target kind or logical representation, cite StructuralCT2RTypingGroundingUnfoldingStructureBlock from B.3.5. C.3 contributes only the kind, admissibility and judgment, subkind, and bridge loci inside that B.3.5-governed local A.22.CGUS specialization. It does not create separate unfolding-structure authority and does not make a constructive trace, working-model relation, proof, evidence relation, or classification true by label. For general diagnostic recovery from an inadequate working account to the exact subject construction, use A.7.1; classification remains one possible locus rather than a general ontology-return method.
The unfolding is admitted only when the block names the starting representation, target kind or logical representation, current bridge when one is used, preserved structure, lost or collapsed structure, CL or CL^k, admissible reuse, blocked substitution, and the proof or evidence subject pattern when that stronger claim is current.
Archetypal Grounding
Bias-Annotation
C.3 counters lexical, locality, document, and ontology-growth bias. A familiar word, source label, or practice boundary supplies neither kind identity nor membership. A record used as evidence does not create an independently governed condition, while an episteme, status, or relation directly named by the criterion keeps its own governor. The kind/declaration/admissibility/judgment/extension split and the readable first move keep the remedy usable.
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
- Treating a programming type, schema class, source ontology class, regulatory category, or ordinary noun as a durable public FPF U-kind.
- Treating a
KindSignatureas the kind, or attaching its formality and claim scope to the kind. - Using a world-side belongs-to predicate or minting a classification relation merely to state one judgment.
- Treating evidence availability, a schema row, or a publication form as the fact that makes classification true.
- Returning
falsewhen the criterion cannot be evaluated. - Treating
KindExtensionor mathematical set notation as ontology. - Repairing a subkind counterexample by silently changing an extension table.
- Treating a plan or work record as a dated work occurrence.
Consequences
Benefits. C.3 supports local typed claims, subkind reasoning, classification, and queryable extensions without premature ontology growth or evidence-created membership.
Costs. Reliance-bearing uses must recover the kind distinction, pin the declaration and slice, check admissibility, and keep not-applicable, false, and unknown distinct.
Risks avoided. False sameness, implicit time, scope-on-kind, record ontology, accidental relation minting, kind/individual substitution, and mathematical-set overread are blocked at the first use.
Rationale
The kind, its declaration, pre-judgment admissibility, one classification judgment when admissible, and a representation of current true members answer different engineering questions and change for different reasons. Keeping them separate lets a kind continue across compatible declaration revisions, lets candidate state change an extension without changing the kind, and lets evidence or a guard change reliance without rewriting the world-side classification.
SoTA-Echoing
Model theory, type systems, ontology engineering, and schema practice distinguish intensional declarations, candidate evaluation, extensions, and assertion scope. C.3 adapts that separation to FPF's object discipline: declaration epistemes follow A.6.0 and C.2.1, context slices and claim scope follow A.2.6, mathematical representations follow C.29, and durable kind admission follows E.24.UK.
Detail Map
C.3 is the head pattern for typed reasoning. It leaves each detailed mechanism at its direct neighboring pattern while preserving a discoverable route to that mechanism.
Do not treat this compact head pattern as the whole C.3 discipline when a case needs declaration, classification, extension, Bridge, kind-use adaptation, abstraction, or applied-guard detail. Use the neighboring C.3 pattern that defines or constrains the live detail.
Relations
- Builds on:
A.2.6context-slice and scope discipline,A.6.0reusable declaration discipline,C.2.1episteme identity, F-G-R, and direct subject patterns for candidate features. - Coordinates with:
C.3.1throughC.3.5,C.3.A,C.29,E.24.UK,A.8,A.11,F.8,F.18, and genericA.22.CGUSwhen typed reasoning is one locus in an admitted unfolding structure; coordinates withStructuralCT2RTypingGroundingUnfoldingStructureBlockonly when C.3 supplies local-kind, judgment, subkind, and bridge loci inside a structural construction-to-typed or logical projection, with any cross-local bridge remaining a bridge within that projection rather than an alternative trigger; coordinates withA.7.1for a general diagnostic return. - Does not replace: direct candidate-feature ontology, A.14 collection membership,
A.2.6scope,C.29representation use, ontic settlement inE.24, U-kind admission inE.24.UK, or naming in Part F.
C.3:End
U.Kind and U.SubkindOf Core
Type: Kind identity, subkind relation, and continuity pattern Status: Stable Normativity: Normative unless a section is explicitly informative
Use This When
Use this pattern when work must recover one reusable kind, decide whether one kind is a subkind of another, or decide whether the same kind continues across a changed KindSignature edition.
What goes wrong if missed. A source or practice label becomes an identity key, U.SubkindOf carries dependency or construction, a finite sample is mistaken for a universal order, mutually classifying kinds are silently merged, or a changed declaration is treated as automatically new or automatically harmless.
What this buys. The user gets an operational kind-continuity test, a replayable subkind test, and a small preorder that remains distinct from declaration identity, current extension, evidence, bridging, and public naming.
Primary EntityOfConcern. One U.Kind individual recovered through its candidate domain, operative membership condition, intended member/non-member distinction, and continuity rule; or one proposed U.SubkindOf relation between exact kind participants within declared applicability.
First useful move. Write the ordinary claim first: CoolingPumpKind is a subkind of PumpKind because every candidate that satisfies the declared cooling-pump condition also satisfies the pump condition. Then name the exact criteria and applicability that make that statement true. Introduce an occurrence designator or formal equivalence grouping only when a receiver uses it.
Not this pattern when. Use C.3.2 for a declaration, admissibility result, candidate classification, or extension; C.3.3 only for a claimed correspondence between independently identified distinct kinds; and E.24.UK when admitting another durable public kind rather than using an already admitted U.Kind individual.
Problem Frame
A practice/source boundary is provenance and a comparison cue. It affects the continuity decision only when comparison exposes a real difference in the candidate domain or membership distinction.
U.SubkindOf is separately admitted by E24UK-AR-USUBKINDOF-R5-01 as a same-individual dependent kind under U.Relation. Its participants are an exact narrower kind and broader kind. An effective reference scheme and aligned KindSignature editions make the criteria interpretable and qualify applicability; they are not relation participants or occurrence-identity discriminators. Candidate state, context slice, declaration edition, kind identity, and one obtaining subkind relation can therefore change for different reasons.
Problem
The sentence cooling pump is a pump is useful only when the membership conditions justify it. A current extension table can hide a bad proposal, and different intensional kinds can happen to classify the same candidates. Conversely, a unit rewrite, source move, or clearer declaration need not create another kind. The core needs an obtaining test for the relation and a before/after test for kind continuity without treating a signature, sample, locality, or extension as the kind.
Forces
Core Objects
Direct U.SubkindOf Relation Boundary
A readable sentence such as CoolingPumpKind is a subkind of PumpKind for this declared plant use states that the direct relation obtains. It needs no occurrence identifier when no receiver distinguishes or refers to the occurrence.
The criterion-entailment branch obtains when the exact narrower membership condition entails the broader one under the aligned interpretation and applicability. The closed-domain branch obtains only when the candidate domain is deliberately finite and closed, every candidate's admissibility has been checked, and exhaustive evaluation leaves no narrower true without a broader true. A counterexample refutes either proposal. A missing dependency or unknown judgment cannot establish either branch; a not-applicable request is outside the comparison.
When a receiver needs one occurrence, R_sub is participant-determined by the ordered pair of kind identities. The effective scheme, aligned signatures, and applicability qualify how obtaining is tested and asserted. A scheme-edition change therefore prompts an alignment and renewed test; it does not create another relation occurrence. If the same participants still satisfy the condition, the same relation continues to obtain. If they no longer do, the prior obtaining claim is no longer current; another assertion may record that change without inventing a scheme-keyed occurrence.
Solution
- Recover each kind before comparing it. For each kind, state the candidate domain, membership condition, intended member/non-member contrast, and continuity rule. Use practice/source provenance to locate the declaration, not to decide identity.
- Check admissibility first. Compare only candidates admissible under both aligned declarations and the stated applicability.
not-applicableforms no C.3.2 judgment. - Select one obtaining branch. Use exact criterion entailment when the membership rules can be compared directly. Use exhaustive evaluation only for a deliberately closed finite domain. State which branch and where it applies.
- Keep observations in their proper role. A non-exhaustive sample, test run, or extension can support the subkind assertion and expose a counterexample. It cannot close an open-domain obtaining claim.
- Keep a preorder over obtaining facts. Reflexivity and transitivity apply. Mutual facts between distinct kinds record classification equivalence for that alignment; they do not imply kind identity. Use the equivalence groups only when a receiver needs a partial order.
- Separate relation, predicate, and assertion. Use the readable relation sentence first. Add
R_sub, a C.2.1 assertion, evidence, or publication only when a named receiver consumes that object. - Diagnose counterexamples at the rule. Repair a false relation proposal, incompatible declaration alignment, or missing distinct-kind bridge. Do not edit an extension row to make the order appear true.
- Decide kind continuity independently. Apply the before/after test in section 6 whenever criterion, candidate domain, assumptions, dependencies, effective scheme, or locality changes. Another
KindSignatureedition neither proves nor denies kind continuity. - Keep scope and Work outside the kind. A kind carries no claim scope. An exact
W : U.Workremains a dated work occurrence under its direct pattern; a plan, log, label, or classification record is a separate episteme.
Continuity Decision
Compare the old and proposed declarations in this order:
Preserving change. CoolingPumpSignature-3 replaces litres-per-second with an exactly aligned SI expression, preserves the pump candidate domain, cooling-performance discriminator, intended member and non-member probes, and maintenance use. The same CoolingPumpKind continues; new judgments cite edition 3.
Identity-breaking change. A proposed edition replaces physical cooling performance with the presence of schema label CoolingPump. A physical pump without the row changes from member to non-member and a labelled non-performing row can appear to qualify. The operative distinction and candidate domain changed; identify another kind rather than continuing CoolingPumpKind.
Locality change. Journal and grant teams may reuse one exact ReviewerSystemRole when candidate Systems, required contribution, and acceptance condition remain aligned. If grant review requires a different contribution or admits a materially different candidate boundary, identify another kind. The two labels decide neither case.
Archetypal Grounding
Bias-Annotation
C.3.1 counters hierarchy, sample-as-law, assertion-as-world, locality, and table-repair bias. A stronger-looking edge is not automatically an obtaining relation; a sample does not close an open domain; mutual classification does not identify two intensional kinds; a changed source does not split one; and an extension remains an output representation rather than the place to repair the rule.
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
- Encoding dependency, part-whole, slot filling, construction, system-role assignment, or admission as
U.SubkindOf, or treating a predicate expression, assertion, diagram edge, or table row as the obtaining relation occurrence. - Treating a source hierarchy or public-looking spelling as durable FPF ontology.
- Treating
KindSignatureas the kind or its formality as a property of the kind. - Assuming every signature edit makes a new kind, or that no signature edit can make one.
- Comparing extensions across incompatible editions and repairing a counterexample by changing rows.
- Storing claim scope on a kind.
- Treating a work label or record as an individual work occurrence.
Consequences
Benefits. Local typed compatibility remains small while its consequences for actual candidate judgments are testable.
Costs. A declaration change that matters to later classification needs an explicit edition and a separate continuity decision.
Risks avoided. False hierarchy, silent redefinition, retrospective reinterpretation, table-created membership, and kind/individual substitution are blocked.
Rationale
Kind identity, direct U.SubkindOf obtaining, assertion identity, declaration identity, candidate state, and current extension answer different questions and change under different conditions. Their separation lets a kind survive a compatible declaration revision while preventing an assertion or revised criterion from creating an order fact, silently rewriting prior classifications, or hiding a non-obtaining subkind proposal. Keeping the core small also prevents construction, admission, naming, scope, slot discipline, or dependency from being smuggled into one hierarchy relation.
SoTA-Echoing
Type theory, ontology engineering, and versioned schema practice distinguish intensional identity, preorders, equivalence classes, interpretation editions, and extensions. C.3.1 keeps that distinction but gives practitioners two replayable obtaining branches and a before/after continuity test; C.3.2 owns admissibility and judgment, C.3.3 owns distinct-kind correspondence, and E.24.UK owns the exact public admissions.
Relations
- Specializes:
A.6.RELforU.SubkindOf: exact ordered kind participants, criterion-entailment or exhaustive closed-domain obtaining, applicability, lightweight occurrence use, and participant-determined identity; schemes and declaration editions qualify interpretation and assertion rather than occurrence identity. - Builds on:
C.3, A.6.0 declaration identity, C.2.1 episteme and assertion identity, A.2.6/USM context-slice and scope discipline, F-G-R, and C.2.3 formality. - Coordinates with:
C.3.2judgments and extensions,C.3.3correspondence between independently identified distinct kinds,A.2when one local kind is a system-role kind,A.6.5declaration-slot uses that consume an already obtaining subkind relation,C.29representations,E.24.UKdurable U-kind admission, andA.8,A.11,F.8, andF.5when public kind governance is current. - Does not replace: C.2.1 governance of affirmative, negative, or unresolved subkind assertions; a direct candidate-feature governor; classification assertion; kind declaration; context bridge; or public naming decision.
C.3.1:End
Kind Intent, Membership Judgment, and Extension
Type: Kind declaration and classification pattern Status: Stable Normativity: Normative unless a section is explicitly informative
Use This When
Use this pattern when repeated typed reasoning needs one explicit kind criterion, when one exact entity or non-entity value must first be checked as applicable and then judged against that criterion in one context slice, or when a named use needs a representation of the candidates currently judged true.
What goes wrong if missed. A kind is confused with its declaration, a practice label splits one kind, a measurement or schema label creates membership, an out-of-domain request becomes unknown, missing information becomes false, a set becomes ontology, or a guard decision rewrites the classification.
What this buys. A practitioner can state an ordinary result, pin the declaration and slice when reliance requires it, distinguish not-applicable from true, false, and unknown, and materialize an extension only for a receiving query or review. A manager can separately change declaration formality, assurance for a relied-on assertion, or claim scope without treating them as one maturity ladder.
Primary EntityOfConcern. One classification use: exact candidate, kind, KindSignature edition, context slice, pre-judgment admissibility, and—only when admissible—the judgment value.
First useful move. Write the readable result first: Pump #14 counts as a cooling pump in this plant slice because it satisfies the declared cooling-pump condition. Before evaluating, confirm that a pump candidate and this slice are within the declaration's candidate domain and applicability. Cite support only when the receiving use relies on it; create a reusable signature or extension only for repeated or set-consuming use.
Not this pattern when. Use the direct subject pattern to establish the candidate and the exact quality, relation, episteme, status, publication occurrence, or other condition named by the criterion; A.14 for membership in a collection; C.3.3 for a claimed correspondence between distinct kinds; C.29 for a claim-bearing mathematical representation; and E.24.UK for admission of another durable public kind.
Problem Frame
A kind can support useful typed reasoning without acquiring its own public U.* label. Its intent may need a reusable declaration, one candidate may need a current judgment, and a query may need a set representation. These are different objects. Before a judgment exists, the candidate must satisfy the declared candidate ValueKind and the slice must lie within declared applicability. Once admissible, the governed condition named by the criterion settles true or false when known; missing support or an unavailable dependency yields unknown.
The rule about evidence is conditional, not lexical. An observation used merely to support a claim does not create an independently governed quality or relation. But a criterion may directly concern an episteme, an obtaining registration or certification relation, a publication occurrence, legal status, or another governed fact. In that case its direct pattern decides whether that very condition obtains; calling the same object evidence in another use does not erase its criterion role. This concept-level rule requires no particular ontology language, schema technology, rule engine, or programming type system.
Problem
The shorthand MemberOf(e,k,slice) is unsafe because readers can take it as an A.14 collection relation, an ontic occurrence, a classification result, a database lookup, or a guard. It also hides whether the request was applicable. C.3.2 restores a declaration, an admissibility result, a three-valued judgment only for admissible candidates, and an optional representation while leaving candidate identity and the criterion's governed conditions with their direct patterns.
Forces
Four Objects and One Applicability Result
ClassificationAdmissibility(candidate, kind, signatureEdition, slice) returns admissible or not-applicable. It is a precondition result, not another kind or membership value. not-applicable means the candidate fails the declared candidate ValueKind/interpretation or the slice falls outside signature applicability; no classification judgment is formed.
Scope is not attached to the kind. A KindSignature episteme may have its own U.ClaimScope; a separate classification assertion has the scope of that assertion; and U.ContextSlice remains an evaluation input.
KindSignature Declaration
Author a reusable KindSignature only when a named receiving use needs the criterion and assumptions to persist across more than one classification. Its claim content declares:
- the exact kind that is its
EntityOfConcern; - the candidate
ValueKindor exact value interpretation admitted as input; - the membership condition in terms of directly governed candidate qualities, relations, constructive grounding, epistemes, registrations, certifications, publications, legal statuses, or other exact conditions;
- the exact
U.ContextSliceapplicability in which the evaluation may be formed; - the effective
U.ReferenceScheme; - named assumptions, dependencies, standards, versions, units, and temporal policy;
- its
U.Formality; and - an optional
ExtentRulefor a named extension-consuming use.
In A.6.0 terms, SubjectKind is the broad candidate kind and RangedValueKind is {true, false, unknown}. not-applicable is returned before this ranged evaluation. ExtentRule is declaration content, not a new ontic relation. Formality characterizes the declaration episteme, not the kind, candidate, truth, or extension. A changed membership condition, candidate-domain declaration, EntityOfConcern, applicability, or effective scheme identifies another signature edition; C.3.1 separately decides kind continuity.
Admissibility and One Candidate Judgment
For exposition, this pattern uses:
A(candidate, kind, signatureEdition, slice) ∈ {admissible, not-applicable}
and, only when A = admissible:
J(candidate, kind, signatureEdition, slice) ∈ {true, false, unknown}
These are local result notations, not newly admitted kinds, A.14 membership occurrences, direct classification relations, or evidence relations. For a fixed candidate, kind, signature edition, and slice, unchanged governed conditions yield the same result; the slice resolves concrete versions and an explicit temporal selector rather than implicit latest or current.
- Recover the candidate first. An entity is already individuated under its direct pattern. A non-entity value keeps the identity, unit, scale, and interpretation supplied by its governor.
- Pin the inputs. Name candidate, kind, exact signature edition, and exact slice; avoid implicit
latestorcurrent. - Check admissibility. If the candidate does not satisfy the declared candidate
ValueKindor interpretation, or the slice is outside declared applicability, returnnot-applicableand stop. Do not formJ. - Evaluate the governed condition. For an admissible candidate, a satisfied criterion gives
true; a known failed criterion givesfalse. - Keep non-settlement visible. Missing support or an unavailable declared dependency gives
unknown, notfalse. - Distinguish condition from evidentiary use. A measurement result, source episteme, certification, registration, publication occurrence, legal-status relation, or record may itself be a criterion condition only when the signature says so and its direct pattern makes that condition obtain. Its mere use as evidence for some other condition creates neither that condition nor membership.
- Separate guard disposition. A guard checks admissibility, scope coverage, and any judgment as separate predicates. It may decline use on
not-applicableorunknownwithout converting either tofalse.
When a separate claim-bearing classification assertion is current, it is a C.2.1 episteme. Its content designates the candidate, kind, signature edition, slice, admissibility, any judgment, and relied-on support. Its exact EntityOfConcern is the governed entity about which classification matters; a value classification may stay in another claim's content rather than fabricating a value-shaped entity. The assertion creates neither candidate nor kind.
A domain that genuinely needs a durable classification-relation occurrence must supply a separate direct pattern with exact participants, obtaining condition, identity, and relation to these results. C.3.2 does not mint that occurrence.
Extension as Representation
Materialize KindExtension(k, slice) only when a named query, quantification, comparison, review, or publication needs the current true-candidate set.
- Pin the signature edition even though the compact name shows only
kandslice. - State the candidate domain without inventing
U.EntitySet. - Include exactly admissible candidates whose judgment is
true. Keepunknownandnot-applicabledistinct when the receiver needs those exclusions explained. - Treat braces, rows, indexes, or database results as representations. They create neither a collection holon, A.14 membership occurrence, direct classification relation, nor criterion condition.
- Use C.29 when the represented set changes a claim-bearing use; otherwise the extension may remain a local calculation.
Candidate state or a later slice can change an extension without changing the signature or kind. An extension row cannot repair an inconsistent declaration or subkind fact.
Subkind Comparison and Change
Whenever SubkindOfObtains(k1,k2) holds under C.3.1, its practical consequence is checked only where both candidate requests are admissible under the aligned declarations:
For the same candidate and slice, an admissible
truejudgment fork1must not coexist with an admissiblefalsejudgment fork2within the relation's declared applicability.
C.3.1 decides whether exact criterion entailment or exhaustive evaluation over a deliberately closed finite domain makes the relation obtain. Non-exhaustive classifications support its assertion or expose a counterexample; they do not establish an open-domain relation. A not-applicable request is outside the comparison. Cross-local use first compares kind identities: reuse the same kind directly when its membership distinction continues; only distinct kinds with an obtaining correspondence use C.3.3. A bridge never transfers source classification truth.
Keep these changes distinct:
Required Worked Cases
Physical pump
CoolingPumpSignature-2 admits physical pump candidates and applies in plant slice S-14. Pump #14 is independently identified as a physical pump, so the request is admissible. Governed flow, heat-transfer, and operating-state conditions satisfy the criterion; a calibrated measurement result supports that claim without becoming the pump or its performance. The result is true. A maintenance-query extension may represent Pump #14 but does not create its classification.
Episteme and publication form
Maintenance-instruction episteme MI-22 is admissible for DiagnosticInstructionKind and is evaluated through its claim-bearing content and governed subject. MI-22-PDF-Layout and MI-22-HTML-Layout are different publication forms for the chosen episteme edition; files that bear them are presentation carriers. Arrangement, form, carrier, or encoding alone changes neither the episteme, criterion satisfaction, kind, nor judgment.
Non-entity temperature value
Value 87 °C, with declared scale, unit, interpretation, and time, is admissible for HighTemperatureValueKind when the signature's ValueKind accepts that quantity. It can then be judged against the declared interval without fabricating a value-shaped entity.
Schema label
A row carries label Customer, but the claim asks whether account holder #441 is a contractual customer. If the kind admits account-holder Systems or persons rather than database rows, the row itself is not an admissible candidate. For the actual account holder, the label may support recovery of the governed contractual relation but does not make that relation obtain. A different row-shape kind could make the row admissible under its own criterion.
Unavailable measurement
Pump #14 remains an admissible physical candidate in later slice S-15, but a required flow-measurement dependency is unavailable. The judgment is unknown. A safety guard may decline reliance; it does not return false or remove the pump from a historical S-14 extension.
Not-applicable request
The value 87 °C is submitted to CoolingPumpSignature-2, whose candidate ValueKind is physical pump. The request is not-applicable; no cooling-pump judgment is formed. Lack of a pump judgment says nothing about whether the temperature value is known.
Registration-defined membership
RegisteredSupplierKind declares supplier candidates and requires an exact obtaining registration-status relation under the current register rule. Supplier #27 is admissible. If that governed relation obtains, it is part of the membership condition even though a registration episteme may also be used as evidence. A copied row or certificate image alone does not create the relation. This preserves legitimate institutional kinds without treating every record as a world-side fact.
Additional Transfer Cases
Work Boundary
Classification does not weaken the work ontology:
U.Workis the admitted kind;W : U.Workis one independently grounded dated 4D work occurrence under its direct pattern;- a plan, expected-work item, log, card, database row, assertion, or description about W is a separate episteme; and
- performer assignment, enacted method, temporal extent, containing system, affected referent, material binding, resource use, transformation, production, result, delivery, and acceptance remain separately governed.
A kind may classify an already identified W. A kind symbol, work label, plan, or record never occupies W's individual position, and record existence does not make planned Work actual.
Authoring Rhythm
- Start with one readable classification sentence and its practical use.
- Recover the exact candidate and the governed criterion conditions before discussing support.
- Reuse an existing signature edition only when it truly governs candidate ValueKind, criterion, applicability, scheme, and dependencies.
- Check admissibility. Stop with
not-applicablewhen candidate or slice lies outside the declaration. - For an admissible request, return
true,false, orunknownwithout folding in the guard decision. - Create an extension only for a named set-consuming use.
- If a separate assertion is required, give its C.2.1 episteme the exact EntityOfConcern, content, scope, support use, and edition.
Conformance Checklist
Common Anti-Patterns and Remedies
Consequences
Benefits. Classification becomes inspectable without ontology growth, evidence-created truth, or coercion among non-applicability, uncertainty, and falsity. Repeated criteria can be reused, and set-consuming uses can receive a bounded representation.
Costs. Reliance-bearing uses must pin a declaration and slice, check candidate/slice applicability, preserve unknown, and recover any criterion-bearing status or relation under its direct pattern.
Risks avoided. Kind/declaration collapse, locality-as-identity, record ontology, not-applicable-as-unknown, false-for-unknown, mathematical-set overread, silent subkind repair, and kind/individual substitution are blocked.
Rationale
The kind, its declaration, pre-judgment applicability, one admissible candidate judgment, and a representation of current true candidates answer different questions. Their separation prevents evidence, locality, time, scope, and notation from rewriting ontology while still allowing a criterion to concern a directly governed episteme, status, or relation when that is the actual classification condition.
SoTA-Echoing
Model theory and type systems distinguish intensional declarations, satisfaction judgments, and extensions; measurement and evidence disciplines distinguish the subject feature from its observation or support. C.3.2 combines those separations with FPF's episteme identity, context-slice, representation, and direct-object boundaries.
Relations
- Builds on:
C.3,C.3.1, A.6.0 declaration identity, C.2.1 episteme identity, A.2.6 context slices and claim scope, and direct patterns for candidate identity and features. - Coordinates with:
C.3.3correspondence between independently identified distinct kinds,C.3.4local adaptations,C.29mathematical representations, C.2.3 formality, F-G-R evidence and assurance, A.14 collection membership, andE.24.UKdurable U-kind admission. - Does not replace: the direct subject pattern, evidence-use relation, collection membership, claim-scope governor, guard decision, public-kind admission, or a separately justified durable classification-relation pattern.
C.3.2:End
KindBridge and CL^k — Cross-local Correspondence between Distinct Kinds
One-line summary. A changed practice, source, team, or scheme first triggers a comparison of kind definitions. If the same kind continues, reuse it and evaluate the receiving candidate afresh; no
KindBridgeis needed. When two independently identified kinds are distinct and a directional correspondence predicate holds, oneKindBridgedirect relation may obtain. A separate bridge-assertion episteme states direction, paired declaration editions, preservation or loss,CL^k, evidence, and admitted use. It never transfers source classification truth.
Status. Normative in Part C. Identifier C.3.3. Audience. Engineering managers, architects, assurance leads, editors.
Depends on.
- C.3.1 — U.Kind and U.SubkindOf: kind identity follows candidate domain and membership distinction; subkind facts form a preorder; locality and scheme editions are not identity keys.
- C.3.2 — Kind intent, admissibility, judgment, and extension: check
admissible | not-applicablebefore a freshtrue | false | unknownreceiving judgment. - A.2.6 — USM: Claim scope and selected context slices remain separate from kind identity and kind correspondence.
- C.2.2 — F–G–R: justified bridge penalties affect reliance R, not F or G.
- C.2.3 — U.Formality: formality belongs to the declaration or assertion episteme.
Non-goals. No repository or notation mandate. No Scope mapping here. No bridge from a locality change alone. No transfer of classification truth. CL^k reuses an ordinal congruence anchor for a declared kind-correspondence use without becoming a universal interoperability score.
Purpose and Audience
Typed reuse can fail because a claim's scope changed, because the receiving use employs another kind, or because wording changed meaning. These are separate questions. C.3.3 handles only a claimed directional correspondence between two distinct kind individuals. It lets a team state, for example, that source Vehicle corresponds to target TransportUnit, which distinctions are preserved or collapsed, and what loss a receiving use accepts.
Context
Different sources or practices may use the same kind, or different kinds may coexist inside one source. Names, source labels, compatible schemes, and matching current extensions decide neither. First compare the candidate domains and membership distinctions under C.3.1. Same-kind reuse needs no bridge. Distinct-kind reuse may need a KindBridge when its exact correspondence predicate can be established. F.9 is additional only when distinct local senses and their bounded use are current.
Problem
- False splitting. A locality change creates two apparent kinds and a bridge even though the membership distinction is unchanged.
- Semantic drift. A genuinely different receiving kind is treated as the source kind because names or extensions look alike.
- Hidden order loss. Subkind facts collapse, invert, or become unsettled without being reported.
- Entangled channels. Scope, sense, and kind correspondence are bundled into one score or record.
- Classification transfer. A source judgment is copied as receiving truth without checking receiving admissibility and criterion satisfaction.
- Unreplayable use. An unspecified mapping or implicit latest edition leaves a guard with no stable basis for deciding whether the bridge use is current.
Forces
Solution — Compare Identity, Then Relate Distinct Kinds
- Compare kind definitions. Recover source and receiving candidate domains, membership distinctions, and continuity rules. A changed locality or scheme prompts this check; it does not decide it.
- Stop on same-kind reuse. If the same kind continues, use the declaration edition selected for the receiving use, check admissibility, and evaluate the candidate afresh. No
KindBridgeobtains merely because source, practice, team, wording, or scheme changed. - Open a bridge only for two distinct kinds. A
KindBridgeoccurrence is an obtaining direct relation between one exact source kind and one exact target kind. Its directional predicate states the correspondence and definedness required by the named receiving use. The relation does not move, clone, construct, or identify either kind. - Keep the assertion separate. A C.2.1 bridge-assertion episteme designates the relation when needed and carries paired
KindSignatureeditions, mapping rule, selected order-preservation results,CL^k, loss notes, evidence, and admitted use. A card, row, F.9 relation, or publication does not make the bridge obtain. - Evaluate the receiving candidate. First return
admissibleornot-applicableunder the receiving signature and slice. Only an admissible request returnstrue,false, orunknown. A source judgment may support the bridge assertion or reliance but is never copied as receiving truth. - Route consequences narrowly. When a receiving claim relies on the obtaining bridge and fresh receiving result, apply only the justified
CL^kconsequence to R. Scope and any sense relation retain their own objects and rules; F and G do not change.
The kinds are the direct relation participants. Scheme and signature editions qualify interpretation, applicability, and the assertion. They do not identify the occurrence. For the ordered kind pair, the direct relation is participant-determined. An aligned scheme-edition change prompts reevaluation of whether the same relation still obtains; it does not mint another occurrence.
KindBridge is the direct relation kind governed here under A.6.REL. This spelling does not by itself admit a public dependent U-kind named U.KindBridge. If admission later matters, E.24.UK must close it separately.
Norms & Invariants (normative)
The following formalize the KB‑01…KB‑12 rules announced in C.3.
Direct Relation Subject and Scope
KB-01 (Distinct participants and obtaining). One KindBridge occurrence has exactly two ordered participants: an independently identified source kind and an independently identified distinct target kind. It obtains only when its directional correspondence predicate holds within declared definedness. A different locality, label, scheme, or extension supplies no bridge. Signatures, assertions, evidence, CL^k, loss notes, and slices are not participants.
KB-02 (No Scope or sense substitution). A KindBridge maps neither Claim/Work scope nor local wording. Scope translation uses A.2.6 when the receiving claim actually consumes it. An F.9 relation is added only for a current distinct-sense use. Neither channel is required merely because a kind bridge exists.
No blended score. Scope congruence, sense-relation loss, and kind congruence remain separate. Do not aggregate them into one interoperability score.
Settlement, Assertion, and Identity
KB-03 (Direct settlement). The C.3.3 settlement SHALL make recoverable:
- exact ordered source-kind and target-kind participants and the proof that they are distinct;
- the directional correspondence predicate, applicability, and definedness; and
- participant-determined occurrence identity for that ordered pair.
The separate bridge assertion states whether obtaining is affirmed, denied, or unresolved; only an affirmative assertion may designate an obtaining occurrence. It also names the declaration and scheme editions used to interpret the predicate, selected source and target subkind facts, preservation/collapse/non-preservation/unknown results, CL^k, loss, evidence, and admitted use. Another assertion, mapping expression, card, signature, scheme edition, or publication does not create another relation occurrence. A changed interpretation prompts a renewed obtaining test. If the same ordered participants and correspondence continue, the same relation continues; if not, the prior obtaining claim is no longer current.
KB-04 (Fresh receiving classification). With fixed receiving candidate, signature edition, and slice, check admissibility first. not-applicable forms no classification judgment. An admissible request is evaluated reproducibly as true, false, or unknown. A source judgment or bridge assertion may support reliance but is never copied into the receiving result. An unavailable bridge dependency blocks that bridge use without rewriting an independently evaluated receiving result.
Order & Monotonicity
KB-05 (Monotone order). If a bridge assertion states that source order fact SubkindOfObtains(k1, k2; sourceRS) is preserved, it SHALL designate exact target kinds k1' and k2', the respective obtaining KindBridge relations from k1 to k1' and from k2 to k2', and the basis on which SubkindOfObtains(k1', k2'; targetRS) holds. Identify a target R_sub : U.SubkindOf occurrence only when a receiving use needs occurrence identity.
KB-06 (No inversions). A bridge assertion MUST NOT state preservation when the mapped target order is inverted. If SubkindOfObtains(k2', k1'; targetRS) holds for distinct mapped kinds, state non-preservation and the exact loss. If the required target order cannot be settled, state unknown; do not turn non-settlement into either preservation or inversion.
KB-07 (Collapse semantics). A bridge assertion may classify selected source subkind distinctions as collapsed when several source kinds correspond to one target kind. The assertion SHALL designate the affected obtaining U.SubkindOf relations and state the lost properties; the direct bridge relation does not alter either local order.
Congruence & Assurance
KB-08 (Anchor reuse and AT neutrality). CL^k reuses the ordinal anchor semantics of CL but assesses the declared bridge use over kind intent and order. The bridge-assertion episteme labels it kind-congruence. Neither the obtaining KindBridge relation nor its assertion computes or alters KindAT; AT is editorial and independent of CL^k.
KB-09 (Effect on R only). After receiving admissibility has been checked and an admissible candidate has received a fresh target judgment, a claim that relies on both that result and an obtaining KindBridge may apply only the bridge assertion's justified monotone Ψ(CL^k) consequence to R, alongside any independently established scope-relation consequence. A not-applicable candidate forms no judgment; unknown stays unknown; F and G do not change.
KB‑10 (Chaining). For a chain of bridges, effective CL^k = min of the links (weakest‑link).
Loss Notes & Definedness
KB-11 (Loss notes). The bridge-assertion episteme SHALL state which KindSignature invariants are not preserved, which obtaining source U.SubkindOf relations are collapsed or not preserved, and any higher-equality caveats. These claims do not rewrite the source or target kinds.
KB-12 (Definedness and guard use). The bridge predicate and assertion SHALL state definedness. Outside it, a receiving guard declines that bridge use. Independently, receiving classification keeps not-applicable or its admissible true, false, or unknown result; bridge inapplicability rewrites none of them.
Interactions (informative)
With Scope and Sense Relations
A receiving use may need none, one, or several independent relations:
- an A.2.6 scope relation when the claim's admitted extent is translated or compared;
- a C.3.3
KindBridgewhen two distinct kinds are directionally related; and - an F.9 relation when distinct local senses are related for a bounded use.
Open only the channels the receiving claim consumes. Keep their definedness, losses, and R consequences separate.
With Receiving Classification
After same-kind reuse or an obtaining bridge, use the receiving KindSignature edition. Check candidate and slice admissibility. If admissible, evaluate the exact receiving judgment. If a mapping motivates another signature, author that declaration episteme separately. A source judgment can support a claim but never supplies receiving truth.
With Kind-use Adaptations
For same-kind reuse, select the receiving C.3.4 declaration and evaluate afresh without a bridge. For distinct-kind use, recover the obtaining KindBridge, bridge assertion, receiving adaptation declaration, and any exact adaptation-correspondence declaration needed for differing constraints or bindings. Source adaptation results are not receiving truth.
With Guards
A typed receiving guard first determines whether the same kind continues or a distinct-kind bridge is current. It then checks receiving admissibility and, when admissible, the fresh judgment. It independently checks any scope or sense relation the claim consumes and applies only justified consequences to R. not-applicable, unknown, absent bridge, and guard refusal remain different results.
Authoring, Review & Rating Guidance (informative)
Authoring a KindBridge assertion
- Compare identity before authoring a bridge. A changed locality, source, team, spelling, or scheme first replays C.3.1. Stop without a bridge when the same kind continues.
- Start narrow and honest. For two distinct kinds, declare only the directional correspondence and subkind facts the receiving use actually relies on; mark the rest unknown.
- Prefer independently identified target kinds. If the target already has a suitable kind and declaration edition, relate that kind directly. If a new target declaration is required, author it separately before asserting bridge obtaining; list what the mapping predicate preserves, relaxes, or drops.
- Write loss notes in plain language. Example: “EV vs ICE subkinds collapsed; battery‑health invariants dropped.”
- Fix the definedness area. Bind to target Standards/versions and any environment selectors essential to classification.
- Assign
CL^kfrom exemplars. Calibrate on concrete counter‑examples and preserved properties; resist optimistic ratings.
Review playbook (10 minutes)
- Identity checked first? Same kind reused without a bridge, or two distinct kinds and the obtaining correspondence shown? Add Scope or F.9 relations only when the receiving use consumes them.
- Order claims honest? Any
⊑inversions? Collapses disclosed? CL^kplausible? Based on preserved properties, not name similarity?- Loss notes present? Will they force narrowing of Scope or extra tests?
- Definedness area clear? Guard will fail closed outside it?
- Penalties wired to R? No hidden tweaks to F/G?
Rating CL^k (rules of thumb)
- High
CL^k: signature equivalence or up‑to‑iso;⊑fragment preserved; only cosmetic losses. - Medium
CL^k: some invariants relaxed or lost; selected subkinds collapsed; order preserved on critical path. - Low
CL^k: name‑only correspondences; properties diverge; order not preserved. Expect significant R penalty and/or adapters.
Worked Examples (informative)
Vehicle → TransportUnit (manufacturing)
Source kinds Vehicle and PassengerCar, target kinds TransportUnit and PassengerTransportUnit, and their exact declaration editions are independently identified. One KindBridge relation obtains from Vehicle to TransportUnit and another from PassengerCar to PassengerTransportUnit under the pinned scheme editions. The bridge assertion states that source fact SubkindOfObtains(PassengerCar, Vehicle; sourceRS) is preserved by target fact SubkindOfObtains(PassengerTransportUnit, TransportUnit; targetRS), while the EV distinction is collapsed; it records CL^k=2, the lost battery-health invariants, and definedness limited to registryAPI v1.4 in the selected time window. A candidate is first checked for admissibility and then classified by the exact receiving declaration; source classification is not copied. If the receiving claim also relies on an independently established scope translation, that relation's consequence remains separate from the kind-bridge consequence; F and G are unchanged.
Same AuthenticatedRequest kind across services — no bridge
Frontend and gateway services use the same AuthenticatedRequest kind: the candidate request domain, signature-validity condition, and intended member/non-member distinction are aligned. Each service uses its selected declaration edition and evaluates the request afresh. The gateway spelling x-auth may require an F.9 sense relation or a C.3.4 vocabulary binding when that wording use is relied on, but the service boundary and spelling alone create neither another kind nor a KindBridge.
AdultPatient across jurisdictions (clinical)
The obtaining bridge relates source kind AdultPatient to independently identified target kind AdultPerson_Y. Its assertion gives CL^k=1, states the 18-versus-21 boundary loss, and limits definedness to the declared jurisdictional editions. The target classification uses its own signature edition. Missing DOB support yields unknown; a mask adapter or narrower Scope may support a later use, while the guard's refusal and R penalty remain separate from target truth.
Anti‑patterns & Remedies (informative)
Conformance Checklist
Integration requirements with Part B. Part B distinguishes the C.3.3 kind-correspondence channel from scope and F.9 sense channels, routes justified CL^k consequences to R, and retains weakest-link chaining. Templates designate exact relied-on relations and assertions; their fields create none of them.
C.3.3:End
KindUseAdaptationDeclaration — Contextual Adaptation of Kinds without Cloning
One-line summary. Use a
KindUseAdaptationDeclarationwhen a procedure needs a narrower or differently named use of an existing kind without defining another kind. The declaration pins the baseKindSignatureedition, local candidate constraints or vocabulary bindings, intended guard use, and applicability. Check admissibility before returningtrue,false, orunknown. A locality change first triggers kind-identity comparison: the same kind needs noKindBridge; distinct kinds need one only when its exact correspondence predicate obtains.
Status. Normative in Part C. Identifier C.3.4. Audience. Engineering managers, architects, reviewers, and editors.
Use This When
Use C.3.4 when a procedure needs a named local way of using an existing kind without claiming another kind. Typical cases include accepting Vehicle candidates only when they have ABS, using local spelling X-Auth for AuthHeader, or combining a candidate constraint with vocabulary bindings.
First identify the base kind, exact KindSignature edition, receiving use, and meanings of local names or predicates. Write one declaration for candidate constraints or vocabulary bindings and route claim-scope conditions separately. Check candidate and slice admissibility, then evaluate one candidate. Stop with the declaration and first reproducible result. If the distinction becomes a stable kind, identify it separately and establish any obtaining U.SubkindOf fact under C.3.1.
Do not use C.3.4 merely to rename a kind, represent a catalog row, narrow claim scope, or avoid deciding whether another kind is needed. A vocabulary-only change adds no candidate predicate. not-applicable, unknown, and a guard refusal are different results.
Depends on.
- C.3.1 — U.Kind and U.SubkindOf: kind identity follows the membership distinction;
U.SubkindOffacts form a preorder and kinds carry no Scope. - C.3.2 — Kind intent, admissibility, judgment, and extension:
KindSignatureis a declaration episteme; admissibility precedes the three-valued judgment. - C.3.3 — KindBridge and CL^k: a directional correspondence only between independently identified distinct kinds, plus R-only bridge consequences.
- A.2.6 — Context slices and Scopes: Claim and Work scope over
U.ContextSlice. - C.2.2 and C.2.3: F–G–R and formality characterize the episteme being assessed.
Non-goals. This pattern mandates no repository or notation. A kind-use adaptation declaration is not a governance tier, data policy, mini-type system, kind, KindBridge, or Scope.
Purpose
Teams often need a local projection of a widely used kind: Vehicle with ABS for one procedure, or local spelling X-Auth for AuthHeader. Cloning a kind for every use fragments catalogs and creates false bridge pressure. A local-use declaration keeps the base-kind identity, makes constraints and bindings explicit, and gives a guard one versioned episteme to designate. It is not another kind, classification occurrence, or record ontology.
Context
C.3.1 and C.3.2 say what claims classify; A.2.6 says where claims hold. A procedure may still tailor use for a compliance procedure, product line, or cohort without changing the kind.
Three objects remain distinct:
KindUseAdaptationDeclarationstates one named use of a base kind.KindUseAdaptationJudgmentis the three-valued result for one admissible candidate under pinned declaration and signature editions.KindUseAdaptationCorrespondenceDeclarationrecords how one exact source declaration corresponds to one exact target declaration when their constraints or vocabulary bindings differ.
The third object is a C.2.1 declaration episteme. Its effective scheme makes source, target, and rule designations interpretable. It is not an executable adapter, mapping Method, representation correspondence, obtaining F.9 relation, KindBridge, or target judgment.
Problem
- Kind sprawl. Teams mint near-duplicates for every procedure.
- Hidden constraints. Informal acceptance rules leak into prose and cannot be replayed.
- Scope conflation. Jurisdiction, API version, or another scope condition is smuggled into kind identity.
- Automatic bridge pressure. A changed source or team is treated as proof of another kind and a bridge.
- Collapsed outcomes. A non-applicable candidate, unsettled admissible candidate, and guard refusal are reported as one
unknownorfalseresult.
Forces
Solution — Declaration, Correspondence, and Judgment
A KindUseAdaptationDeclaration is a named, versioned C.2.1 declaration episteme about one local use. The base kind is its EntityOfConcern; its effective scheme gives meaning to declaration names and predicates. Its claim content states:
- the exact base kind and pinned base
KindSignatureedition; - the receiving use and adaptation type: constraint, vocabulary, or composite;
- additional directly governed candidate conditions, when any;
- vocabulary or notation bindings;
- exact candidate and slice applicability plus dependencies;
- scope expectations routed separately through A.2.6; and
- intended guard use and this declaration episteme's formality, when current.
First evaluate adaptation admissibility. A candidate rejected by the base signature's ValueKind, an adaptation-specific candidate requirement needed merely to form the question, or the declared slice applicability is not-applicable; no adaptation judgment is formed. For an admissible request, use:
J_kindUse(candidate, kind, kindSignatureEdition, adaptationDeclarationEdition, slice) ∈ {true, false, unknown}
The judgment conjoins the base C.3.2 judgment with every added candidate-condition predicate. A known false gives false; all known true gives true; unresolved required facts give unknown. A vocabulary-only declaration adds no predicate and preserves the base judgment. A guard may decline use on not-applicable or unknown without rewriting either.
An optional pinned-edition representation may list admissible candidates judged true. It is not U.EntitySet, A.14 membership, another kind, or a direct classification relation. Scope conditions stay under A.2.6 rather than becoming kind identity.
When a use moves to another practice, source, or team, compare the base-kind membership distinctions first:
- if the same kind continues, use the declaration and signature edition selected for the receiving use and make a fresh receiving judgment; no
KindBridgeexists merely because locality changed; - if independently identified kinds are distinct and the use claims a directional correspondence, establish the C.3.3
KindBridge; use the receiving signature and adaptation declaration and make a fresh receiving judgment; and - if two adaptation declarations differ in constraints or bindings, a separate
KindUseAdaptationCorrespondenceDeclarationmay name source declaration as EntityOfConcern and state target, direction, deterministic rule, definedness, loss, and effective scheme. It creates no bridge or target truth.
A stable conceptual refinement may justify another kind and an obtaining C.3.1 subkind fact. A declaration, correspondence, judgment, catalog row, or representation creates neither.
Norms and Invariants
Definition and Shape
KUA-01 (Definition). A KindUseAdaptationDeclaration SHALL be a named, versioned C.2.1 declaration episteme with exact base kind as EntityOfConcern, effective scheme, pinned base signature, receiving use, adaptation type, candidate constraints, vocabulary bindings, applicability, dependencies, intended guard use, and separate scope expectations. Its formality characterizes the episteme.
KUA-02 (Not a new kind). A declaration MUST NOT introduce a kind or subkind fact. Stable refinement requires an independently recovered kind and C.3.1 obtaining test.
KUA-03 (Admissibility before judgment). Fixed candidate, kind, base-signature edition, adaptation-declaration edition, and slice first yield admissible or not-applicable. Only an admissible request yields true, false, or unknown; implicit latest and guard-result coercion are forbidden.
KUA-04 (Adaptation type). A vocabulary declaration preserves the base judgment. Constraint and composite declarations use governed candidate conditions: any known false gives false, all known true gives true, and unresolved required facts give unknown.
Separation of Channels
KUA-05 (Scope versus candidate). Conditions of the candidate may enter the adaptation judgment. Claim- or Work-scope conditions remain under A.2.6. A declaration may cite both, but a guard routes them separately.
KUA-06 (Guard use). A guard MAY designate a declaration only when its exact edition, base signature, dependencies, applicability, and candidate conditions are recoverable. It checks admissibility before the judgment and makes its use decision separately.
Stable Refinement and Catalog Representation
KUA-07 (Stable refinement). Broad reuse triggers a review for another kind. If that kind and an obtaining subkind fact are established, retain the adaptation declaration only for any remaining local use or retire it. Declaration reuse, catalog action, or labeling performs no kind admission and establishes no subkind fact.
KUA-08 (Addressability). Every guard-addressable adaptation declaration resolves to its exact edition, base signature, dependencies, applicability, and intended use. A correspondence declaration also resolves its source declaration as EntityOfConcern, target declaration, direction, deterministic rule, effective scheme, definedness, and loss. A catalog represents those references; it is neither the declaration episteme nor ontology, and consolidation does not merge kind identities.
Cross-local Use
KUA-09 (Identity check before bridge). A locality change first compares exact base-kind definitions. Same-kind reuse needs no KindBridge but still uses the receiving declaration and a fresh judgment. Distinct-kind use establishes a KindBridge only when its directional correspondence predicate obtains. Differing adaptation constraints or bindings may additionally require an exact correspondence declaration. Source judgments are never copied as receiving truth; justified bridge consequences affect R only.
KUA-10 (Definedness and fail-closed use). Outside adaptation applicability, return not-applicable and form no judgment. For an admissible request with an unavailable dependency, return unknown. Outside correspondence definedness, the guard declines that cross-local use without rewriting an independently evaluated receiving result.
Invariants and Non-goals
- No Scope leakage. An adaptation declaration cannot widen or narrow Claim scope G; context conditions are enforced by A.2.6 guards.
- Identity preservation. The base kind remains
k; the declaration does not change itsEntityOfConcern. - Weakest-link unaffected. Adaptation and correspondence declarations do not alter weakest-link rules on F or R; guards route candidate-feature predicates to the exact judgment and context predicates to Scope.
Interactions
With Kinds and Subkinds
Use an adaptation declaration for procedural tailoring. If the criterion becomes conceptual and stable, identify another local kind and establish the exact obtaining U.SubkindOf relation. Repeated declaration use, promotion language, and a catalog link do not establish that relation.
With Judgment and Declarations
- The base
KindSignatureepisteme supplies the kind criterion and its own F. - The separate adaptation declaration supplies additional candidate-feature constraints or vocabulary bindings and may have its own F.
- The exact
KindUseAdaptationJudgmentpins both editions and preservesunknown; neither formality value belongs to the kind, candidate, or truth value. - An optional extension-like result remains only a pinned-edition representation of true adaptation judgments.
With KindBridge
A locality change first prompts kind-identity comparison. When the same base kind continues, select the receiving signature and adaptation declaration and evaluate a fresh candidate result without a KindBridge. When two independently identified kinds are distinct and an exact directional correspondence is relied on, establish the C.3.3 KindBridge, its assertion, the receiving declaration, and any needed adaptation-correspondence declaration. Only justified bridge penalties affect R; F, G, admissibility, and classification truth remain unchanged.
With Guards
Guard_KindUseAdaptation designates exact adaptation and base-signature editions, checks admissibility, evaluates an admissible candidate, checks Scope separately, and keeps not-applicable, unknown, and refusal distinct. For distinct-kind cross-local use, it composes with the C.3.3 guard only after the bridge and receiving declarations are recoverable. For same-kind reuse, it performs the fresh receiving evaluation without inventing a bridge.
Anti-patterns and Repairs
Worked Examples
Vehicle@ABSOnly Constraint Use
VehicleABSUse-2026 designates Vehicle, pins its signature, and adds the governed candidate condition that the vehicle has ABS. A physical vehicle in the declared slice is admissible; missing ABS support yields unknown, while a non-vehicle input is not-applicable. Surface, rig, and time conditions used only to bound the claim remain Scope. If ABS becomes a stable classification distinction, recover another kind and test its subkind relation separately.
AuthenticatedRequest@Frontend Vocabulary Use
FrontendAuthHeaderUse-2026 binds authHeader to local spelling X-Auth and adds no candidate condition. Its judgment therefore equals the admissible base judgment. Moving the same exact request kind to another team requires a fresh receiving evaluation but no KindBridge merely because the team or spelling changed. If two independently identified request kinds differ, establish any bridge separately.
AdultPatient@Clinic Composite Use
ClinicAdultPatientUse-2026 pins the base adult-patient signature and adds the candidate condition ageAt(patient, slice) >= 21; the chosen clinic and claim window remain separately governed scope/applicability values. A person in the declared candidate domain is admissible; unavailable birth support yields unknown.
In Jurisdiction Y, first compare the exact patient-kind membership distinctions. If the same kind continues, use the Y declaration and evaluate afresh without a bridge. If the threshold or interpretation makes a distinct target kind and a directional correspondence is relied on, establish the KindBridge. A separate adaptation-correspondence declaration may then state how the two exact use declarations differ. Neither object transfers source truth.
Authoring and Review Guidance
An adaptation card may show its declaration designator, base kind, effective scheme, pinned base-signature and declaration editions, adaptation type, intended use, candidate constraints, bindings, separately routed Scope, applicability, examples, known bridge or correspondence declarations, and a stable-distinction review note when current. A correspondence card shows its source declaration as EntityOfConcern and names target, direction, rule, definedness, loss, and effective scheme. A card represents the declaration; it is not the declaration or another kind.
Rules of thumb:
- Keep candidate conditions small and governed.
- Check ValueKind and applicability before the three-valued judgment.
- Put claim-scope conditions in Scope, not kind identity.
- Treat locality as a comparison cue. Require a bridge only for distinct kinds with an obtaining correspondence.
- If several teams reuse one stable conceptual constraint, review whether another kind is warranted; reuse alone establishes none.
Reviewer questions:
- Are the exact base kind and declaration editions recoverable?
- Is the type—constraint, vocabulary, or composite—correct?
- Are candidate conditions, applicability, and ClaimScope separated?
- Does evaluation distinguish
not-applicable,true,false,unknown, and guard refusal? - On locality change, was kind identity compared before any bridge was claimed?
- For distinct-kind use, do the bridge predicate, receiving declaration, fresh judgment, any adaptation correspondence, and only justified R consequence remain separate?
- Does a stable conceptual distinction warrant another kind, or is the declaration sufficient?
Conformance Checklist
C.3.4:End
KindAT — Intentional Abstraction Facet for Kinds (K0…K3)
One-line summary.
KindATis an informative editorial facet on one localU.Kind. Its anchors—K0 Instance, K1 Behavioral Pattern, K2 Formal Kind/Class, and K3 Up-to-Iso—help plan declaration rigor, assurance coverage, bridge expectations, catalog search, and refactoring. KindAT is not a Characteristic: it has no algebra or threshold and never appears in guards or composition. It changes neither the kind, aKindSignature, a classification judgment, an extension representation, nor F–G–R.
Status. Informative for anchors, heuristics, examples, and guidance; normative only for the usage rules that prohibit guard/composition use and constrain placement.
Placement. Part C (Kinds), identifier C.3.5. Audience: engineering managers, architects, editors, and assurance leads.
Depends on.
- C.3/C.3.1: the context-local
U.Kind, obtainingU.SubkindOfrelations, and kind continuity. - C.3.2: the separate
KindSignaturedeclaration episteme, exact four-input classification judgment, and optional pinned-edition extension representation. - C.3.3: the obtaining
KindBridgerelation and its separate bridge-assertion episteme carryingCL^k, loss, evidence, and admitted use. - C.3.4: the
RoleMaskdeclaration episteme and exact masked judgment. - A.2.6, C.2.2, and C.2.3: Claim/Work scope, F–G–R, and
U.Formalityon the episteme that owns it. - MM-CHR: the Facet-versus-Characteristic distinction.
Non-goals. KindAT supplies no numerical scale, gating rule, composition operator, public-kind admission, classification result, or assurance score.
Purpose
Teams need a quick answer to a planning question: is this local kind intended as a curated instance-like cohort, a behavioral pattern, a formal invariant-bearing kind, or a kind considered up to structural equivalence? The answer can guide where declaration rigor and assurance effort are likely to pay off without pretending that abstraction itself widens scope, raises formality, settles classification, or increases reliability.
KindAT gives that planning vocabulary while keeping the governing objects separate:
- the local kind and its order remain under C.3/C.3.1;
- the
KindSignatureremains a declaration episteme whose ownU.Formalitymay change; J(candidate, kind, signatureEdition, slice)remainstrue,false, orunknown;- any
KindExtensionremains a pinned-edition representation of true candidates; and - bridge and mask objects retain the ontology assigned by C.3.3 and C.3.4.
Orthogonality and rationale
- G says where a claim or Work use applies.
- a local kind says what the declaration and claim are about.
- a KindSignature declaration episteme states the reusable criterion and has its own F when current.
- R says how well a receiving claim or use is supported.
- KindAT is only a catalog and planning tag on the local kind.
Calling KindAT a Characteristic would invite a second scope axis, an abstraction score, or a hidden classification gate. Keeping it as a facet lets editors search and plan without adding another truth-bearing or assurance-bearing object.
Anchors K0…K3 (informative)
K0 — Instance-level
Intent. The local kind is used for named exemplars or a tightly curated cohort.
Cues. The reusable criterion, when one is needed, relies mainly on direct identity features or an enumerated bounded candidate domain.
Non-example. A stable invariant-bearing distinction belongs nearer K2 even if few candidates are currently known.
Planning. Prefer exact slice-bound judgments and assurance over the current candidate domain. Cross-context reuse is likely to need explicit instance correspondence and may have low CL^k.
K1 — Behavioral pattern
Intent. The local kind is recognized through repeatable behavior or role-like performance rather than a mature formal invariant set.
Cues. A KindSignature may use controlled prose, behavioral obligations, or executable acceptance predicates.
Non-example. A kind with stable explicit predicates and order relations belongs nearer K2.
Planning. Invest in making the signature criterion evaluable and in testing behavioral diversity. Bridges are usually pattern correspondences whose assertions must state loss.
K2 — Formal kind/class
Intent. The local kind has explicit invariants, relations, and a reviewed position in a local kind order.
Cues. A reusable KindSignature declaration episteme pins predicate-like criteria, dependencies, and reference scheme; judgments are replayable under exact editions.
Non-example. An informal cohort or role cue does not become K2 merely because it is stored in a schema.
Planning. Consider raising the declaration episteme's F where the receiving use warrants it; plan R across relevant subkinds and boundary cases. KindBridge assertions may support medium or high CL^k only from demonstrated signature/order preservation.
K3 — Up-to-Iso
Intent. The kind's governed criterion is invariant under a declared isomorphism or equivalence notion.
Cues. Structural equivalence, rather than individual identity, is load-bearing in the signature and receiving use.
Non-example. A class whose candidate identity matters beyond the declared structure is not K3.
Planning. Require explicit equivalence witnesses and receiver acceptance. High CL^k is justified only when the obtaining bridge and its assertion demonstrate preservation of the relevant equivalence structure.
Manager heuristics (informative)
These are planning cues, not default F values, R values, classification results, or CL^k assessments.
Misuse and antidotes (informative)
- “Higher KindAT means wider G.” Wrong: only the scope governor changes G.
- “Gate on KindAT.” Wrong: use the exact classification, scope, evidence, and policy predicates required by the receiving guard.
- “Depth in
U.SubkindOfdetermines KindAT.” Wrong: the facet concerns intentional stance, not graph depth. - “KindAT belongs on the claim or signature.” Wrong: the tag is on the local kind; a catalog may represent that assignment.
- “A reused RoleMask has been promoted automatically.” Wrong: if the distinction is conceptual and stable, separately identify a local kind and establish any obtaining
U.SubkindOfrelation under C.3.1. - “KindAT rates quality.” Wrong: formality belongs to the relevant episteme and assurance belongs to the receiving support path.
Usage rules (normative)
AT-01 (Facet, not Characteristic). KindAT SHALL be treated as a Facet per MM-CHR. It has no algebra or threshold and MUST NOT appear in guard predicates or composition math.
AT-02 (Placement). If recorded, KindAT SHALL characterize one exact local U.Kind under an effective reference scheme. A catalog row may represent that assignment. KindAT MUST NOT be attached to a claim, capability, KindSignature episteme, candidate, judgment, or extension as a substitute for its own governor.
AT-03 (No F–G–R effect). Editors SHALL NOT imply that a higher KindAT widens G, raises the signature episteme's F, increases R, or changes a classification value. Any such sentence MUST name the actual declaration, scope, evidence, or receiving-use change.
AT-04 (Bridge neutrality). Neither an obtaining KindBridge relation nor its bridge-assertion episteme computes or alters KindAT. The assertion may record an informative anchor comparison, but CL^k remains a separate assessment of the admitted bridge use from demonstrated signature/order preservation and loss.
AT-05 (Catalog representation). When a context uses KindAT, its catalog SHOULD identify the local kind and effective reference scheme and reference, rather than collapse, the current KindSignature edition, obtaining subkind relations, RoleMask declaration editions, KindBridge occurrences/assertions, and optional extension representations. Absence of a tag means “not set”, not K0.
Authoring and review guidance (informative)
Fast rubric
- Concrete exemplars or a bounded cohort suggest K0.
- Behavioral obligations with few stable global invariants suggest K1.
- Explicit invariant-bearing criteria and a reviewed local order suggest K2.
- An explicit, load-bearing equivalence notion suggests K3.
Review questions
- Is the tagged object the exact local kind rather than its signature, card, candidate, claim, or extension?
- Does the anchor describe the kind's intentional stance rather than the current number of candidates?
- Are proposed F and R changes stated as planning decisions over their actual owners rather than effects of KindAT?
- Does a stable mask distinction require a separately identified kind and independently obtaining subkind relation?
- Does cross-context use recover the exact KindBridge occurrence and separate bridge assertion instead of inferring congruence from the tag?
Integration notes (informative)
- C.3.1/C.3.2. KindAT may guide work on the signature declaration and assurance plan; it changes neither kind continuity nor the four-input judgment.
- C.3.3. KindAT may suggest what preservation evidence to seek. The bridge assertion, not the tag, carries
CL^k, loss, evidence, and admitted use. - C.3.4. Repeated mask use is a review cue only. A new local kind and any
U.SubkindOfrelation are established independently. - A.2.6. Scope remains G on the claim or Work use. KindAT never supplies coverage.
- C.2.3. The relevant declaration or claim episteme owns F. KindAT can motivate investment but cannot assign the value.
Worked mini-examples (informative)
- K0.
Account_US_GAAP_2025_Q1_Cohort: use exact candidate judgments in the pinned quarter slice; do not infer a broad kind from one query result. - K1.
CacheableRequest: make retry/idempotence behavior evaluable in a named signature edition and test diverse failure modes. - K2.
Account: use explicit posting and balance invariants, test relevant subkinds, and evaluate each candidate with the exact signature edition and slice. - K3.
UndirectedGraphup to node relabeling: state the equivalence notion and require bridge/evidence witnesses that preserve it.
Conformance checklist (normative)
C.3.5:End
Typed Guard Macros for Kinds + USM (Annex)
One-line summary. These guard macros combine C.3 declaration compatibility, the exact C.3.2 candidate judgment when an actual candidate is current, RoleMask and KindBridge declarations/relations, and A.2.6 Scope without collapsing them. A claim quantified over a kind can be checked at declaration level; applying that claim or a capability to one candidate additionally requires
J(candidate, kind, signatureEdition, slice).true,false, andunknownremain classification values, while allow/refuse remains a separate guard disposition. KindAT never appears in a guard.
Status. Normative for macro obligations, evaluation order, three-valued/fail-closed discipline, and the conformance checklist; informative for decision trees, examples, and implementation-like skeletons.
Placement. Part C (Kinds), identifier C.3.A. Audience: engineering managers, editors, reviewers, assurance leads, and authors of regulatory, evidence, ESG, and Method–Work checks.
Depends on.
- A.2.6 USM: exact
U.ContextSlice, Claim/Work scope,Gamma_time, scope bridges, and SpanUnion. - C.3/C.3.1: exact local kinds and obtaining
U.SubkindOfrelations. - C.3.2:
KindSignaturedeclaration epistemes,J(candidate, kind, signatureEdition, slice),true/false/unknown, and optional extension representations. - C.3.3: obtaining
KindBridgerelations and separate bridge-assertion epistemes carryingCL^k, loss, evidence, definedness, and admitted use. - C.3.4:
RoleMaskandMaskAdapterdeclaration epistemes andJ_mask(candidate, kind, kindSignatureEdition, roleMaskEdition, slice). - C.3.5: KindAT as an editorial facet forbidden in guards.
- C.2.2/C.2.3 and Part B: F–G–R, formality on the owning episteme, bridge consequences, and scope congruence.
- A.15/A.15.1: the separation of capability, plan, exact actual Work occurrence, and every episteme about it.
Purpose and audience
Use this Annex when a receiving action must check one or more of these without blending them:
- the declaration-level compatibility of a claim's quantified kind with a consumer's expected kind;
- the classification of one exact candidate under one exact signature edition and slice;
- Claim or Work scope coverage;
- cross-context kind and scope bridges and their R consequences;
- a RoleMask declaration and exact masked judgment; or
- an actual capability use or Work occurrence whose input/output candidates are typed.
The practical gain is a readable refusal reason. “The kinds are incompatible”, “the candidate is known not to satisfy the criterion”, “classification is unknown”, “scope does not cover”, “a bridge is unavailable”, and “the guard refuses use” remain different outcomes.
Problem
Older guard shorthand used one two-valued “membership defined” question for several different jobs. That erased the exact candidate and signature edition, collapsed unavailable support into known failure, made a refusal look like a classification result, and allowed a record or bridge assertion to manufacture target truth. Method–Work use added another collapse when a JobSlice, capability row, plan, or log was read as the performed Work occurrence.
C.3.A restores two levels:
- declaration level: which exact local kind and
KindSignatureedition a claim quantifies over, and whether that kind is compatible with the receiver's expected kind under same-context order or an obtaining KindBridge; and - candidate-use level: whether one exact target-side candidate satisfies the receiver's exact declaration in that exact slice, with the claim-kind consequence supplied only by the already established same-context order or cross-context bridge.
Shared outcome model
All guards obey these invariants.
- Exact declarations. A kind designator never substitutes for the exact
KindSignatureedition needed by the use. - Candidate only when current. A universally quantified claim or proof can be checked for declaration compatibility without inventing a wildcard candidate. Actual application, test attachment, capability input/output use, or other candidate-bearing action pins the candidate and evaluates the four-input judgment.
- Three classification values.
truemeans the criterion is known to hold;falsemeans it is known to fail;unknownmeans the evaluation cannot settle because evidence or a declared dependency is unavailable or the candidate is outside the evaluation domain. - Separate guard disposition. A guard returns an action disposition such as allow or refuse. Both
falseandunknownnormally cause fail-closed refusal, but the guard MUST preserve which classification value it consumed. - Scope separation. Scope coverage is a USM predicate over a named slice. It does not classify the candidate or repair kind compatibility.
- Bridge separation. An obtaining KindBridge relation connects exact source and target kinds. Its separate bridge assertion supplies mapping,
CL^k, loss, evidence, definedness, and admitted use; neither object creates a target kind, signature, or judgment. - R-only consequences. Justified scope- and kind-bridge consequences affect R only. They do not change F, G, or classification truth.
Normative guard macros
Names such as Guard_TypedClaim are editorial handles. A context may alias them only when the same objects, values, and refusal distinctions remain recoverable.
Guard_TypedClaim — declaration-level admission
Intent. Decide whether claim C, quantified over local kind k_claim, may enter a receiving use restricted to kind k_receive in TargetSlice, without claiming anything yet about an unnamed candidate.
Guard_TypedClaim(C, k_claim, claimSignatureEdition, k_receive, receiveSignatureEdition, TargetSlice, thresholds?) SHALL:
- recover the exact
KindSignaturedeclaration episteme editions whose respectiveEntityOfConcernvalues arek_claimandk_receive, and whose evaluation domains and effective reference schemes cover the declared use; when both roles use the same kind and edition, state that identity rather than duplicating the declaration; - establish declaration-level kind compatibility:
- in one context, the kinds are identical or
SubkindOfObtains(k_receive, k_claim; effectiveReferenceScheme)holds under C.3.1, with an identifiedR_sub : U.SubkindOfoccurrence only when occurrence identity is needed; or - across contexts, an obtaining KindBridge relates exact source
k_claimand targetk_receiveunder the paired source and targetKindSignatureeditions, and a separate current bridge assertion states the mapping, applicability, loss,CL^k, evidence, and admitted receiving use;
- in one context, the kinds are identical or
- require
U.ClaimScope(C)to cover the exactTargetSliceand require an explicitGamma_timeselector; - apply only the justified bridge consequences to R;
- check evidence freshness separately when the admission implies reliance; and
- check a policy-required formality threshold on the exact claim or declaration episteme that owns the value.
The same-context direction above is contravariant only for restricting a universally quantified claim: a claim over Vehicle may enter a PassengerCar-restricted use when PassengerCar is a subkind of Vehicle. It is not a generic compatibility direction for producer outputs, operation arguments, mutable positions, or arbitrary typed slots; each such use states its own variance rule. This guard MUST NOT invent an anonymous candidate or infer a candidate classification from declaration compatibility.
Guard_CandidateUse — apply a typed claim to an exact candidate
Intent. Decide whether claim C, quantified over k_claim, may be used for exact target-side candidate candidate in a receiving use restricted to k_receive.
Guard_CandidateUse(C, candidate, k_claim, claimSignatureEdition, k_receive, receiveSignatureEdition, TargetSlice) SHALL:
- identify the candidate under its direct governor before classification;
- satisfy
Guard_TypedClaimfor the same claim-kind and receiving-kind editions and slice; - evaluate
J(candidate, k_receive, receiveSignatureEdition, TargetSlice); - continue candidate-bearing use only on
true: for a same-context proper subkind, the already establishedSubkindOfObtains(k_receive, k_claim; RS)supplies the monotone claim-kind consequence; for a cross-context use, rely only through the obtaining KindBridge and its current assertion, without inventing a source-context candidate judgment; - refuse on known
falsewhile retaining that value; and - refuse on
unknownwhile retaining the missing dependency, unavailable support, or out-of-domain reason.
Evidence may support a classification assertion, but record presence, bridge presence, or guard invocation MUST NOT make the candidate satisfy the receiving criterion. When k_claim and k_receive are identical under one declaration edition, record that identity and evaluate the candidate once.
Guard_TypedJoin — compose typed producers and consumers
Intent. Compose producer A, which declares output kind k_A, with consumer B, which expects input kind k_B.
Guard_TypedJoin(A, k_A, edition_A; B, k_B, edition_B; TargetSlice) SHALL:
- pin both declaration episteme editions;
- establish output-to-input compatibility in the covariant flow direction:
- in one context, the kinds are identical or
SubkindOfObtains(k_A, k_B; effectiveReferenceScheme)holds; or - across contexts, an obtaining KindBridge maps
k_Ato exact target-side kindk_A', its separate assertion carries the current mapping and loss basis, andk_A'is identical tok_BorSubkindOfObtains(k_A', k_B; targetReferenceScheme)holds;
- in one context, the kinds are identical or
- compute serial scope as the intersection of the two governed scopes and require coverage of
TargetSlice; - route bridge consequences to R and check freshness separately; and
- when an actual produced candidate enters B, evaluate
J(candidate, k_B, edition_B, TargetSlice)and continue only ontrue, preservingfalseandunknownseparately from refusal.
Declaration compatibility alone MUST NOT classify a future or actual output. Scope widening MUST NOT repair a type mismatch. The universal-claim variance rule in Guard_TypedClaim does not reverse this producer-to-consumer direction.
Guard_MaskedUse — exact RoleMask use
Intent. Use exact candidate candidate under a named RoleMask declaration in TargetSlice.
Guard_MaskedUse(artifact, candidate, kind, kindSignatureEdition, roleMaskEdition, TargetSlice) SHALL:
- recover the exact C.2.1 RoleMask declaration episteme, its base kind, pinned base signature edition, intended use, candidate-feature constraints, bindings, dependencies, and definedness;
- check artifact scope separately through USM;
- evaluate
J_mask(candidate, kind, kindSignatureEdition, roleMaskEdition, TargetSlice); - continue only on
true, refuse while preserving knownfalse, and fail closed while preservingunknown; - keep context predicates out of the candidate-feature criterion; and
- for cross-context use, establish the KindBridge relation and assertion, target declarations, and any separate
MaskAdapterdeclaration episteme before evaluating the target masked judgment.
A mask name is not a kind synonym. Repeated mask use can trigger review for a separately identified local kind and independently obtaining U.SubkindOf relation; no guard or catalog action performs that admission.
GuardSpanUnionTyped — parallel support lines
Intent. Publish SpanUnion for the same typed claim supported by independent lines.
For each line, the guard SHALL:
- recover the same governed claim, quantified kind, and signature edition;
- satisfy declaration-level typed admission in that line's slice;
- when a line's evidence is candidate-specific, bind each exact candidate and its exact judgment rather than treating a row label as classification;
- preserve line-specific bridge consequences and freshness;
- provide the USM independence justification; and
- include no slice outside the union of covered line scopes.
If lines quantify over genuinely different kinds, normalize through separately justified kind relations or publish distinct claims; do not hide the difference in SpanUnion.
GuardXContextTyped — cross-context typed reuse
Intent. Reuse claim C from a source context in target TargetSlice while keeping scope translation, kind correspondence, and target classification separate.
Guard_XContext_Typed(C, sourceKind, sourceSignatureEdition, targetKind, targetSignatureEdition, TargetSlice, candidate?) SHALL:
- recover an obtaining Scope Bridge and its applicable congruence assessment when Claim scope crosses context;
- recover an obtaining KindBridge relation with exact source/target kind participants and its separate bridge assertion with pinned scheme/signature editions, mapping rule, definedness,
CL^k, loss, evidence, and admitted use; - recover the independently authored target
KindSignatureedition; - require translated Claim scope to cover
TargetSlice; - when an actual candidate is current, evaluate the fresh target judgment
J(candidate, targetKind, targetSignatureEdition, TargetSlice)and preserve all three values; - apply the justified scope- and kind-bridge consequences to R only; and
- make the separate allow/refuse decision.
A source judgment may support reliance but MUST NOT be copied as target truth. If no candidate is current, the guard ends at declaration-level compatibility and scope; it does not fabricate one.
Evaluation semantics and order (normative)
E-01 (Order). Recover exact declarations and kind compatibility first; check Scope coverage second; evaluate an exact candidate only when the receiving action is candidate-bearing; then apply R consequences, freshness, and policy thresholds before the separate action disposition.
E-02 (Determinism). With fixed candidates when any, kind/signature editions, slices, bridge/assertion editions, dependencies, and time selectors, the judgments and guard predicates MUST be reproducible. Implicit “latest” is forbidden.
E-03 (Three values). Every current C.3.2 or C.3.4 classification consumed by a guard MUST retain true, false, or unknown. Missing evidence, unavailable declared dependency, or out-of-domain input MUST NOT be coerced to false.
E-04 (Fail-closed without truth rewrite). A required false, unknown, missing declaration, non-obtaining relation, unavailable bridge assertion, or uncovered Scope causes refusal. The refusal is not itself a classification value or an assertion that the relevant world-side relation fails to obtain.
E-05 (Weakest link and bridge consequence). Chained bridge assessments use the governed weakest-link rule. The receiving R path records each relied-on bridge/assertion; neither F nor G nor a judgment value is modified.
E-06 (Predicate separation). Declaration compatibility, candidate classification, Scope coverage, evidence freshness, bridge applicability, capability fit, and action disposition SHALL remain separately inspectable predicates.
Conformance checklist (normative)
Proven-equivalent aliases
A context-specific guard alias is equivalent only when all required objects, inputs, classification values, bridge distinctions, and disposition boundaries can be recovered. Similar wording or the same final allow/refuse bit is insufficient.
Bridge consequences
Phi(CL_scope) and Psi(CL_kind) are monotone non-increasing consequences on the receiving R path under the governing bridge patterns. This Annex prescribes no numeric form. It never performs arithmetic on F or G.
Decision trees (informative)
D1 — Admit a quantified claim.
- Pin the quantified claim kind, receiving kind, and both exact signature editions.
- In one context, require the receiving kind to be identical to or a subkind of the claim kind; across contexts, recover the exact source-claim to target-receiving KindBridge relation and assertion.
- Check Claim scope against the exact TargetSlice and
Gamma_time. - Apply R consequences and freshness/threshold checks.
- Return the separate action disposition. Do not ask for a candidate unless the receiving use applies the claim to one.
D2 — Apply the claim to a candidate.
- Identify the candidate under its direct governor.
- Complete D1.
- Evaluate the exact four-input target judgment under the receiving-kind declaration; use the already established order or bridge for the claim-kind consequence.
- On
true, continue; onfalse, refuse as known failure; onunknown, refuse and retain the non-settlement reason.
D3 — Compose or cross a context.
- Pin source and target declarations.
- Recover the obtaining kind relation/bridge and separate assertion; recover Scope Bridge separately.
- Check the serial or translated scope.
- If an actual output/candidate is current, evaluate it under the target declaration.
- Apply R consequences and decide separately.
D4 — Publish a union.
- Complete the relevant D1/D2 checks per line.
- Demonstrate support-line independence.
- Publish only the supported union; retain line-specific classifications and bridge consequences.
Guard anti-patterns and remedies (informative)
Worked examples (informative)
E1 — Same-context braking claim. A policy quantified over Vehicle pins VehicleSignature@v4; the receiver pins PassengerCarSignature@v3. Declaration admission establishes SubkindOfObtains(PassengerCar, Vehicle; plantVehicleScheme). Applying the policy to VIN-17 evaluates J(VIN-17, PassengerCar, v3, S-plant); on true, C.3.1 monotonicity supplies the Vehicle-side consequence needed by the universal claim. A missing axle dependency yields unknown and a separate refusal.
E2 — Cross-plant reuse. An obtaining KindBridge relates source Vehicle to target TransportUnit; its assertion records a collapsed EV/ICE distinction and CL^k=2. The target signature is independently authored. Plant-B evaluates its exact vehicle candidate under that target edition; the source result is only support, and bridge consequences lower R.
E3 — API adapter. A producer declares Request; a consumer expects AuthenticatedRequest. Declaration compatibility fails until an adapter and target declaration are recovered. For request req-884, unavailable key-validation support yields target unknown; the consumer refuses without asserting that the request is known unauthenticated.
E4 — Masked clinic use. The guard designates the exact AdultPatient@Clinic RoleMask declaration, base signature edition, patient candidate, and slice. Unavailable date-of-birth support yields unknown; the mask label and EHR row do not classify the patient.
Rationale
One final allow/refuse bit is operationally convenient but ontologically poor. Keeping declarations, candidate judgments, Scope, bridges, evidence, and disposition separate lets a reviewer see which repair is needed and prevents a guard from becoming a hidden relation, assertion, or evidence-to-truth converter.
C.3.A:Annex A - Regulatory and compliance alignment [A/I]
C.3.A:A.1 Purpose and fit
Regulations name categories such as Adult person, Class II medical device, Personal data, and Lease. A local context needs both a faithful category correspondence and explicit jurisdiction/version/time applicability. The kind channel answers “about what”; USM Scope answers “where and when”; neither answers whether one exact local candidate satisfies the target criterion.
C.3.A:A.2 Normative obligations
C-REG-1 (Regulatory declarations). Each used regulatory category SHALL be an exact authority-context local kind with a separately identified KindSignature declaration episteme edition. Any F value characterizes that episteme, not the kind.
C-REG-2 (Kind correspondence). Cross-context category use SHALL recover an obtaining KindBridge relation between exact authority and local kinds plus a separate bridge assertion with mapping, pinned editions, preservation/loss, CL^k, evidence, definedness, and admitted use.
C-REG-3 (Scope). Jurisdiction, effective dates, grace periods, and other genuinely contextual applicability conditions SHALL be Claim scope over exact context slices with explicit Gamma_time. A product-family or platform distinction belongs in Scope only when it is genuinely a context-slice dimension of the claim; when it classifies the target entity, recover it as an exact kind and, for candidate-bearing use, an exact candidate judgment. A direct candidate feature remains with its own governor and SHALL NOT be smuggled into Scope.
C-REG-4 (No synonym shortcut). A legal label, translation row, or policy card SHALL NOT substitute for the KindBridge relation, its assertion, or the target declaration.
C-REG-5 (Exact candidate use). Whenever a policy is applied to candidate candidate, the guard SHALL evaluate J(candidate, localKind, localSignatureEdition, localSlice) and retain true, false, or unknown. Declaration compatibility alone is insufficient.
C-REG-6 (Consequences). Justified kind- and scope-bridge consequences SHALL affect R only. They SHALL NOT alter F, G, or the candidate judgment.
C-REG-7 (Editioning). A change in law that changes the criterion creates another signature episteme edition; a change in applicability changes Scope. C.3.1 decides kind continuity. Guards SHALL pin editions and time and SHALL NOT rely on “latest”.
C-REG-8 (Local adaptation). A local nuance MAY use a RoleMask declaration. If it becomes a stable conceptual distinction, the context SHALL separately identify any new local kind and establish its obtaining subkind relation; mask reuse does not perform that change.
C.3.A:A.3 Regulatory guards
Guard_RegAdopt(P, candidate, authorityKind, authoritySignatureEdition, localKind, localSignatureEdition, S_local).
- Check P's governed scope and explicit time against
S_local. - Recover the exact authority/local declarations, KindBridge relation, and bridge assertion.
- Check bridge applicability and route its consequence to R.
- Evaluate
J(candidate, localKind, localSignatureEdition, S_local). - Continue only on
true; retain knownfalseorunknownbefore refusing. - Check freshness of relied-on regulatory and candidate support separately.
Guard_RegChange(change, impactedDeclarations, impactedScopes).
- Decide whether the change alters criterion, reference scheme, applicability, or more than one.
- Author the required signature episteme edition and let C.3.1 settle kind continuity.
- Update Scope independently when jurisdiction/version/time coverage changes.
- Reassess the bridge assertion's mapping, loss,
CL^k, evidence, and admitted use. - Evaluate affected exact candidates for the new receiving use under the new declaration edition while preserving every prior judgment indexed to its prior edition and slice; do not edit a set representation or rewrite historical judgments as a substitute.
Guard_RegXContextUse(P, candidate, sourceKind, targetKind, targetSignatureEdition, S_target). Apply Guard_XContext_Typed and then the exact target candidate judgment. A missing target dependency yields unknown; it is not cured by a high bridge assessment.
C.3.A:A.4 Worked examples [I]
Adult dosage across jurisdictions. Authority kind AdultPerson@RegY uses threshold 18; hospital kind AdultPatient uses 21. The obtaining KindBridge and its assertion state the boundary loss and CL^k=1. For patient P-44, the hospital evaluates its target signature edition in the dated formulary slice. Missing DOB support gives unknown; the guard refuses without asserting that P-44 is a non-adult.
GDPR and CCPA. Two source kinds relate to independently identified product-context kinds through separate bridges/assertions. Each policy has its own jurisdiction/time Scope. A data item is governed by a fresh target judgment; an alias table is support, not classification.
Export control. The shipping policy pins the target product signature edition, shipment candidate, destination/end-use slice, and date. Category correspondence and Scope translation have separate bridges. The exact product judgment and the shipping guard disposition remain separate; higher residual risk may require manual review.
IFRS and US GAAP Lease. Each authority kind and local corporate kind remains independently identified. The bridge assertion records the short-term-exception loss. Test planning targets boundary candidates under pinned target declarations rather than treating one shared label as truth.
C.3.A:A.5 Guidance and migration [I]
- Inventory regulatory claims, exact category declarations, and applicability slices.
- Recover or author target
KindSignaturedeclaration editions; keep F on those epistemes. - Establish KindBridge relations and separate assertions with loss and admitted use.
- Rewrite candidate-bearing guards to pin candidate, local kind, signature edition, and slice.
- Preserve
unknownand record refusal separately. - Route Scope through USM and bridge consequences through R.
- Use RoleMask declarations for local procedural tailoring; separately establish a new kind/order relation only when the distinction truly becomes conceptual and stable.
C.3.A:A.6 Manager's compact pattern [I]
- Where and when? Claim scope over exact context slices.
- About what? Exact local kind and signature declaration; KindBridge relation/assertion if foreign.
- Which exact thing? Fresh target
J(candidate, kind, signatureEdition, slice). - Can we act? A separate guard disposition after scope, judgment, bridge, freshness, and policy checks.
C.3.A:Annex B - Assurance lanes and evidence design [A/I]
C.3.A:B.1 What typed assurance adds [I]
VA can prove a claim quantified over an exact declared kind; LA can exercise exact candidates and boundary cases under pinned editions and slices; TA can qualify the tools used to produce support. None of those lanes turns evidence existence into classification truth.
C.3.A:B.2 Normative obligations
EA-1 (Declaration and candidate binding). Every VA/LA artifact SHALL cite the governed claim, exact quantified kind and signature edition, and assumed Scope. Candidate-specific evidence SHALL additionally name each exact candidate and its four-input judgment.
EA-2 (Subkind coverage). A claim over kind k SHALL justify coverage over relevant obtaining subkind relations and paired signature editions. RoleMask rows may cover named procedural uses but SHALL NOT silently stand in for a stable subkind.
EA-3 (Three values in evidence use). A test, observation, or proof may support a classification assertion. An unavailable evidence dependency yields unknown; failed evidence retrieval MUST NOT be recorded as candidate false.
EA-4 (Independent unions). SpanUnion SHALL include a support-line independence account and preserve per-line candidate judgments and bridge consequences.
EA-5 (Bridges). Cross-context evidence use SHALL recover Scope Bridge separately from KindBridge relation/assertion, use the independently authored target declaration, and evaluate target candidates afresh. Consequences affect R only.
EA-6 (Freshness). Evidence windows and tool/declaration editions SHALL be explicit and tied to the governed slice. Expiry causes refusal or unknown at the predicate it disables; it does not widen Scope.
EA-7 (TA separation). Tool qualification SHALL remain distinct from content proof, candidate facts, classification judgment, and receiving disposition.
EA-8 (No scope-by-wording). More general wording, more matching candidates, or additional evidence-matrix rows SHALL NOT widen G. A ΔG+ change requires the new support or sufficiently congruent bridge basis required by A.2.6; otherwise retain or narrow the declared Scope.
C.3.A:B.3 Evidence matrix [I]
Rows plan declared distinctions; they do not classify every candidate. A proof-only row may remain declaration-level when it genuinely proves a universal claim. A test or monitoring row becomes candidate-bearing and records exact judgments for the exercised candidates.
C.3.A:B.4 VA lane [A/I]
- VA-1. A proof carrier SHALL cite the exact claim, quantified kind,
KindSignatureedition, and assumed scope slices. - VA-2. A proof of a universal claim need not invent a candidate; application to an actual candidate uses
Guard_CandidateUseseparately. - VA-3. Cross-context proof reliance SHALL recover both bridge channels, the target declaration, loss, and R consequences.
- VA-4. Tool-kernel qualification belongs to TA and does not raise the declaration's F or candidate truth.
Example: a proof over PassengerCarSignature@v4 assumes a dry-road slice. Reuse at Plant-B requires bridge/scope settlement. Application to VIN-17 then uses the Plant-B target signature and exact target judgment.
C.3.A:B.5 LA lane [A/I]
- LA-1. Each test or monitoring campaign SHALL state row declaration editions, slice columns, exact tested candidates, and their judgments.
- LA-2. Boundary probing SHALL distinguish criterion boundaries from Scope boundaries.
- LA-3. A KindBridge assertion that records collapsed distinctions SHALL lead to explicit coverage repair; it does not alter target truth.
- LA-4. Freshness and SpanUnion independence SHALL remain explicit.
Example: rows PassengerCar and LightTruck use pinned signature editions; columns cover dry/wet slices. The tested VINs are exact candidates. A missing sensor dependency for one VIN yields unknown, not a negative vehicle classification.
C.3.A:B.6 TA lane [A/I]
Qualify provers, checkers, measurement pipelines, and classifiers separately. A classifier output can support an assertion about J; the tool neither becomes the candidate nor makes the governed criterion hold. Version drift may make the support unavailable and hence produce unknown for a candidate-bearing use.
- TA-1. Every tool whose qualification is relied on by VA or LA SHALL identify its exact version and qualification status, and the receiving guard SHALL recover that declaration when the reliance is current.
- TA-2. Missing or weaker tool qualification MUST NOT be hidden by lowering the owning episteme's F or widening G. The receiving policy may require additional independent support, reduce or condition R, or refuse the use while preserving the exact unavailable-support reason.
C.3.A:B.7 Evidence guards
Guard_EvidencePlan_Typed SHALL check exact row declaration editions, exact slice columns, bridge/assertion needs, candidate-selection policy, freshness, independence, and TA declarations. Planning rows do not count as candidate judgments.
Guard_EvidenceAttach_Typed SHALL bind every evidence unit to its exact claim/use, row declaration, slice, exact candidate when current, judgment value, support relation, freshness, and bridge consequences. It SHALL preserve unknown and the separate attach/refuse disposition.
C.3.A:B.8 Anti-patterns and remedies
C.3.A:B.9 End-to-end example [I]
A two-plant braking claim pins the PassengerCar declaration and Plant-A scope. VA proves the quantified claim over that declaration. LA tests exact VINs in dry/wet slices and records their judgments. TA identifies tool versions. Plant-B reuse recovers both bridges, the target declaration, loss and R consequences; each Plant-B candidate is evaluated afresh before evidence is attached.
C.3.A:Annex C - ESG and Method–Work guards
C.3.A:C.1 ESG obligations (normative)
When a state transition publishes or relies on a claim quantified over kinds, the ESG guard SHALL:
- pin the claim, exact quantified claim kind, receiving kind, and both needed
KindSignatureeditions; - establish the correct same-context restriction direction or the exact source-claim to target-receiving KindBridge relation and separate assertion;
- check Claim scope and explicit
Gamma_time; - when one or more actual candidates are part of the transition, evaluate each exact four-input target receiving-kind judgment and preserve all three values;
- when a RoleMask is used, recover its declaration edition and evaluate the exact masked judgment;
- apply justified bridge consequences to R only;
- check formality and freshness on their actual owners; and
- return a separate state-transition disposition.
ESG MUST NOT widen G to hide incompatibility, treat a label as a candidate judgment, or convert unknown to false.
C.3.A:C.2 Method–Work obligations (normative)
This Method–Work slice is conditional; it is not a definition that makes every actual change agentic, capability-held, planned, method-mediated, or Work. Open its capability/method/WorkPlan entry checks only when those objects and an A.15.1 Work use are current. A natural, spontaneous, formal, jointly caused, or non-separable U.Transformation remains under A.3/A.3.4 and does not acquire a fictive performer, role assignment, method, capability, plan, or Work to satisfy this guard. A broader scale-free-agency or Work decision remains with A.13 and A.15.1; planned C.9 may later consolidate an agency-characteristic profile but supplies no current governing force. This annex neither settles nor forbids that decision. Reflexive cases require separately grounded acting and affected positions, while joint or non-separable cases keep their direct dynamics, interaction, or causality governors rather than forcing one arbitrary actor-target split.
When the Method–Work use is current, it has two different boundaries.
Prospective entry. Before execution, a guard may decide that a holder capability, method, intended U.WorkPlan, JobSlice, and candidate inputs are sufficient to start. That decision SHALL NOT claim that Work already occurred. The capability instance, capability statements or currentness assessments, fit predicates, WorkPlan, JobSlice, and entry record remain distinct.
Actual result or acceptance. When performed Work is current, the guard SHALL identify exact W : U.Work as an independently grounded, world-side, dated 4D Work occurrence under A.15.1. W is not the U.Work kind, JobSlice, capability, plan item, log, card, row, or assertion. Any plan, log, result record, or assurance record about W is a separate episteme that designates W.
A conforming Method–Work check SHALL:
- require the capability's governed Work scope to cover exact JobSlice with explicit time;
- check capability measures, qualification/currentness, and fit as separately governed predicates;
- pin every expected input/output local kind and signature edition;
- for every actual input candidate, evaluate
J(inputCandidate, expectedInputKind, inputSignatureEdition, JobSlice)and preserve all three values; - use exact RoleMask declarations and masked judgments when procedural tailoring is current;
- establish exact target bridges/declarations and fresh target judgments for cross-context candidates;
- before execution, return only an entry disposition and keep W absent;
- after execution, identify W independently and, for every actual output candidate relied on, evaluate the exact output judgment;
- keep W, inputs, outputs, JobSlice, capability, plan, logs, and assertions distinct; and
- refuse fail-closed on
falseorunknownwithout rewriting either value.
C.3.A:C.3 Ready-to-use skeletons
ESG_TypedGate(Claim, claimKind, claimSignatureEdition, receiveKind, receiveSignatureEdition, TargetSlice, candidates?). Apply Guard_TypedClaim to the exact claim and receiving kinds; for each actual candidate apply Guard_CandidateUse with both declaration editions; apply bridge, freshness, and policy predicates; return the separate transition disposition.
MethodWork_EntryGate(Capability, WorkPlanRef, JobSlice, inputCandidates, inputDeclarations). Check Work scope, capability/qualification/fit predicates, exact input judgments, masks, bridges, and freshness. Return “entry allowed/refused”. Do not create or identify W.
MethodWork_ResultGate(W, JobSlice, actualInputs, actualOutputs, declarations, ResultRecordRef?). First recover the independently grounded dated W under A.15.1. Then evaluate exact input/output candidate judgments, check scope and any acceptance predicates, and keep any ResultRecordRef as a separate episteme designating W.
C.3.A:C.4 Worked examples [I]
ESG braking policy. The claim pins VehicleSignature@v4 and the dry/wet TargetSlice. The consumer is restricted to PassengerCar, and SubkindOfObtains(PassengerCar, Vehicle; plantVehicleScheme) holds under the paired exact declaration editions. For VIN-17, evaluate J(VIN-17, PassengerCar, passengerCarEdition, TargetSlice)=true; C.3.1 monotonicity then supplies the Vehicle-side classification needed by the universal claim. An unavailable brake-configuration dependency would yield unknown, and the transition would refuse separately.
Risk-score Work entry and occurrence. ComputeRiskScore capability is considered for request req-884 in JobSlice api-v2.3/eu-west/t-204. The entry guard evaluates the request under the pinned AuthenticatedRequest signature. If true, it may admit execution; no Work occurrence yet follows. After execution, actual W = RiskScoreRun-2026-07-22T10:03Z-884 : U.Work is independently grounded as the dated world-side occurrence. RiskScoreRunLog-884 is a separate episteme designating W. The output score value is a separate candidate evaluated under its declared output kind and signature edition.
Cross-context plant use. The source claim and source kind cross via separate Scope and KindBridge channels. Plant-B recovers its own target declaration and evaluates exact TransportUnit candidate TU-9. Bridge assertions affect R; they do not classify TU-9 or create the later Work occurrence.
C.3.A:C.5 Anti-patterns and remedies
C.3.A:End
Decision Theory (Decsn-CAL)
Type: Calculus (C) Status: Stable Normativity: Normative unless marked informative
At a glance. C.11 is the choice-calculus pattern for the moment when options already exist and the working question is which option to choose, including whether another probe is worth its cost before commitment.
Problem frame
When ongoing Work still needs a next action. If admissible actions still have to be recovered from ongoing Work, its domain Method, and current facts, use A.15.7 first. Return here only when a current chooser and OptionSet exist and comparison can change the result; a mandatory response or one familiar cue need not be inflated into an option set.
Use this when. Use this pattern when one DecisionSubject already has an OptionSet in hand and the real question is how to choose among those already-available options under uncertainty, preference, causal or subjunctive dependence, and bounded probing or computation.
Start here when. Start here when a person, team, organization, or other decision-capable system must decide whether to choose now or spend more effort on probing, information gathering, or computation before choosing.
First output. The first useful output is one explicit DecisionSubject, one explicit OptionSet, one explicit comparison basis, one explicit ChoiceRule, and one explicit ChoiceResult saying whether the lawful choice result is choose now, reject the current set, probe more, or move to a neighboring question.
If that first output still cannot be written honestly, the current comparison state is not late-stage choice doctrine yet. The case is still unfinished local choice work or one neighboring question in disguise.
Immediate failure indicators.
- The chooser is still moving between person, team, organization, or another collectivity-bearing level.
- The current comparison is still inventing, expanding, or reframing options while also claiming to compare them.
- The current comparison says more information would help but cannot name one next probe that could still change the result.
- The current result is really surfacing one selected set or one enactment plan rather than one local choice.
First-minute questions.
- Who or what is actually choosing here, and at what chooser-bearing level?
- What options are already on the table now?
- What current basis is being used to compare them?
- What next probe could still change the choice, if any?
- Is this still local choice, or has the question moved to a neighboring problem—for example, search, pool policy, selector-result declaration, publication availability, or enactment?
Typical reroutes. C.38 when labels or fragments still need to become complete ways of obtaining the same result; C.18 when the real question is open-ended invention or reframing; C.19 when the working question is how broadly to explore or exploit the candidate pool; C.24 when one option is already chosen and the work has become sequencing or enactment; A.13 when the hard question is agenthood rather than choice (planned C.9 is future characteristic-profile consolidation only); A.18 or A.19 when the mathematical support question itself becomes primary.
Common neighboring-pattern mistakes. Do not use C.11 to hide search work inside "decision", to hide candidate-pool policy inside one local choice, or to hide execution planning inside one generic rationality account. Do not treat declaring selector-facing set-result content, or later making that result available, as if either were the same question as deciding.
What goes wrong if this pattern is missed. Search, selection policy, planning, and choice doctrine collapse into one blurred notion of rationality. Teams either choose too early because pool policy was never stated, keep probing without one reason the next probe is still worth its cost, or leave only one vague claim that "a decision was made" without one explicit decision record naming the current result.
What this pattern buys. This pattern gives one stable place to compare classical, causal, success-first or subjunctive, bounded-resource, active-inference-adjacent, and quantum-like decision lines without silently reassigning search, selection, or planning doctrine to the wrong question. In practice it buys one explicit answer to four questions: choose now, reject the current set, probe again, or reroute.
Not this pattern when. Do not start here when the current question is still generating candidate options, setting exploration or exploitation policy over a candidate pool, declaring selector-facing set-result content, making that result available to an audience, or sequencing execution under an operational plan.
Decision work often fails not because no options exist, but because the choice among existing options is never typed as its own question. C.11 starts from one narrower and more useful center: one decision subject choosing among already-available options, including whether more probing is worth the cost before the choice is fixed.
Problem
Many systems have options on the table but still lack one explicit doctrine for what makes one option rational to choose. They mix together at least four different questions.
One question is still generating candidate options, variants, or open-ended search directions. Another question is governing how broadly a candidate pool should be explored or exploited before narrowing. A third question is planning, sequencing, replanning, or enacting the chosen option once a choice has already been made. The fourth question, and the one governed here, is choosing among already-available options under uncertainty, dependence, and bounded deliberation.
A second distortion appears when decision theory is reduced to one thin slogan about expected utility. Real choosers face evidential and causal distinctions, subjunctive or success-first cases, probe costs, information value, computation value, and situations where the chooser is not just one isolated individual.
Without one explicit place for choice calculus, search, candidate-pool policy, and planning rush into the same question, while the actual doctrine of choosing among live options disappears behind generic talk about rationality.
Forces
Solution
Causal-use hook for choice records
When a choice depends on an effect, intervention, counterfactual, causal-policy, or off-policy claim, the ChoiceResult keeps the decision question local and cites the C.28 support result as one basis.
Omit the tail when causal support changes neither the comparison nor the chosen result. If causal wording changes the result, include the tail or downgrade the wording. A C.28 result does not choose, permit, or deploy an option; C.11 uses it with the other decision premises and may still select, defer, or abstain.
Primary EntityOfConcern and admissible choice result
C.11 governs theory-side choice among already-available options. Its selected decision result states what should be chosen from the current OptionSet, including whether further probing, information gathering, or computation is rational before the choice is fixed.
The OptionSet choice question begins only after an option set already exists. It does not form complete ways of obtaining one result, govern open-ended generation of options, or govern the execution order of a plan after a choice has already been made.
Decision discipline over a live option set
A conforming C.11 pass does not stop at naming schools of decision theory. It carries one usable choice discipline over a live OptionSet, and it ends with one explicit ChoiceResult under one explicit ChoiceRule.
-
Fix the chooser and the choice-bearing level. State one
DecisionSubjectand oneDecisionSubjectGranularity. If the real dispute is still about who or what counts as the chooser, coordinate withA.13instead of hiding that dispute inside one local choice; plannedC.9may later consolidate an agency-characteristic profile but supplies no current governing force. -
Freeze the current option set. State the already-available options being compared now as one
OptionSet. If the rows are only labels or fragments and the question is several complete ways to obtain the same result, stop here and applyC.38. If the hard work is open-ended invention, expansion, or reframing, applyC.18. -
Make the comparison basis explicit. State one
PreferenceOrderor oneEvaluativeMeasure, plus oneBeliefStateand oneOutcomeModel. The comparison is not usable if some options are being judged under one belief state and other options under one later, unmarked update. If two options are only comparable after one further probe or one model revision that changes the belief state or outcome model before comparison, say that the current comparison is unfinished and apply step 5 rather than pretending that one silent basis shift already solved it. -
Choose the dependence layer that actually governs the case. Start from the evidential baseline when the choice is being compared through likely outcomes under the current
BeliefState. Add oneInterventionModelwhen taking one option changes the world through intervention rather than mere observation. Add oneCounterfactualModelplus oneSubjunctiveDependenceRelationwhen the case depends on one predictor, one structurally linked chooser, or one decision-procedure coupling that intervention talk alone does not capture. Use the least-committing dependence layer that still covers the live case, and do not switch layers across options without saying so explicitly. -
Run the probe-worthiness test before commitment. State one
ProbeActionSet, oneProbeBudget, and oneCostToProbe. UseValueOfInformationfor additional observation or measurement, andValueOfComputationfor additional reasoning, simulation, or search over the already-available options. This rule is intentionally local or myopic: it judges the best next feasible probe over the currentOptionSetand current comparison basis, not one full sequential or non-myopic experimental program. RicherOEDlines may strengthen this doctrine, but the localC.11closure rule already has to decide whether the next feasible probe can still change the current choice. If no feasible further probe fits the remainingProbeBudget, or if the best available probe no longer justifies itsCostToProbe, close under the current comparison basis. If a feasible probe is still worth its cost, and that probe could still change which option survives or whether the currentOptionSetshould be rejected, run it, update theBeliefStateandOutcomeModel, and return to step 3. If one choice result is already fixed and the remaining probe would change only execution-path description, call-plan ordering, enactment budget, or checkpointing of that chosen option, stop treating the probe as local choice doctrine and applyC.24. -
Apply one
ChoiceRuleand emit oneChoiceResultplus the next question. End with one explicit result:choose now,reject current set,probe again, orreroute because this is no longer local choice. If the result ischoose now, name the winning option or the retained tie-set plus the reason no remaining feasible probe is worth its cost. If the result isreject current set, name the reason no current option survives under the present basis and, when more work follows, the neighboring question that now takes over. If the result isprobe again, name the next probe and the exact comparison defect it is supposed to repair. AC.11pass is done only when it names the lawful choice result and the reason that result is lawful.
Receive heterogeneous premises without relabeling them as signals
An interesting observation, information-gain estimate, capability result, objective or reward, articulated former cue, or C.17 characterization enters this pattern only under its exact source/result identity. Use E.10.LRN first when learning wording still hides that identity. Use A.10 when an evidence-bearing or source-bearing claim is actually relied on: its existing RelianceDisposition qualifies only that bounded premise use. An objective, reward, preference, or loss enters as the EvaluativeMeasure, PreferenceOrder, or ChoiceRule input it actually supplies and is not evidence by numerical form. When an A.16.1 cue pack remains current as a source or provenance episteme, preserve that source identity and route the separately articulated endpoint result through its direct claim owner. A C.17 novelty, surprise, use, or creativity characterization remains a characterization and does not license a move by itself.
No separate premise-qualification result sits between those owners and C.11. Use the qualified inputs in the live option/probe comparison and return only the existing ChoiceResult. When the missing comparison basis is specifically what a finite candidate contributes relative to the current configuration, use C.11.CRC to construct that ordinary comparison claim and return here. If every premise and the finite comparison are already explicit, proceed directly.
Well-formed comparison state
Well-formedness constraint: a live C.11 comparison state is usable only when the decision record states all of the following:
- one
DecisionSubjectat oneDecisionSubjectGranularity; - one current
OptionSet; - one current comparison basis through
PreferenceOrderorEvaluativeMeasure, plus oneBeliefStateand oneOutcomeModel; - one active dependence layer for the current comparison, unless the record explicitly says that comparison is still being reopened;
- one current account of whether another probe is still feasible and worth its cost.
The comparison is still unfinished, not yet wrong but not yet closeable, when any of the following remains true:
- the chooser is still shifting between person, team, organization, or another collectivity-bearing level;
- the option set is still changing while the record also claims to rank the options;
- one option is being judged under one belief state and another under one later update that is not itself declared as the next probe result;
- one heavier dependence layer is invoked for rhetorical force, but the record never states what defect of the lighter comparison it repairs;
- the record says more information would help, but never says which probe could still change the choice and why.
Minimal admissible decision semantics
This minimal choice doctrine does not settle every decision-theory dispute, but it already supports some semantic distinctions by value and rules out others.
The following are lawful in this C.11 body when they are stated explicitly:
- one incomplete or only partially ordered
PreferenceOrder, so long as the unresolved comparison stays visible through one retained tie-set, one further probe, or one honestreject current setresult rather than one fake winner; - one
EvaluativeMeasurefor magnitude, threshold, or trade-off-sensitive cases, so long as the measure being used now is explicit enough to explain why the current result follows under it; - one temporary unresolved criterion conflict, so long as the record says whether the present comparison is using one priority order, one threshold, one explicit trade-off measure, or one unfinished state that still blocks closure;
- one explicit
BeliefStaterevision, so long as it enters the comparison as one named probe result or one named model repair rather than as one silent basis shift; - one widened
DecisionSubjectat person, team, organization, or other collectivity-bearing level, so long as the current subject-bearing level is explicit and the record does not hide unresolved cross-scale or cross-collective conflict behind one generic chooser label.
The following are not admissible in this C.11 body:
- silently totalizing one genuinely partial preference relation just to force
choose now; - silently switching from one criterion mix or one belief state to another across options;
- pretending that unresolved cross-scale or cross-collectivity conflict is already one settled local ranking when the aggregation question has not actually been discharged;
- using one polished record shape as a substitute for one stated comparison doctrine.
This is why C.11 is more than one note-taking protocol. The body already supports local incompleteness, partial order, explicit trade-off measures, and wider chooser-bearing cases, but it requires those semantic facts to change the lawful result rather than remain hidden beneath one elegant summary line.
Probe-worthiness rule
Another probe is worth doing only when all three conditions hold together:
- the probe fits inside the remaining
ProbeBudget; - the expected gain from the probe, through
ValueOfInformationorValueOfComputation, is large enough to justify itsCostToProbe; - the probe can actually change the local choice result by changing the ranking, breaking or creating a tie, showing that no current option survives, repairing one missing comparison, or showing that the question should reroute.
This is the current local or myopic probe-worthiness rule for C.11: judge the best next feasible probe over the current OptionSet, not one whole non-myopic experiment design over longer horizons. Later sequential or non-myopic OED may strengthen this doctrine, but they do not relocate the local-choice question outside C.11.
Do not keep probing merely because uncertainty remains. Uncertainty is ordinary. What matters is whether one feasible next probe can still change what should be chosen, or whether the current OptionSet should be rejected, from the current local choice question.
If the best available next probe cannot change which option survives, cannot change whether the current set should be rejected, or cannot justify its cost, the correct result is not one vague statement that the case is hard. The correct result is one explicit ChoiceResult under the current basis and current ChoiceRule.
If the next probe would no longer change which option survives but would only change how one already-chosen option gets enacted, budgeted, or checkpointed, the question has already crossed to C.24.
ChoiceRule versus ChoiceResult
ChoiceRule and ChoiceResult are not the same kind of thing.
ChoiceRuleis the doctrine or operator that says how the current comparison basis, dependence layer, and probe-worthiness value support oneChoiceResult.ChoiceResultis the emitted record stating which choice result is lawful now under that rule.
The operational answer of this pattern is therefore one emitted ChoiceResult under one explicit ChoiceRule. The result is complete only when it states the choice result and the condition that makes that result lawful.
Only four result forms are lawful here:
choose nowreject current setprobe againreroute
A fifth soft result such as "keep thinking", "stay with the current view", or "the case is still complex" is not a conforming output. It is one unfinished state that still needs to be typed.
For choose now, the emitted ChoiceResult should show:
- the selected option or the retained tie-set;
- the comparison basis under which that result currently holds;
- the reason no still-feasible probe is worth its cost.
For reject current set, the emitted ChoiceResult should show:
- that no member of the current
OptionSetsurvives under the present comparison basis; - the exact shared defect, threshold failure, or dominated-outcome reason that defeats the current set;
- the next neighboring question only when more work now follows, such as new option generation or one explicit escalation path.
For probe again, the emitted ChoiceResult should show:
- the exact next probe;
- the comparison defect that probe is expected to repair;
- the reason the probe is still worth its cost.
For reroute, the emitted ChoiceResult should show:
- the neighboring pattern authority that now governs the question;
- the reason this is no longer local choice among already-available options.
Closure rule over the current OptionSet
The comparison may close as choose now only when all of the following are true together:
- the current
OptionSetis stable enough that the decision record is no longer still inventing options; - the current comparison basis is explicit enough to state why one option survives or why one tie-set remains;
- no still-feasible next probe is expected to change the survivor relation with enough expected value to justify its cost;
- the record still concerns local choice rather than pool policy, selector-result declaration, publication availability, or enactment.
The comparison may close as reject current set only when all of the following are true together:
- the current
OptionSetis explicit and stable enough to reject as the present choice set; - the current comparison basis is explicit enough to show why no member survives under the present basis;
- no still-feasible next probe is expected to rescue one member with enough expected value to justify its cost;
- the result is still one local choice conclusion rather than one disguised pool-policy, selector-result declaration, publication-availability, or enactment result.
The comparison should close as probe again only when all of the following are true together:
- one next probe is named by value;
- that probe fits the remaining
ProbeBudget; - that probe is expected to repair one named comparison defect;
- that repaired defect could still change which option survives, whether the current set should be rejected, or whether the question should reroute.
The comparison should close as reroute when the record has already learned that the governing decision question changed:
- to
C.38when labels or fragments must first become complete-enough ways of obtaining the same result; - to
C.18when the option set itself is under open-ended invention or reframing; - to
C.19when the question is now how broadly to keep exploring or exploiting one candidate pool; - to
C.24when one choice result already exists and the next task is now sequencing, enactment, or execution-path probe work; - to
G.5when the next task is declaring or naming selector-facing selected-set content; when that result already exists, useE.17for its source-backed publication face and return to source andE.24.PUBfor the publication occurrence and audience availability.
If none of those closure conditions can yet be satisfied, the record is still unfinished. It is not rescued by richer terminology alone.
Minimal decision-record form
A minimal C.11 decision record has this shape:
The record does not need that exact syntax. It does need that exact content.
If the record does not state the current chooser, current options, current comparison basis, current ChoiceRule, current probe decision value, and current ChoiceResult, then it still behaves more like one doctrinal essay than one usable decision record.
Use branch language only when it changes the actual comparison being performed.
Resource-aware choice is one lens over declared source families
- Start from one declared source family or one declared source-family composition such as
Front,Archive, orFront+Archive. - Apply one declared decision lens over that source family rather than inventing one hidden universal winner rule.
CostToProbe,ValueOfInformation, andValueOfComputationbelong to that lens-side choice doctrine.- They may justify another probe, one changed local comparison outcome, or one stop decision, but they do not rename the current
DominanceSetand do not declare one shortlist-family result. - If one candidate remains worth probing because its expected information value still exceeds its expected cost, say that explicitly as one lens-side choice judgement.
- If one archive point remains worth probing because it may change the frontier later, keep that as one resource-aware choice claim, not as evidence that the point is already on the current front.
- The kernel floor here is:
A.19.SelectorMechanismremains the cited set-return floorSelectionSlotremains the selector output floor- if later selector-facing set-result declaration is required, that set-returning floor may support one
Shortlistor oneRankedShortlistinG.5rather than one forced single winner
Classical evidential baseline
Stay with the classical evidential baseline when the question is to compare already-available options through preferences, utilities or desirabilities, beliefs, and likely outcomes under uncertainty.
In this baseline, the options are being compared as evidence about what consequences are likely if they are chosen. This is the ordinary default when intervention structure, predictor-coupling, or context-sensitive non-commutativity are not yet doing real work in the case.
Typical practical cash-outs are:
choose nowbecause the current sharedBeliefStateandOutcomeModelalready make one option or tie-set survive, and no still-feasible probe is worth its cost;probe againbecause one further observation, measurement, or comparison pass could still change the ranking without requiring a heavier causal, subjunctive, or context-order repair;reroutebecause the current decision question is no longer really comparing one fixedOptionSet, but has become search, pool policy, selector-result declaration, publication-availability, or enactment work.
The baseline is still unfinished when the current comparison invokes it but cannot keep one shared BeliefState and OutcomeModel across the compared options, or when one heavier defect is already live and the current comparison still pretends one plain evidential comparison is enough.
Causal repair
Switch on one InterventionModel when taking one option changes the world through intervention rather than merely signaling which outcome was already likely.
What changes here is not the prestige label of the theory line, but the comparative question itself: the working question is no longer only what this option indicates about the outcome, but what this option causes in the outcome structure.
Typical practical cash-outs are:
choose nowbecause, under the declared intervention structure, one option now causally dominates or remains the survivor and no remaining feasible probe can reverse that causal ranking;probe againbecause one intervention-relevant uncertainty still blocks a lawful causal comparison and one named next probe could still change which option causally survives;reroutebecause the intervention-use question has already moved from local choice into enactment planning, protocol design, or one neighboring question.
This repair has not yet landed if the comparison still treats options only as evidence after invoking causal language, or if an InterventionModel is named without stating what defect of the lighter evidential comparison it repairs.
Success-first or subjunctive repair
Switch on one CounterfactualModel plus one SubjunctiveDependenceRelation when Newcomb-like, blackmail-like, or other predictor-coupled cases remain under-described by the older evidential-versus-causal split.
What changes here is that the comparison must stay answerable to linked decision procedures, predictors, or structurally similar choosers rather than only to direct intervention on one local event.
Typical practical cash-outs are:
choose nowbecause, under the declared counterfactual or subjunctive structure, one option survives once the predictor-coupled comparison is made explicit;probe againbecause one further model clarification, predictor assumption check, or decision-procedure comparison could still reverse the current survivor relation;reroutebecause the governing decision question is no longer settling local choice doctrine but has become one wider characterization, negotiation, or enactment question that only borrowed predictor-coupling language.
If that coupled structure is not live, do not activate this branch. If a predictor-coupled or success-first repair is named but the linked structure that changes the comparison is still unspecified, the branch is not yet load-bearing in the current decision.
Active-inference neighboring repair
Bring the active-inference line into view when the chooser is embodied, online, and socially coupled, and when the decision cannot be understood as one disembodied choose-then-act moment.
What changes here is practical choice logic, not one neighboring-school label. The comparison is no longer over one frozen snapshot alone. The comparison must now ask whether one more observation, one more coupled update, or one more socially mediated or role-expectation clarification actually changes what should be done now.
This minimal choice doctrine makes that social-expectation pressure explicit, but it does not yet operationalize one full ROE or SocialExpectationRegime object model inside C.11. If that heavier machinery is itself what the case hinges on, the decision record should say so honestly rather than pretending the local C.11 floor has already settled it.
Typical practical cash-outs are:
probe againbecause one further embodied observation, coupled update, or explicit role-expectation clarification can still change the state estimate enough to reverse the current survivor relation;choose nowbecause delay itself now worsens the state being managed, closes the window in which the preferred option remains feasible, or leaves no lawful time for one more socially mediated check;reroutebecause the question has already become enactment sequencing or agent-characterization work rather than local choice.
C.11 keeps the choice question visible there, but A.13 still governs the narrower question of what kind of agent or agential system is in play; the A.17/A.18/A.19/C.16/A.10 stack governs measured characteristic and evidence claims, while planned C.9 may only consolidate that profile later. C.24 still governs sequencing and enactment once a choice result has already been fixed.
Do not invoke this line only because one agent is acting in the world. Invoke it when embodied coupling, online updating, or explicit social-expectation pressure actually changes what the chooser should do now from the current OptionSet.
Quantum-like neighboring repair
Bring the quantum-like line into view when context effects, order effects, response-replicability tension, or incompatible-question structure change the comparative state enough that one simple commutative probability reading no longer fits.
What changes here is the practical structure of comparison. One order of questioning or one framing path may produce one different survivor relation from another. The comparison must therefore either stabilize the comparison under one declared order or show why one more clarifying pass is still needed.
This minimal choice doctrine keeps the branch at that measurement-sensitive recognition point. It does not yet claim one full quantum-like state-space package inside C.11; it claims only that the live comparison may need one explicit measurement-class or order-sensitive repair rather than one plain commutative reading.
Typical practical cash-outs are:
choose nowunder one declared order or framing because rival orders no longer change which option survives;probe againbecause one framing-sensitive comparison pass, one further question order, one response-replicability check, or one explicit measurement-class clarification could still reverse the survivor relation;reroutewhen the current decision question is no longer deciding among live options but has become one selector-result declaration, publication-availability, or enactment problem that only borrowed order-effect language rhetorically.
Do not promote this line to the unmarked default unless those repaired limitations are live in the case.
Do not invoke this line merely because a case feels psychologically subtle. Invoke it when one changed order, framing, response pattern, or incompatible-question structure actually changes the comparison state or the survivor relation in the live choice.
If none of those repaired limitations is live, stay with the classical evidential baseline rather than switching branches without one live repaired limitation.
The family map is therefore one disciplined set of refinements over the same choice question, not one excuse to rename every neighboring question as decision theory.
Reroute as soon as the question stops being local choice
Use C.11 while the question remains: from this current OptionSet, what should the DecisionSubject choose, and is another probe worth its cost before commitment?
Reroute immediately when the question changes:
- If the current rows are labels or fragments and the hard question is how several complete ways could obtain the same result, leave this pattern and work in
C.38first. - If the hard question is still what options should exist at all, or whether the current option set needs open-ended expansion or reframing, leave this pattern and work in
C.18first. - If the options already exist but the question is how broadly to keep exploring or exploiting the candidate pool, leave this pattern and work in
C.19, where the next useful output is one explicit pool-policy result rather than one localChoiceResult. - If one option is already chosen and the question is how to sequence, budget, or enact that choice, leave this pattern and work in
C.24, where the next useful output is one enactment-facing call plan orCheckpointReturn. - If the question has shifted from deciding to declaring or naming selector-facing selected-set content, leave this pattern and work in
G.5. Its next useful output may be aShortlistorRankedShortlistwhen alternatives remain for later choice, aJointUseSetwhen every named member is included for one bounded use, a narrowed handoff, abstain, or escalation. None is one more localChoiceResult. If that result already exists and the current question is presentation or availability to an audience, useE.17for the source-backed publication face and return to source andE.24.PUBfor the publication occurrence and availability.
ProbeBudget stays here while it means the epistemic or deliberative budget for one more probe before choice and while that probe can still change which option survives or whether the current set should be rejected. When the same word now means execution budget, call budget, enactment budget, or execution-path scouting after one choice result already exists, the question has moved to C.24.
ValueOfInformation and ValueOfComputation also stay theory-side here as comparative criteria while the question is still local choice among the current options. If one more probe could still change which option survives or whether the current set should be rejected, stay in C.11. If the choice result is already fixed and those criteria now govern only execution-path sequencing, call-plan ordering, or enactment of the chosen option, the question has crossed to C.24. C.19 and C.24 may consume the criteria, but they do not become the doctrine authorities for them.
Outside this pattern remain candidate generation, pool-wide exploration policy, selector-facing set-result declaration, publication availability, and execution planning.
Minimal inventory and mathematical floor
The minimum usable inventory for this pattern is:
- subject and option objects:
DecisionSubject,DecisionSubjectGranularity,OptionSet; - evaluative and epistemic objects:
PreferenceOrder,EvaluativeMeasure,BeliefState,OutcomeModel; - dependence and comparison objects:
InterventionModel,CounterfactualModel,SubjunctiveDependenceRelation,ChoiceRule,ChoiceResult; - probe and bounded-resource objects:
ProbeActionSet,ProbeBudget,CostToProbe,ValueOfInformation,ValueOfComputation.
These objects are required because the decision record must carry one explicit path from a live OptionSet through one live ChoiceRule to one emitted ChoiceResult.
Always explicit versus conditionally activated objects
The following objects should be explicit in every usable C.11 decision record:
DecisionSubjectandDecisionSubjectGranularity;OptionSet;- one evaluative basis through
PreferenceOrderorEvaluativeMeasure; BeliefState;OutcomeModel;ChoiceRule;ChoiceResult.
The following objects activate when the case needs them:
InterventionModelfor causal repair;CounterfactualModelplusSubjunctiveDependenceRelationfor success-first or predictor-coupled repair;ProbeActionSet,ProbeBudget,CostToProbe,ValueOfInformation, andValueOfComputationwhen one more probe or one more computation pass is still live.
What matters is not that every decision record mechanically mentions every token. What matters is that the current comparison does not smuggle one active question without naming the object that carries it.
Immediate lexical commitments:
- the default chooser term is
DecisionSubject, notAgent; DecisionSubjectGranularitynames the chooser-bearing level when the question is about whether the chooser is one person, team, organization, or another collectivity-bearing system rather than one generic scalar or coordinate;- relation-heavy wording remains answerable to
A.6.Ptogether withA.6.5.
Local plain glosses for the load-bearing inventory:
DecisionSubject: who or what is actually carrying this choice now, whether that is one person, one team, one committee, one organization, or another collectivity-bearing system;DecisionSubjectGranularity: the level at which the choice is being attributed, such as person-level, team-level, or organization-level rather than one vague "agent" label;OptionSet: the concrete options already on the table now;PreferenceOrder: the current better-than / worse-than ordering over those options for this decision subject;EvaluativeMeasure: the explicit utility-style or desirability-style scoring measure used when the case needs magnitudes, thresholds, or trade-offs rather than only one ordering;BeliefState: the current uncertainty-bearing state about the world, the case, and the likely consequences of the options;OutcomeModel: the model that maps options plus the current uncertainty picture to the consequences that matter for this choice;InterventionModel: the part of the model that says how the world changes because one option is actually taken;CounterfactualModel: the model used to compare relevant non-actual alternatives or alternate decision procedures;SubjunctiveDependenceRelation: the dependence between this choice and one predictor, one linked chooser, or one structurally similar decision procedure when intervention talk alone is not enough;ChoiceRule: the current choice doctrine or operator that says what conditions makechoose now,reject current set,probe again, orreroutelawful in this case;ChoiceResult: the emitted result record saying which of those lawful choice results actually follows now under the currentChoiceRule;ProbeActionSet: the further checks, measurements, simulations, or questions that can still be run before commitment;ProbeBudget: the remaining time, money, attention, or tolerated delay available for those pre-choice probes;CostToProbe: the real cost of another measurement, question, simulation, trial, or delay before commitment;ValueOfInformation: the expected gain from learning more before choosing;ValueOfComputation: the expected gain from spending more reasoning or compute before choosing.
What follows from DecisionSubject being wider than Agent:
- the chooser in
C.11need not be one person-like agent; - a team, committee, organization, or coupled human-tool system may be the
DecisionSubjectwhen that is the real level at which the choice is being made; - the pattern therefore does not force agency characterization to do the job of naming who or what is currently choosing.
This floor is enough to keep choice doctrine inspectable and stable. It does not yet assume one full branch-specific quantum-like package or one cross-scale geometry-heavy package.
Boundary on multilevel and social-expectation doctrine
DecisionSubject and DecisionSubjectGranularity are the local answer to human-only and individual-only narrowing. They keep the chooser explicit at person, team, organization, or other collectivity-bearing level so the doctrine does not silently collapse back into one generic individual agent.
This minimal choice doctrine does not yet settle all of the heavier doctrine that can sit behind that wider chooser-bearing scope. In particular, this body does not yet fully settle:
- collective aggregation doctrine over conflicting preferences or criteria;
- cross-scale or cross-collective conflict between person-, team-, organization-, or broader system-level objectives;
- one full
ROEor social-expectation structure for socially scaffolded choice; - one full multilevel or geometry-heavy formal package for those cross-scale or cross-collective questions.
Those absences are not hidden exceptions. They are explicit scope boundaries of this C.11 body. If one of those heavier questions is already live in the case, the decision record should say that the local C.11 floor is being used only as the current typed floor and should keep the unresolved aggregation, ROE, or multilevel support question visible by value.
Minimal decision tuple and finish condition
A C.11 decision record is complete only when it states:
- who or what is choosing:
DecisionSubjectat oneDecisionSubjectGranularity; - what is currently choosable:
OptionSet; - how the options are compared:
PreferenceOrder,EvaluativeMeasure,BeliefState, andOutcomeModel; - which heavier dependence layer is active when the case needs it:
InterventionModel,CounterfactualModel, andSubjunctiveDependenceRelation; - what comparison doctrine currently governs the case: one explicit
ChoiceRule; - what further probing is still available and worth paying for:
ProbeActionSet,ProbeBudget,CostToProbe,ValueOfInformation, andValueOfComputation; - what the current comparison concludes: one emitted
ChoiceResultthat says choose now, reject the current set, probe again, or reroute. That result must name either the selected option, the retained tie-set, or the next probe or reroute named by value.
Without that explicit tuple, choice doctrine usually collapses into one of three easier but wrong substitutes: generic rationality talk, search folklore, or planning folklore.
The finish condition is more specific than "the record now sounds informed." The record is finished enough for practical use only when the choice result follows from the stated comparison basis, stated ChoiceRule, stated probe decision value, and emitted ChoiceResult rather than from unstated background assumptions.
A C.11 pass is finished enough for practical use when all three conditions hold:
- the current comparison basis is explicit enough to state why one option now outranks or survives the others;
- the reason to stop probing, or the reason to probe again, is explicit rather than assumed;
- the next question is explicit:
choose now,reject current set,probe again, orreroute.
If the case remains tied or underdetermined under the current basis, say that directly and keep the tie-set explicit. A lawful ChoiceResult may still be probe again or reroute, but it must not pretend that one winner already exists when the current basis has not earned that conclusion.
If those conditions are still missing, the pattern has not yet answered the choice question even if the terminology already sounds sophisticated.
Archetypal Grounding
System grounding
Tell. A research team already has three experiment plans on the table. The option set exists. The real question is to decide which plan to run and whether one more measurement is worth the delay.
Show. The DecisionSubject is the team, the DecisionSubjectGranularity is team-level, the OptionSet is the three current plans, the team's PreferenceOrder puts risk reduction ahead of schedule convenience, and the current OutcomeModel still carries calibration uncertainty. The extra calibration run belongs in the ProbeActionSet, its one-day delay is part of the ProbeBudget, and the practical question is whether its ValueOfInformation exceeds its CostToProbe by enough to change the emitted ChoiceResult under the current ChoiceRule.
Show. If the extra calibration run could still change which plan survives and the one-day delay fits the remaining ProbeBudget, the right ChoiceResult is probe again with that exact calibration run named. If the measurement can no longer overturn the ranking, the right ChoiceResult is choose now with the winning plan and the reason further probing is no longer worth its cost.
Show. A finished result here should therefore read like one decision record, not one research-theory aside: "Team-level chooser; three current plans; risk reduction preferred; calibration uncertainty still live; one extra calibration run remains feasible and could still overturn the current ranking; ChoiceResult = probe again with calibration run." Or, after that probe is no longer worth doing: "ChoiceResult = choose plan B now because the remaining calibration gain no longer justifies one more day of delay."
Show. C.38 is the place for turning labels or fragments into complete ways of obtaining one result, C.18 is the place for open-ended invention of new plans, C.19 is the place for broader exploration policy over the plan pool, and C.24 is the place for the run sheet and execution order after the choice is made.
Episteme grounding
Tell. A model-selection comparison takes three already-articulated explanations and asks whether one more observation or one more comparison pass is rational before preferring one explanation over the others.
Show. C.11 governs the decision doctrine over the current explanation set: one BeliefState, one OutcomeModel, one explicit PreferenceOrder or EvaluativeMeasure, and, when the case needs it, one InterventionModel, CounterfactualModel, or SubjunctiveDependenceRelation rather than one thinner evidential comparison. When another model comparison pass is on the table, ValueOfComputation belongs here as part of the current choice doctrine rather than as one later planning afterthought.
Show. If one more comparison pass cannot realistically change which explanation survives, the decision record should not end with "more analysis may help." It should end with one ChoiceResult that prefers the current explanation now. If one more pass could still reverse the ordering and is cheap enough to justify, the decision record should say exactly which pass is worth doing and what ambiguity it is expected to resolve.
Show. A lawful closing line here is therefore something like: "ChoiceResult = choose model 2 now because the surviving uncertainty no longer changes the ordering under the current evidence" or "ChoiceResult = run one additional comparison pass on models 1 and 2 because the current outcome model still cannot distinguish their failure costs." Anything vaguer leaves the decision question unfinished.
Show. This pattern does not yet govern open-ended hypothesis generation and does not yet govern operational rollout. Those questions stay outside this pattern even when the decision later feeds them.
Collective and contextual grounding
Tell. A clinical board must decide whether to escalate a patient now or order one more test. The board is the chooser, not one isolated individual, and the result shifts when the case is discussed in prognosis-first versus risk-first order.
Show. C.11 keeps the case legible by typing the chooser as one DecisionSubject at explicit DecisionSubjectGranularity, keeping the available actions as one current OptionSet, keeping one explicit BeliefState and OutcomeModel around those actions, and asking whether another test belongs in the ProbeActionSet with enough expected value to justify its CostToProbe.
Show. Active-inference-adjacent pressure is visible because the chooser is embodied, online, and socially coupled; quantum-like pressure is visible because context and question order change the comparison state. C.11 keeps both repaired limitations visible without pretending that the whole pattern has already become one full active-inference or quantum-like formal package.
Show. If the order effect still changes which option survives, the comparison should say that directly and keep the comparison unfinished. The lawful choice result is then either one framing-stabilizing probe or one declared comparison order under which the current result will be judged. It should not hide that instability inside one vague statement that the board has mixed intuitions.
Show. An admissible output here therefore looks like one of three concrete records:
ChoiceResult = probe again with one rapid diagnostic test because the current prognosis-first versus risk-first framing still changes which option survives;ChoiceResult = choose now and escalate because, under the fixed risk-first order and current evidence, no remaining feasible test can reverse the survivor relation before delay increases harm;ChoiceResult = the next question is governed by C.24 because the board has already chosen escalation and the next task is now treatment sequencing rather than local choice.
Show. The output still has to be one actionable record. If the current result cannot say which of those three forms is now lawful, then the contextual pressure has been noticed but not yet carried into one usable decision result.
Bias-Annotation
This pattern is intentionally biased toward Prag and Onto/Epist discipline.
It prefers one clear decision-theory EntityOfConcern, one explicit neighboring-question split, and one minimal mathematical floor over one looser but more rhetorically flexible notion of rationality.
That bias can feel too strict in cases where the chooser, option set, or dependence structure is still genuinely moving. The mitigation is not to weaken the pattern back into one general rationality account. The mitigation is to keep the unfinished state explicit: hold one tie-set, hold one probe again result, or state the neighboring subject pattern that now truly governs the question.
The family map also remains plural: causal, success-first, active-inference, and quantum-like repairs stay visible without being overpromoted into one default doctrine.
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
One quick usability test helps here: if the closing line does not state one lawful choice result for the working chooser or team, the current result is still unfinished even if the doctrine survey looks polished.
Consequences
Rationale
A live option set and a live choice among that set are not the same question as generating options, governing a candidate pool, or sequencing execution. Keeping that distinction explicit is what makes the doctrine usable rather than ceremonial.
DecisionSubject is the better default chooser term because decision theory often applies to persons, teams, organizations, and other system-bearing collectivities. Agent remains useful, but only when an explicit agency claim is actually being made.
A minimal mathematical floor is necessary because choice doctrine without one stable object stack quickly turns into verbal drift. But a pattern also fails if it keeps only the object names and never shows how those objects discipline an actual choice. That is why Solution here is procedural: it must carry the path from OptionSet through one ChoiceRule to one ChoiceResult, including the stop-or-probe decision, rather than only one survey of neighboring theories.
The practical gain of that procedure is not elegance for its own sake. It is that later search, policy, publication, and planning work receive one explicit result instead of one hand-waving claim that deliberation happened somewhere upstream.
At the same time, this pattern should not pretend that one full quantum-like or geometry-heavy package is already settled just because those neighboring lines are real.
SoTA-Echoing
Practical reading of this alignment:
-
In ordinary current-option cases, start with the classical evidential baseline and use it to emit one explicit
choose now,probe again, orrerouteresult under one sharedBeliefStateandOutcomeModel. -
Failure of a simple Bayesian or passive-read-like model is not yet evidence that QL is necessary. Try richer classical, causal, performative, instrument, active-sensing, or representation-abstraction rivals before keeping the QL branch as load-bearing.
-
If intervention structure changes the survivor relation, state that explicitly and switch to causal comparison rather than leaving the comparison at the level of correlation talk.
-
If predictor-coupling or structurally linked choice procedures remain load-bearing, keep the subjunctive layer visible and say what linked structure could still reverse the current result.
-
If another measurement, comparison pass, or search pass is being considered, treat its value and cost as part of the current decision doctrine rather than as one later planning afterthought.
-
If the chooser is embodied, online, and socially coupled, or if context and order effects change the comparison state, keep those repaired limitations visible by naming the observation named by value, social-expectation clarification, order stabilization, response-replicability check, or measurement-class clarification that could still change the current
ChoiceResult, and say directly when fullerROE, quantum-like state-space, or multilevel doctrine still sits outside this local choice body. -
If the quantum-like line is activated, treat it as one measurement-sensitive mathematical lens or representational repair, not as one claim that the chooser or world is physically quantum.
-
If none of those heavier repaired limitations is live, stay with the lighter branch rather than activating one prestigious label that does not yet change the next action.
Worked-slice discipline from these rows:
- the system grounding slice is disciplined primarily by the bounded-resource and classical-baseline rows, so the output must end in one explicit probe-or-choose result;
- the episteme grounding slice is disciplined primarily by the bounded-resource and subjunctive-repair rows, so the output must say what comparison pass or predictor-coupled clarification could still reverse the result;
- the collective and contextual grounding slice is disciplined primarily by the active-inference and quantum-like rows, so the output must name the embodied observation, framing stabilization, or reroute that now becomes lawful.
Qualification and smallest reopen. The source uses above were checked on 2026-08-26. A newer publication does not by itself reopen C.11. Reopen only when it materially changes the current-option boundary, chooser, comparison basis, probe value or cost, or one branch-activation condition used by the Solution. Revise the affected source row and its matching procedure branch, worked slice, checklist item, or public entry cue; leave unrelated decision doctrine unchanged.
Relations
- Builds on:
A.6.P,A.6.5,A.10,A.13,A.18,A.19; coordinates with:E.10.LRNfor learning-word recovery,C.11.CRCfor a missing finite configuration-relative comparison claim,C.17for bounded characterization, and plannedC.9only as a future agency-characteristic-profile consolidation - Read next when this question leaves local choice:
C.38for forming complete ways of obtaining one result,C.18for open-ended candidate generation and reframing,C.19for one explicit pool-policy result over exploration or exploitation governance,C.24for one enactment-facing call plan orCheckpointReturn,G.5for the selector-facing result kind that is actually current—retained alternatives, all-member joint use, narrowed handoff, abstain, or escalation—andC.28when the choice result depends on causal-use support - Keeps outside: candidate generation, pool-wide exploration or exploitation policy, selector-facing set-result declaration, publication availability, and execution sequencing
- Aligns with: classical evidential decision theory, causal decision theory, success-first or subjunctive repair, bounded-resource metareasoning and probe-cost doctrine,
C.28causal-use question/rung/support vocabulary, active-inference-adjacent decision work, quantum-like contextual repair where context or order effects are real, and multilevel mathematical-lens pressure at the minimal-floor level only
Quantum-like choice-boundary note
Use C.11 first when the question is local choice, belief, preference, comparison, question order, option-menu framing, or an incompatible-question effect inside one decision situation. Quantum-like wording is retained only when it adds a concrete residual order-effect, probe, frame, or comparison reading that ordinary decision or probability language would hide.
Decision repair sequence:
- State the current
DecisionSubject,OptionSet, comparison basis, andChoiceRule. - Ask whether the apparent QL issue changes the local choice result: choose now, reject current set, probe again, or reframe the governing question.
- If the issue is question order, incompatible questions, response-replicability tension, non-shared comparison frames, or CbD-style variable identity / joint-availability trouble inside the current option set, keep the QL repair inside C.11.
- If the current option set itself is suspect, incomplete, generated by the wrong frame, or still needs expansion/reframing/search, leave C.11 and apply
C.18,C.19,A.19, orB.5.2as appropriate. - If the issue changes boundary state, bridge/export faithfulness, coordinated-work evidence, measurement admissibility, or viability envelope, apply the pattern governing that claim.
- Emit one
ChoiceResultand one next question; do not leave the QL branch as a theory label.
When the question leaves local choice, apply the subject pattern instead of stretching C.11:
Useful outputs:
choose nowunder a declared order/frame;probe againbecause another question order, response-replicability check, or frame test could still change the survivor relation;reroutebecause the live problem is no longer local choice;- no QL wording when ordinary uncertainty, preference conflict, or option-generation work is enough.
C.11 may cite C.26 as the common quantum-like modeling lens only for the residual question after the local-choice split is applied. It is not the whole-cluster pattern for boundary, bridge/export, distributed-evidence, viability, or state-representation coarsening claims.
C.29 mathematical-lens use relation
C.29may supply a lens-supported prediction, distinction, obstruction, diagnostic boundary, or rival-lens note that a decision record can cite. If the output is aChoiceResultor local choice record, useC.11to state and test the decision. AnyG.5selector-result declaration andG.9benchmark result remain separate. When one of those results must be available to an audience, useE.17for its source-backed publication face and return to source andE.24.PUBfor the publication occurrence and availability.C.29does not select the option by mathematical elegance.
C.11:End
Configuration-Relative Contribution Comparison
Tech name:
ConfigurationRelativeContributionComparisonPlain name: compare what this finite change adds to the current configuration
Type: C-pattern
Status: Stable
Placement: a narrow companion used before
C.11when its comparison basis is not yet available
Use This When
Use this pattern when a bounded addition, replacement, removal, intervention, experiment, information/computation acquisition, capability-development element, project, or component is being justified by “what it adds,” but the current configuration, interactions, resources, horizon, uncertainty, and receiving decision are not yet part of the comparison.
First useful result. Return one ordinary C.2.1 episteme that compares a realizable finite changed configuration with the current configuration under a declared basis. State the result coordinates and resource coordinates, interactions, uncertainty, option effects, unsupported overreads, and the C.11 decision that can consume the claim. The comparison does not choose the option.
Cheap exit. If a current A.19/C.11 account already states the same finite baseline, change, horizon, result and resource coordinates, interactions, uncertainty, and reopen condition, use that account directly.
Not this pattern when. Do not use it for a source-only comparison with no realizable configuration change; for a purely causal question under C.28; for a mathematical-lens question already answered by C.29 and a field Method; for an archive/front relation under C.18; or as a substitute for field-specific finance, optimization, operations, engineering, experimental-design, or capability-development calculation.
Problem Frame
Candidates are often described by an isolated score, average benefit, frequency, local gradient, shadow price, or expected information gain. The receiving decision concerns something else: whether a finite change is worthwhile from this current configuration, over this horizon, for these affected Systems, under these resource and authority constraints.
The same candidate can contribute differently when prerequisites, complements, substitutes, bottlenecks, thresholds, congestion, implementation capability, uncertainty, reversibility, and future options differ. A good isolated characteristic can therefore coexist with a dominated configuration change, and a weak-looking local result can preserve valuable options or reveal a critical blocker.
Problem
Without an explicit configuration-relative comparison, practitioners make at least six transfers:
- a finite change is approximated by a derivative outside its valid region;
- a shadow price for one active constraint is multiplied into the value of an asset that changes several constraints;
- a candidate is compared with an empty system instead of the actual current configuration;
- several result and resource coordinates are hidden inside one scalar;
- interaction and common-cause overlap are counted as independent contribution; and
- information, option value, or reversibility is treated as realized benefit.
A.19 provides comparison mechanisms and characteristic spaces, C.29 governs mathematical lenses, and C.11 makes the choice. The remaining recurring practitioner action is to construct the finite comparison claim that those patterns can consume.
Forces
Solution
Construct the smallest finite counterfactual comparison that can change one named decision.
- Name the receiving decision. State the deciding System, current
DecisionSubject, decision deadline, currentOptionSetor the option-set question that this comparison will inform, and which result could change the decision. - Freeze the current configuration. Name the actual or currently relied-on configuration
S0, system boundary, affected Systems, holder or beneficiary, relevant environment, and what is held fixed only for this comparison. If the affected-System coordinate is missing and could change the comparison, useA.1.CSDfirst; bring back only consequence claims compatible with thisS0/Δ/S1, horizon, evidence window, and receiving decision. A historical, empty, or ideal configuration is not the default baseline. - Name the finite change. State the addition, replacement, removal, intervention, or probe
Δ, the realizable candidate configurationS1, admissibility conditions, implementation capability, transition Work, reversibility, and excluded variants. - Fix horizon and scenarios. State the interval, relevant states or scenarios, timing assumptions, and any decision or evidence window. Do not combine results from incompatible horizons without an explicit mapping.
- Declare result coordinates. Name the result vector whose coordinates can change the decision and the protected coordinates that may not be silently scalarized. Include affected-System consequences and distributional differences when current.
- Declare resource coordinates. Name the action, transition, information-acquisition, computation, attention, capital, time, material, energy, authority, and other resources that the field case actually consumes. Keep costs of evaluating and realizing the change distinct.
- Recover constraints and interactions. State active and potentially activated constraints, complements, substitutes, thresholds, congestion, downstream effects, common causes, overlaps, and double-counting risks.
- Recover option effects. State whether the finite change opens, closes, delays, preserves, or makes irreversible later options. Keep information value and option value as decision inputs, not already realized operating results.
- Qualify evidence and uncertainty. Identify source claims, currentness, uncertainty, sensitivity/robustness results, transfer limits, rival explanations, and
A.10reliance dispositions where an evidence-bearing claim is used. - Write the comparison claim. State what
S1contributes relative toS0only under the declared coordinates, horizon, scenarios, constraints, interactions, and evidence. Use dominated, non-dominated, beneficial, harmful, or indeterminate wording only when the stated relation supports it; do not force one scalar winner. - Route mathematical near-misses. Apply the distinction in
C.11.CRC:4.2; the finite comparison may consume a derivative, sensitivity, shadow price, variational, or inference result without becoming identical to it. - Return to
C.11.C.11combines this claim with preferences, belief state, outcome model, probe worth, and other premises and emits oneChoiceResult. State the smallest configuration, horizon, evidence, resource, constraint, or option-set change that reopens this comparison.
Lightweight comparison form
ConfigurationRelativeContributionComparison@Context is a form name for one ordinary comparison episteme. It is not a root U-kind, universal delta value, selector result, or decision.
Omit a field only when it cannot change this comparison and that omission is apparent from the bounded case. A polished record cannot compensate for a missing current configuration or decision.
Mathematical and model-routing distinction
This is why calculus of variations matters without becoming the default interpretation of marginality. When the candidate is a whole trajectory, field, function, control, or shape, pointwise finite-coordinate reasoning can miss the coupled admissible deformation. C.29 governs the mapping from the world or domain model to that mathematical object, what structure is preserved or lost, and when the lens must stop. Specialist practice governs derivation, discretization, solver choice, optimality and sufficiency checks, and validation.
Recognition and assurance split
Recognition. A user can recognize a conforming comparison when S0, finite Δ, S1, boundary, horizon, result and resource coordinates, interactions, uncertainty, and receiving decision are visible.
Assurance. Trust in the numbers and relations remains separate. Field evidence must support the baseline and candidate behavior; implementation capability and transition Work must be credible; causal claims use C.28; source reliance uses A.10; material assurance uses B.3; authority and permission use their direct patterns. This pattern creates none of those results.
Worked Slices
Flood-pump modernization
The current station configuration FPS7-C19 supports bounded discharge use. A candidate bearing-temperature sensor is not compared with “no pump” or by its isolated diagnostic accuracy. The finite comparison uses FPS7-C19 as S0; sensor, placement, cabling, controller, maintenance access, calibration, and operating procedure changes as Δ; and the installed candidate as S1. Result coordinates include discharge continuity, failure detection, maintenance access, recoverability, and evidence continuity. Resource coordinates include outage time, installation Work, calibration, observation, and maintenance burden. The current result is indeterminate because placement and maintenance evidence are missing; another observed-load window can change the decision. C.11 therefore remains free to emit probe again rather than the comparison silently selecting the sensor.
Capability-development programme
Adding one pattern to a programme is compared with the person's current mastered and externally supported set, not with an empty curriculum. The comparison names target later Work, prerequisite complementarity, time to competent use, support dependence, critical-error detection, transfer and retention evidence, and future option value. A newly produced artifact or recent exercise-score gain can be evidence for a bounded claim, but neither is automatically the candidate element's capability contribution.
Operations constraint intervention
A positive shadow price for one bottleneck supports a local statement about relaxing the formulated active constraint. A finite machine addition also changes labor, maintenance, setup, downstream capacity, energy, resilience, and perhaps the active constraint. The S0/S1 comparison can therefore disagree with shadow-price multiplication without making the shadow price useless.
Capital allocation
A project is compared with the current portfolio and financing/operating configuration. The comparison includes cannibalization, shared resources, risk concentration, financing constraints, irreversibility, staging, information gained before later commitments, and displaced options. NPV, real-options, scenario, and portfolio Methods remain Corporate Finance practice; this pattern supplies only the finite comparison grammar returned to C.11.
Bias Annotation
- Scalar bias: do not hide protected coordinates or distributional effects inside one score.
- Smoothness bias: do not replace a realizable finite change with a derivative outside its validity region.
- Additivity bias: inspect complements, substitutes, overlap, thresholds, congestion, and common causes.
- Empty-baseline bias: start from the actual current configuration unless another baseline is explicitly the decision subject.
- Physics-prestige bias: a variational or thermodynamic form does not establish a physical mechanism or decision authority.
- Information-as-result bias: expected information and option value are inputs to choice, not already realized target-System benefit.
Conformance Checklist
- Is one receiving decision named?
- Are
S0, finiteΔ, and realizableS1explicit? - Are system boundary, affected Systems, horizon, scenarios, and evidence window compatible—and, when a missing bearer could change the comparison, was
A.1.CSDused before freezing this coordinate? - Are result and resource coordinates explicit, with protected coordinates not silently scalarized?
- Are implementation capability, transition Work, reversibility, and excluded variants recoverable?
- Are constraints, interactions, overlap, thresholds, congestion, and downstream effects considered where material?
- Are future option effects distinguished from realized results?
- Are evidence, uncertainty, sensitivity/robustness, transfer limits, and unsupported overreads visible?
- Is each derivative, sensitivity, shadow-price, functional-variation, variational-inference, or evolutionary-variation result used only for its exact question?
- Does the output remain a comparison claim, with
C.11retaining theChoiceResult? - Is the smallest reopen condition stated?
Common Anti-Patterns and Repairs
Consequences and Reopen Condition
Benefits. Finite additions, removals, replacements, probes, and investments become comparable without requiring additivity, smoothness, or a universal scalar. Domain calculations can be reused while their validity regions remain visible. The result gives C.11 a stable comparison input and keeps choice authority there.
Costs. Practitioners must name a baseline, vectors, interactions, and uncertainty that an isolated score could hide. Some cases remain indeterminate until field evidence or implementation capability is available.
Reopen this pattern when repeated cases cannot express their finite comparison with this spine; when a current A.19/C.11 composition fully absorbs the same practitioner entry, action, first result, and stop; or when a mathematical branch requires a different transdisciplinary action rather than a field-specific Method.
Rationale
The pattern is narrow because its result is neither a new value ontology nor a decision. The reusable action is to construct a finite configuration-relative claim before local choice. A.19 remains the comparison-mechanism owner, C.29 the mathematical-lens owner, and C.11 the choice owner.
The selected name follows F.18. Marginal contribution decision conflates finite difference, derivative, economic terminology, and the later decision; marginal value encourages one scalar; sensitivity analysis names a different question. Configuration-Relative Contribution Comparison names the reference configuration and comparison while leaving domain quantities and choice outside.
SoTA Echoing
Refresh only the affected source-use row when a newer result changes one Solution distinction or shows that a field-independent method can replace it. Older mathematical anchors remain historical where current work has repaired their limits.
Relations
- Builds on:
C.2.1,A.10,A.19,C.16,C.27,C.28, andC.29. - Supplies: one finite comparison claim to
C.11; it can also supply an input to a field-specific portfolio, programme, intervention, architecture, or experiment decision. - Coordinates with:
A.1.CSDwhen affected-System consequence coordinates are missing;C.18when the candidate changes the possibility space;C.19for pool governance;B.3for assurance; A.15 for transition Work; and the direct field practice for calculation and validation. - Keeps outside: universal marginal value, a new delta kind, domain formulas and thresholds, causal proof, assurance, permission, selected-set declaration, and
ChoiceResult.
C.11.CRC:End
C.13 — Constructional Mereology (Compose‑CAL)
Status: Stable Type: Pattern
At a glance. Use C.13 when a practitioner must show how identified entities and relations that obtain form one whole, collection, or aspect. The account explains how those facts support the whole, collection, or aspect; writing a sum, set, or slice expression does not create the entities or relations.
Use this when. Use this pattern after the direct relation patterns have identified the participants and relations that obtain, when you need a compact, inspectable account of how they assemble a whole, form a collection, or distinguish an aspect.
First useful move. Name the whole, collection, or aspect whose construction you must explain; then name its inputs, the constructive part relations or the collection's own belongs-to relations, and the rule by which those facts form it. Choose sum, set, or slice as the shortest truthful construction narrative.
What goes wrong if missed. A readable component, belongs-to, or aspect statement may lack its construction account; or the opposite mistake occurs and a diagram, list, or Γ_m expression is treated as if it created a whole, a relation, or a holon.
What this buys. A compact three-form construction discipline that keeps integrated assembly, collection, and aspect distinct while leaving relation conditions, whole identity, evidence, and public relation names with the patterns that define them.
Not this pattern when. Not this pattern when the current question is only relation vocabulary, evidence or assurance without a structural claim, epistemic representation, a selected dependent U.Structure, temporal phase without an aspect claim, public-kind admission, or transformation composition without a direct transformation-composition governor.
Intent
Provide one minimal calculus for narrating three kinds of construction: how constituents assemble an integrated whole, how entities form a collection under that collection's own belongs-to rule, and how a bearer is distinguished under one facet as an aspect. The calculus records how already identified entities and obtaining relations support that named whole, collection, or aspect. It is not a second source of relation obtaining and does not make any of them exist by notation.
Also known as “Γₘ mereology” and “constructor-based composition”.
Layer. calculus. Depends on. A.14 and the direct relation patterns for participants, obtaining conditions, and occurrence identity; the direct kind pattern for the candidate whole and its identity or reidentification rule. Consumed by. A.1 when candidate holon recognition needs constructive assembly, B.3.5 when a named assurance use needs a structural grounding account, and subject patterns that need a compact construction narrative.
Compose-CAL keeps exactly three narrative forms—sum, set, and slice. A materialized construction trace is a C.2.1 episteme about the construction facts. Its claims can designate entities, relation occurrences, rules, and identity conditions; the trace is neither the whole, collection, or aspect it describes nor a participant in the world-side relations.
Problem Frame
FPF needs both readable structural relations and a recoverable account of how constituents assemble a whole, entities form a collection under its belongs-to rule, or a facet distinguishes an aspect. A relation name alone may leave the construction opaque. A constructor expression alone can commit the opposite error by treating syntax as the source of entities, relation obtaining, or whole identity.
Problem
A bare list of ComponentOf, collection-specific belongs-to, or AspectOf claims does not say which assembly, collection rule, or facet makes them one construction. But a bare sum, set, or slice expression is no better: the same constituents can participate in different assemblies, a collection need not be an integrated holon, and an arbitrary facet label does not establish an aspect. The construction account must therefore name world-side facts and preserve the candidate's direct identity or reidentification rule.
Forces
- Parsimony vs truth. Three construction forms are easier to reuse than an open constructor catalogue, but no form may replace a missing direct relation or assembly rule.
- Readable statement vs constructive account. Practitioners need ordinary component, belongs-to, and aspect statements; reviewers may also need to inspect how those relations support the named whole, collection, or aspect.
- Input set vs assembly. The same entities can be assembled through different obtaining relations and can therefore yield different wholes.
- Continuity vs extensional snapshots. Constituents and part-relation occurrences can change while the same whole continues when its direct reidentification rule permits the phase change.
- Construction vs evidence. A trace states the construction account; evidence and assurance separately support or warrant the claim content.
- Cross-domain reuse vs owner bypass. Systems, epistemes, methods, and work occurrences can all need constructive grounding, but their direct patterns retain kind, part, and identity authority.
Solution
Solution sketch
Use the coarsest of three construction narratives that fits the named whole, collection, or aspect. In each case, write the shorthand only after the required facts are recoverable.
The familiar argument lists are readable shorthand, not complete ontological signatures. A complete use names the whole, collection, or aspect and states the direct facts beside the shorthand. Input order does not matter to the list of designated inputs, but assembly relations, rules, facets, and identity conditions do matter. The same input set under a different assembly can yield another whole.
A construction may obtain in the world even when no trace episteme has been written. When another piece of work needs an inspectable trace, materialize a C.2.1 episteme whose claim content names the whole, collection, or aspect; its constituents, entities that belong, or bearer; the relation occurrences that obtain; the construction rule; and the identity conditions. Creating, editing, publishing, or losing that episteme changes the account or its availability, not the past or present construction facts.
Do not add a fourth constructor merely to carry time, execution order, parallelism, representation, evidence, or a domain label. Keep those claims with their direct patterns beside the construction account.
Normative Standard (high‑level)
- C13-N1 — Direct facts first. A C.13 trace is conformant only when every named constituent or collection entity and every named part, collection-belonging, or aspect occurrence is independently identified under its direct pattern.
- C13-N2 — Whole identity stays direct. The candidate whole follows its direct identity and reidentification rule. Equality of an input list or trace does not decide whether the existing whole continues or a new whole must be identified; a permitted constituent replacement can preserve one whole, while the same constituents under another assembly can form another whole.
- C13-N3 — Construction form.
sum,set, andsliceare the only C.13 forms. Reordering or duplicate designation does not change the listed inputs; it does not merge distinct entities or relation occurrences and does not erase assembly or facet differences. - C13-N4 — Mereological discipline. Direct part patterns and A.14 govern acyclicity, antisymmetry, transitivity where applicable, recurrence, and occurrence identity. C.13 does not strengthen a direct relation by calculus convention.
- C13-N5 — Trace separation. A materialized trace is a C.2.1 episteme. It creates none of the following: the whole, collection, or aspect it describes; the inputs; the relation occurrences; the construction rule; the identity conditions; or holonhood.
- C13-N6 — A collection account is not component assembly.
setsupports a collection account; it does not imply integrated assembly,ComponentOf, system agency, or A.1 recognition. Usesumonly when constructive part relations and assembly are independently grounded. - C13-N7 — Elected assurance grounding stays with B.3.5. A direct structural Working-Model edge may be published without a C.13 trace. When that publication elects B.3.5 or a named current requirement demands the profile, follow B.3.5 for the required
tv:groundedBylink and declaredvalidationMode; C.13 supplies the reconstructible trace content. Evidence, warrant, currentness, and reliance remain separate, and neither the link nor the mode replaces the direct construction or identity facts. - C13-N8 — Subject owners remain authoritative. Method, work, and discipline construction may use C.13 only after their direct patterns identify actual parts and whole-forming relations. A selected dependent
U.Structuredoes not become a whole, collection, aspect, or holon by selection or name. - C13-N9 — Transformation composition stays fail-closed. A C.13 entity-construction trace, method decomposition, work decomposition, common changed referent, or temporal subdivision establishes neither transformation parthood nor a composite transformation. Without a direct transformation-composition governor, retain the independently identified changes and the exact blocker; infer neither composition nor atomism.
Scope, applicability, terms & notation
Use Compose-CAL when the current claim concerns the construction of one exact system, episteme, method, work occurrence, discipline, collection, or aspect and its direct part patterns already supply the required participants and obtaining relations. Do not apply it merely because a sentence contains part, a diagram groups nodes, or a selected structure organizes relations.
Γ_m— the three-form notation for a C.13 construction narrative.- construction trace — claim content that names the whole, collection, or aspect; its inputs; the direct relations that obtain; its construction rule; and its identity conditions; when materialized, it is a C.2.1 episteme.
- constructive part relation — an exact world-side relation occurrence governed by its direct pattern; it is designated by the trace but not created by it.
- assembly rule or method — the rule by which the named constituents assemble the whole, the members form the collection, or the bearer and facet distinguish the aspect; a rule-description episteme is not the assembly, collection, or aspect itself.
- identity or reidentification rule — the direct rule that identifies the whole, collection, or aspect and says which changes preserve or end it.
Alias readiness. These are common readable projections only when their direct relation meanings match the case:
ComponentOfmay accompany asumconstruction;- an ordinary belongs-to sentence may accompany a
setconstruction; the collection's own pattern supplies its meaning, occurrence history, and any recurrence rule; AspectOfmay accompany asliceconstruction;PortionOfneeds the direct portion relation and metrical semantics in A.14, not a facet spelling alone;ConstituentOfneeds the direct logical or content-part relation; material mixtures use their exact portion or component owner.
The readable label and the trace answer different questions. The label states which direct relation obtains; the trace explains how the exact relation set supports this construction. Neither one is evidence merely by being present.
Structural CT2R Typing-Grounding Use
When a target kind or logical representation must reuse both a Γ_m construction account and an independently grounded Working-Model relation, use StructuralCT2RTypingGroundingUnfoldingStructureBlock from B.3.5. C.13 contributes the account of the subject-side relations that actually obtain and states which mereological structure the target preserves or loses inside that B.3.5-governed local A.22.CGUS structure specialization. C.13 does not create separate unfolding-structure authority and does not by itself supply a bridge, kind intent, proof, empirical evidence, or admissible reuse. Apply A.7.1, rather than this structural CT2R block, when an inadequate working account must be diagnosed against the subject construction.
Use this split especially when a readable relation label such as ComponentOf, a collection's belongs-to predicate, AspectOf, ConstituentOf, or RepresentationOf is being reused beyond what its sentence warrants. The label does not by itself prove constructive grounding or a wider structural projection. Name the construction trace and Working-Model relation, the target kind or logical representation, any bridge used, the structure preserved and collapsed, and the proof or evidence relation required by the stronger claim. If the evidence instead diagnoses a mismatch that requires revision of the working ontology, apply A.7.1.
Archetypal Grounding
Pump Skid: Integrated Assembly, Not A Parts List
PumpSkid #7 is assembled from exact Pump, Motor, Baseframe, Manifold, enclosure, pipe, cable, and connector entities. The direct mechanical, electrical, and fluid part-relation patterns identify the exact fastening, coupling, enclosure, terminal, flange, and seal occurrences. The skid assembly method or rule states how those facts form the candidate, and the skid reidentification rule says which replacements preserve PumpSkid #7.
The shorthand Γ_m.sum{Pump, Motor, Baseframe, Manifold, ...} is truthful only with those facts beside it. It records an integrated-assembly construction; it does not make the relations obtain. The composition sustains skid-level boundary, interface, load-envelope, and operating characteristics not attributable to one constituent alone.
The same parts unconnected on a pallet do not form the skid. A bill of materials and drawing are epistemes about intended or possible assembly. They do not substitute for actual part relations, assembly, or identity. The same part set connected under a different governed assembly may constitute another whole.
Collection And Aspect
A fleet register can identify one collection and the vehicles that belong to it under the registration rule. Γ_m.set{Vehicle-1, Vehicle-2, ...} reports that collection only after the fleet identity, registration rule, and each belongs-to fact have been established. It creates neither the fleet nor those facts. It establishes no vehicle integration, constructive parthood, collective agency, acting system, or A.1 holonhood. If the same candidate later passes all six A.1 matters, a separate sum account may report its independently grounded constructive parts and assembly.
Reuse the filled Reactor-7 case in A.14:5.3: Γ_m.slice(Reactor-7, thermal-boundary) reports ThermalEnvelope-7, the insulation panels, seals, and boundary interfaces picked out by the thermal-boundary rule, the obtaining AspectOf occurrence, and the enclosure identity and ending conditions. A permitted panel replacement can preserve the aspect while requiring a current trace; dismantling the enclosure, changing the facet rule, or reidentifying Reactor-7 ends the reported occurrence. The slice reports these facts and creates none of them. A dashboard view, selected concern, or time window is not that aspect by display.
Episteme, Method, Work, And Discipline Holons
A theory episteme may use C.13 only after C.2.1 identifies the episteme and an exact direct episteme-part or claim-composition pattern identifies the constituent entities, the part relations that obtain, and the assembly and reidentification rule. C.2.1 claim-graph content helps constitute the episteme but does not thereby supply a C.13 part predicate. A definition, derivation, diagram, representation, publication, or evidence relation likewise does not become a part merely because it states, shows, publishes, or supports the theory; include it in a sum trace only when an exact direct part predicate independently obtains. The trace then reports the claim-bearing assembly rather than creating it.
A composite method may use C.13 after B.1.5 or another direct method-composition pattern identifies exact submethods, whole-forming relations, constraints, and the whole-method reidentification rule. A dated work occurrence may use C.13 only after the direct work-mereology owner identifies exact work parts and whole-forming relations. Step labels, a recipe, work-plan items, a WBS, co-occurrence, or common performer do not supply those facts.
A discipline may use C.13 only after C.20 and its direct relation owners identify whatever constituent entities the case actually requires, the whole-forming relations that obtain among them, and the discipline identity or reidentification rule. Do not infer parts from C.20 card positions or from objects merely associated with the discipline. A canon item, practice, organization, carrier, bridge, comparison relation, field name, bibliography, curriculum, or publication collection enters a sum trace only when an exact direct part predicate independently obtains.
Selected Structure And Transformation Stops
A selected BoundedModelUseStructure organizes exact model-use relations for a use. Selection does not give the dependent structure constituents, parthood, agency, holonhood, or an MHT. C.13 can discuss construction of an underlying system, episteme, method, or work whole when its direct facts are available; it does not turn the selected relation organization into that whole.
Mounting, wiring, fluid-connection, and configuration changes may each be independently identified U.Transformation occurrences. A skid entity-construction trace does not make those changes constituents of one composite transformation. If a use requires transformation contribution, parthood, composite identity, or holonhood and no direct governor supplies the relevant compatibility and reidentification law, retain the separate changes and the exact blocker. Missing composition facts establish neither composition nor indivisibility.
Scope Justification
The same three forms work across mechanical, biological, informational, Method, Work, and Discipline cases because they keep three questions apart: integrated assembly, collection belonging, and aspect distinction. Using them does not replace the patterns that define the particular entities and relations. Order and timing remain with Method and temporal patterns; evidence and warrant remain with assurance patterns; public kind admission remains with E.24.UK; the direct identity rule decides whether the existing whole continues or a new whole must be identified, with B.2 used when reidentification is current.
Bias-Annotation (cognitive anti-patterns and counter-moves)
Conformance Checklist (normative, calculus‑level)
The following regulate a C.13 use.
Common Anti-Patterns and How to Avoid Them
- Constructor as public relation. A
Γ_mtrace is shown as the relation the working reader should use. Keep the exact direct relation in ordinary prose and use the trace only for the construction account. - Trace as cause. A diagram, formula, parts list, or trace publication is said to create the assembly. Recover the actual inputs, obtaining relations, assembly, and identity rule.
- Item in a collection treated as a component. A
setconstruction is used to infer integrated assembly structure. Keep collection belonging distinct; usesumonly after constructive part relations and assembly independently obtain. - Same parts, same whole. Two assemblies with the same component names are treated as one whole. Compare their obtaining relations, assembly rules, boundaries, and identity conditions.
- Temporal constructor drift. A phase, schedule, or assembly order is modeled as a Compose-CAL constructor. Keep temporal and method claims in their own planes.
- Method or work shortcut. Recipe steps, plan items, or WBS rows are called parts of an actual method or work occurrence. Use the direct method- or work-composition owner first.
- Transformation shortcut. Changes of constituents are called parts of one transformation because the entity was assembled. Return the exact missing transformation-composition governor and retain the separately identified changes.
Consequences
Benefits
- Inspectable construction. A practitioner can recover which exact inputs, relations, and rule support one assembly, collection, or aspect.
- Identity clarity. The account distinguishes the input list from the assembly and keeps whole reidentification with the direct identity rule.
- Human-first use. Ordinary ComponentOf, belongs-to, and AspectOf sentences remain readable; notation is optional shorthand for a named construction use.
- Plane separation. Order, time, evidence, representation, kind admission, and receiving reliance keep their direct owners.
- Cross-domain reuse. The same three forms can describe system, episteme, method, work, discipline, collection, and aspect cases without claiming one universal part relation.
- Truthful stops. Missing direct part or transformation-composition governors remain visible instead of being hidden by a trace.
Costs and mitigations
- A truthful trace needs more than a parts list: exact relations, assembly, and identity conditions must be named. Reuse a direct pattern's existing facts rather than duplicating them.
- A world-side construction can obtain before anyone writes a trace, and its direct relation claim can remain usable without an assurance profile. When its publication elects B.3.5 or a named current requirement demands it, materialize the required trace and validation mode without treating publication as the cause of construction.
- The same inputs can support different assemblies, and one whole can survive permitted replacements. Always carry the direct reidentification rule.
One-line takeaway.
sum,set, andsliceexplain an already grounded construction; they do not create its entities, relations, identity, evidence, or holonhood.
Rationale (informative)
Why exactly three forms?
sum, set, and slice keep three recurring practitioner questions apart:
sumasks how exact constituents and constructive relations assemble an integrated whole;setasks which entities belong to a collection under that collection's identity and belongs-to rule;sliceasks which exact aspect is distinguished from one bearer under a governed facet.
The forms are intentionally small, but their inputs do not determine ontology by themselves. An assembly is more than a set of part names; a collection is not automatically a holon or agent; and a facet label is not an aspect occurrence. The direct patterns provide relation obtaining and occurrence identity, while the candidate's direct pattern decides whether the existing whole continues or a new whole must be identified.
Why traces remain epistemic. A construction can obtain before anyone writes its account. A materialized trace is claim-bearing content used to inspect, communicate, or support that account. Evidence and assurance may warrant the claim, G.11 may govern the selected edition's currentness, and receiving work may rely or decline. None of those epistemic results changes the world-side assembly by itself.
Why order, time, selected structure, and transformation composition are outside. Method order and temporal extent answer different questions from parthood. A selected U.Structure is an organization of relations for a use, not automatically another holon. Entity construction also supplies no law by which several actual changes compose into one transformation. Keeping these stops explicit prevents an economical notation from becoming an ungoverned ontology.
SoTA-Echoing
Constructional ontology and applied mereology both require explicit choices about constructors, dependence, identity, and the relation between a construction account and the object constructed. C.13 adopts that pressure by requiring exact inputs, obtaining direct relations, assembly, and reidentification. It rejects the stronger shortcut that a term, graph, extensional input set, or written constructor expression alone settles the existence or identity of the whole.
Model-based engineering likewise separates a readable structural model from the physical, operational, informational, method, or work organization it describes. C.13 keeps that model useful while routing representation, evidence, assurance, and currentness to their direct patterns.
A.14:14 supplies the source decision used by the changed set and slice forms. For set, it requires the collection's own belongs-to rule and blocks both automatic parthood and the conclusion that separate parthood is impossible. For slice, it requires an obtaining AspectOf relation with its bearer, facet rule, and identity conditions; a Characteristic, view, projection, partition, or time window does not substitute. If that A.14 source account changes, recheck only the affected set or slice contract, normative row, and link to A.14 here. An ordinary change to a collection rule or occurrence, aspect or bearer, facet rule, identity condition, or materialized trace reopens only that construction account and the claim it reports.
Relations
Builds on
- A.14 and the patterns for each relation. They define and test the participants, conditions, recurrence, and occurrence identity for component, collection-specific belongs-to, aspect, portion, constituent, and other constructive relations.
- C.2.1. It governs the identity of a materialized construction-trace episteme.
Coordinates with
- B.3.5. Governs the required trace link and validation mode only for a structural Working-Model edge covered by an elected profile or named current requirement. Its publication and assurance apparatus does not create the construction or decide whole identity.
- A.1 and B.2. A.1 consumes constructive assembly as one component of holon recognition; B.2 consumes exact construction and direct reidentification facts when the question is whether the existing whole continues or a new whole must be identified. C.13 decides neither public-kind recognition nor whole reidentification.
- B.1.5 and direct method-composition patterns. Supply exact submethods, whole-forming relations, constraints, and whole-method reidentification before a method construction is narrated.
- A.15 and direct work-mereology patterns. Supply exact work parts and whole-forming relations before a dated work construction is narrated.
- C.20 and direct discipline-composition relations. Supply exact discipline constituents, whole-forming relations, and identity conditions before a discipline construction is narrated.
- A.22 and A.1.1. Keep selected relation organization and bounded model use distinct from construction of the underlying holon.
- A.3.4. Identifies each actual bounded change independently; C.13 supplies no transformation-composition law.
- C.29. Keeps formulas, graphs, diagrams, and traces as representations of independently recovered objects when representation is current.
- A.7.1 and A.22.CGUS. Handle diagnostic return and the wider structural projection from construction to a target kind or logical representation when those uses are current.
Constrains
- A pattern that relies on a constructive whole states that whole, its constituents, the part relations that obtain, the assembly rule, and the identity rule rather than relying on a list or diagram.
- Collection, aspect, method, work, discipline, selected-structure, and transformation cases keep their direct owners and stop at missing governors.
- New construction forms require a separate parsimony and use argument; ordinary time, order, evidence, representation, and domain labels do not justify one.
Provides
- the three construction narratives
Γ_m.sum,Γ_m.set, andΓ_m.slice; - a plain-language discipline for connecting those narratives to exact direct facts without making the trace their cause;
- explicit unassembled-collection, selected-structure, existing-whole continuity or new-whole identification, and transformation-composition stop conditions.
C.13:End
Measurement & Metrics Characterization (MM‑CHR)
Status: Stable Type: Pattern
Use this pattern when. Use C.16 when a value, sensor indication, score, rating, dashboard reading, or comparison is being treated as a measurement without a recoverable measurand, Characteristic, Scale, method, model, calibration basis, dated work, attributed value, uncertainty, time stance, or comparability basis.
What goes wrong if missed. Raw output, indication, actual subject state, measurement result, diagnosis, and criterion verdict collapse into one number; model and calibration assumptions disappear; uncertainty is laundered away; and a dashboard or evidence link is mistaken for work, result, assurance, or decision authority.
What this buys. One executable measurement account: exact measurand or subject, Characteristic and Scale, Unit and polarity when current, method, model, calibration, input and output quantities, uncertainty propagation, dated work with actual bindings, one measurement result, one C.2.1 result episteme, and bounded provenance and later use.
Intent (Normative)
Name. Measurement & Metrics Characterization (MM‑CHR).
Use this when. Use C.16 when a reading, score, rating, sensor indication, dashboard value, or claimed comparison must be made interpretable as a measurement. The working question is: what exact subject or measurand was measured, for which Characteristic and Scale, by which method and model, under which calibration and time stance, with what attributed value and uncertainty?
What changes in practice. Instead of carrying a number and a source link, the practitioner recovers a complete measurement chain: reusable specification, exact measurand, method, model, calibration basis, input and output quantities, dated measurement work, direct bindings, measurement result, one result episteme, and provenance. A reader can then tell what the reading supports and what still requires a diagnostic, criterion, assurance, causal, acceptance, or decision pattern.
Not this pattern when. Use A.17 for the Characteristic, A.18 for scale-operation legality, C.16.P while measurement wording is still ambiguous, A.19 for comparison or selection, C.28 for causal use, A.10/G.6 for provenance, B.3 for assurance, G.4 for an acceptance declaration, G.11 for currentness, and C.11 for a decision result. C.16 supplies none of those results by implication.
Local designators. MeasurementSpecification, MeasurementMethod, MeasurementModel, MeasurementWork, MeasurementResult, and MeasurementResultEpisteme name exact objects in one case; they are not new public U-kinds or universal relation types. MeasurementMethod is one exact U.Method; MeasurementWork is one dated U.Work; MeasurementResultEpisteme is one C.2.1 episteme.
Compatibility with the retained measurement family. U.DHCMethod remains the durable measurement-definition value that fixes the Characteristic, Scale, unit and polarity and cites the exact method and model. U.Measure remains the durable reading claim: when persisted, it is the C.2.1 result episteme that states the C.16 measurement result. U.Unit carries quantity-kind and conversion semantics when the Scale requires them. U.EvidenceStub is only a compact locator into A.10/G.6 provenance; it is not the measurement result, an evidence carrier, a work record, or a relation that establishes measurement.
Scope and result boundary (Normative)
C.16 governs the measurement-specific result algebra:
- one measurand or otherwise exact measurement subject;
- one Characteristic and one Scale, with Level or Coordinate and Unit when applicable;
- the reusable measurement specification, exact
U.Method, measurement model, calibration requirements, and uncertainty treatment; - dated measurement work with performer, actual bindings, resources, and time stance;
- the value or set of values attributed to the measurand together with relevant information, including uncertainty and interpretation basis; and
- direct comparability within the declared basis.
C.16 does not turn an instrument message, file, dashboard tile, ledger row, or evidence citation into a measurement result. It does not own the actual subject state, diagnosis, criterion verdict, acceptance action, assurance claim, causal conclusion, or decision. It introduces no universal measurement-result, work-result, evidence-use, common-scale, or criterion-participant relation.
Problem Frame
A measurement is often compressed to subject → value. That abbreviation hides the measurand, the quantity or characteristic intended to be measured, the model relating inputs to an output quantity, the calibration basis, the work occurrence, and the uncertainty carried into later use. It also makes raw instrument output, a displayed indication, an attributed measurement result, a diagnostic interpretation, and a criterion verdict look like one object.
The failure becomes visible when two readings are compared, when a detector output is treated as the state of the subject, or when a dashboard value is reused as evidence, assurance, acceptance, or decision authority. C.16 restores the measurement-specific objects before any receiving use is judged.
Forces
- Interpretability vs convenience. A compact value is easy to carry; a usable result needs its measurand, Characteristic, Scale, model, calibration, uncertainty, and time stance.
- Model dependence vs objectivity rhetoric. Measurement may use corrections, calibration coefficients, influence quantities, and inference. Hiding them does not make the result more direct.
- Cross-domain reuse vs scale coercion. Physics, software quality, architecture, survey, and judging cases need common discipline without one common scale.
- Repeatability vs occurrence identity. A reusable method and operation declaration do not establish that measurement work occurred or that actual participants were bound.
- Result vs later interpretation. A value attributed to a measurand is not by itself a diagnosis, conformance verdict, causal conclusion, assurance claim, or decision.
Solution — recover one complete measurement chain (Normative)
Start with one ordinary direct sentence:
Dated measurement work
Wapplied methodMto measurandx, using modelf, calibration basisK, and actual input bindingsX, and obtained output quantity valueywith stated uncertaintyu; epistemeEstates that measurement result under its declared Characteristic, Scale, unit, time stance, and interpretation basis.
If any noun in that sentence cannot be grounded, return that exact gap rather than filling it with a generic result or evidence relation.
Name the measurand and measurement subject
M‑SUB‑1. Name the measurand: the quantity or characteristic intended to be measured. When FPF uses a non-quantity Characteristic, name the exact subject and the Characteristic whose Scale position is being attributed.
M‑SUB‑2. Preserve arity. An entity Characteristic has one subject; a relation Characteristic has the exact ordered or unordered tuple required by A.17. A relation reading is not silently rewritten as a unary property of one participant.
M‑SUB‑3. Distinguish the measurand from the actual subject state. A measurement result attributes values under a method and model; it does not make the physical, social, architectural, or epistemic state identical to the result episteme.
Fix Characteristic, Scale, unit, polarity, and time stance
M‑CSLC‑1. One U.DHCMethod binds exactly one Characteristic to exactly one Scale. A discrete reading names its Level; another reading names its Coordinate or value on that Scale.
M‑CSLC‑2. When units apply, name the quantity kind and presentation Unit. Conversions are admissible only when they preserve the quantity kind and the Scale supports the operation. Nominal and ordinal labels do not acquire interval or ratio arithmetic by being encoded as numbers.
M‑CSLC‑3. An ordered Scale declares polarity: higher-is-better, lower-is-better, or target-is-best. Polarity guides later interpretation; it is not an acceptance criterion or decision rule.
M‑CSLC‑4. State the time stance: instantaneous or as-observed at T, aggregated over window W, or another exact temporal basis. A later value does not silently replace an earlier result.
Separate method, description, model, calibration, and work
M‑METH‑1. MeasurementMethod is one exact U.Method. Its U.MethodDescription may state generic participants, parameters, effects, and measurement conditions; it contains no actual-participant slots and does not claim that measurement occurred.
M‑MODEL‑1. MeasurementModel states how input quantities and influence quantities determine or constrain the output quantity. It names the model edition, assumptions, corrections, and domain of validity. A formula, software function, or signature is only a representation or declaration of that model until its exact governed object is recovered.
M‑CAL‑1. Name the calibration basis required for the use: reference standard or comparison basis, dated calibration work and result when current, calibration coefficients or corrections, applicable interval, and uncertainty contribution. A calibration certificate or ledger row cites these facts; it does not establish them by being stored.
M‑WORK‑1. MeasurementWork is one exact dated U.Work. First recover every actual performer's A.13 core for the measurement action, including the same obtaining assignment; then independently admit the Work under A.15.1 from its performance history, at least one obtaining enactsMethod relation, temporal extent, and at least one obtaining locally declared containing-system relation. Add F.6 afterward only when the measurement claim also needs precise assignment-bound attribution. Name the exact measurand through its direct subject relation or an A.6.1 operation-application binding. Name another enacted Method, resource, or concrete participant only when the measurement claim uses its independently obtaining relation or binding. A plan, compatible signature, method description, instrument type, or retained reference establishes none of those actual facts.
Recover input quantities, output quantity, and uncertainty
M‑IO‑1. Name each actual input quantity used by the model, including indications, repeated observations, environmental or other influence quantities, reference values, calibration coefficients, and applied corrections when current. Name the exact output quantity whose value is attributed to the measurand. These are measurement-model roles, not a universal work input-output ontology.
M‑UNC‑1. State the uncertainty associated with the attributed value or values whenever it affects interpretation or use. Identify the contributing input uncertainties, correlations or covariance when relevant, propagation method, coverage or interval interpretation, and significant model inadequacy. An uncertainty number without its interpretation is not complete.
M‑UNC‑2. Propagation follows the declared measurement model. Linearized propagation, sampling, interval, set-valued, or another method is admissible only under its own assumptions. Combining provenance pointers is not uncertainty propagation, and more cited grounds do not monotonically guarantee lower uncertainty.
State one measurement result and one result episteme
M‑RES‑1. MeasurementResult is the value or set of values attributed to the measurand together with relevant information needed to interpret them. At minimum, recover the measurand, Characteristic, Scale, attributed value or values, Unit when relevant, uncertainty, method, model, calibration basis, time stance, and exact measurement work.
M‑RES‑2. MeasurementResultEpisteme is one exact C.2.1 episteme. Its ClaimGraph states the C.16 result, subject, interpretation basis, polarity or domain status when current, and uncertainty. U.Measure may designate this retained reading claim. The episteme is not the measurand, actual subject state, raw output, indication, diagnosis, or criterion verdict.
M‑RES‑3. When exact work and governed actual changes first establish the episteme's identity and that inception matters, A.15.PROD supplies the local entity-identity inception claim. C.16 does not introduce a work-to-result relation.
Keep comparability and scoring bounded
M‑CMP‑1. Direct comparability is conservative: two readings cite the same U.DHCMethodRef, Characteristic, Scale and Unit semantics, compatible model and calibration regime, and a compatible time or population basis. Similar labels or units are insufficient.
M‑CMP‑2. Cross-template conversion, normalization, scoring, aggregation, comparison, selection, or cross-context transport names its exact subject pattern, method, declaration, Bridge, and loss or uncertainty consequence. C.16 does not mint a common scale or corpus-wide migration relation.
M‑SCORE‑1. A Score is another declared Scale reading. Its scoring method and actual application remain under their direct Method, Work, and operation-binding patterns. A score does not overwrite its source measurement results.
Route provenance and later use outward
U.EvidenceStub may carry a type-of-ground and identifier that lead to the exact A.10/G.6 provenance path. The path can cite the method description, model, calibration, work, inputs, output, result episteme, source publications, and transformations. Neither the stub nor a graph edge establishes those objects or their obtaining relations.
A later comparison, diagnosis, criterion evaluation, acceptance action, or decision is separate dated work. It uses the result episteme through an exact premise, reference, operation-argument, decision-use, or other direct relation. Currentness belongs to G.11; bounded reliance to A.10 or B.3 under their entry conditions.
Lexical and neighboring-pattern discipline
Use measurand, measurement subject, Characteristic, Scale, Level, Coordinate, value, Unit, measurement method, measurement model, calibration, uncertainty, measurement work, and measurement-result episteme for their exact jobs. Plain-register metric, reading, score, and output are acceptable after first-use mapping. Do not use measurement result, evidence, validation, or verification as umbrella terms for several governed objects.
Key relations. C.16 uses A.17 and A.18 for Characteristic and Scale legality; A.6.1 for declaration-local positions and operation bindings; A.15.1 for admitted Work and its performing System; and F.6 for the exact obtaining assignment under which that System performed. If claim-bearing source wording still says only “role,” use E.10.ROLE first, then use A.2 or A.2.1 only when an exact local system-role kind, classification, or assignment has actually been recovered. C.2.1 covers the result episteme; A.10/G.6 provenance; G.11 currentness; B.3 assurance; and the exact pattern for the next diagnosis, acceptance, causality, comparison, selection, or decision question.
Scale-type admissibility quick reference (Informative)
Didactic note. This table is a memory aid for engineers and managers. It does not introduce new admissibility rules. Normative admissibility of operations by scale type is governed by A.18 (CSLC) and, where mechanized in CG‑frames, by the relevant admissibility profiles. If any row below conflicts with A.18, treat it as an illustrative example and follow A.18.
Reminders (informative; see A.18 for normative rules). G‑1 (Order). On ordinal, transforms should be monotone. G‑2 (Differences). On interval or ratio, Δ is meaningful; on ordinal or nominal, it is undefined. G‑3 (Ratios). Only ratio Scales admit x/y semantics; interval, ordinal, or nominal do not. G‑4 (Unit coherence). Interval or ratio arithmetic presumes compatible units (or a declared conversion). G‑5 (Target polarity). If polarity is targeted, comparisons use distance‑from‑target semantics as declared by the relevant subject pattern, template, and cited method or mechanism.
(These rules line up with the MM‑CHR exposition of CSLC and term discipline; A.17 fixes the lexical side.)
Provenance and use semantics (Normative)
What an EvidenceStub is and is not
U.EvidenceStub is an optional compact locator from the reading claim to an exact provenance path. It may identify a source publication, calibration record, instrument output, model edition, work occurrence, transformation, or other ground, but A.10/G.6 govern the path and its citations.
- The stub is not evidence in the abstract, a result, an instrument output, a work record, an assurance claim, or a provenance-as-result object.
- Several stubs form a list of locators, not a measurement algebra. Their union is not uncertainty propagation and does not guarantee stronger warrant.
- A provenance edge may be asserted only after its direct source relation, work fact, participation, production, representation, or citation relation is independently established.
- A later user states the exact relied-on claim and local
RelianceDisposition; material reliance or an assurance claim enters B.3. Mere availability, citation, or graph membership does not establish actual use.
Measurement-result boundaries (Normative)
Keep the following objects distinct even when one carrier displays several of them:
The carrier, dashboard, ledger, criterion clause, and evidence path may represent or cite several rows. None collapses their identities or establishes another row by presence alone.
Archetypal Grounding
Calibrated detector receiver. The detector emits raw counts. Its processing yields an indication of 41.8 kPa. The measurand is gas pressure at port P over the stated sampling window; Characteristic is Pressure; Scale is a ratio quantity scale; Unit is kPa. Measurement model PressureModel-4 uses counts, reference offset, temperature, and calibration coefficients as inputs and pressure as output. Dated measurement work names its performer, detector, port, resources, bindings, calibration basis, and uncertainty propagation. The C.16 result attributes 41.8 kPa ± 0.6 kPa to the measurand under that basis; one C.2.1 episteme states it. The raw counts, displayed indication, actual pressure, result episteme, a later leak diagnosis, and a pressure-limit verdict remain different objects.
Internal-combustion-engine test bench. One dated test-bench work occurrence binds the engine, dynamometer, fuel batch, ambient conditions, method, model, and calibration records. Torque, exhaust temperature, and emissions are three Characteristics with separate Scales and result epistemes; their input quantities, output quantities, covariance where relevant, and uncertainties remain separately recoverable. Aggregation work may later construct a declared performance summary, and evaluation work may apply an emissions criterion. Neither the summary nor the pass/fail verdict is the torque or emissions measurement result.
Architecture coupling. The measurand is the exact ordered module pair under a declared dependency census window, not either module alone. The Characteristic is Coupling on an ordinal Scale. The method description defines generic dependency classes; dated work binds the actual codebase edition and pair. The result episteme states the Level and basis. A later release decision may rely on it, but the dashboard tile and decision record do not establish the census work.
Bias-Annotation
Conformance Checklist (Normative)
- Subject: one exact measurand or measurement subject is named, with correct entity or relation arity.
- CSLC: Characteristic, Scale, Level or Coordinate, Unit when current, polarity, and time stance are explicit.
- Method/model: the exact
U.Method, MethodDescription boundary, measurement model edition, inputs, output quantity, assumptions, and validity domain are recoverable. - Calibration: applicable calibration work/result, reference basis, coefficients or corrections, validity interval, and uncertainty contribution are cited when required.
- Work: every actual performer has the A.13 core; the dated
U.Workis independently admitted under A.15.1; F.6 is added afterward only when precise assignment-bound attribution is current. The exact measurand relation or A.6.1 binding is present; further enacted Methods, resources, or participant bindings are present only when the measurement claim uses them. - Result: one C.16 measurement result attributes value or values to the measurand with uncertainty and relevant information; one C.2.1 episteme states it.
- Separation: raw output, indication, actual subject state, result, result episteme, diagnosis, verdict, and decision are not collapsed.
- Comparability: direct or transformed comparison names its exact basis and does not upgrade the Scale or mint a common scale.
- Provenance/use: A.10/G.6 provenance, G.11 currentness, bounded reliance, assurance, and later work remain under their subject patterns.
- Boundary: no method description, plan, signature, carrier, ledger row, evidence edge, or stored reference is used to infer actual participation, work, or result identity.
Common Anti-Patterns and How to Avoid Them
- Template as occurrence. A reusable
U.DHCMethod, model, signature, or calibration procedure is treated as proof that work occurred. Ground dated work and actual bindings. - Generic result field. A record has
result=...without saying whether it is output, indication, measurement result, diagnosis, verdict, or decision. Name the direct result kind and governor. - Evidence algebra. Evidence locators are unioned as though idempotence or count determined uncertainty or warrant. Use measurement-model uncertainty propagation and exact A.10/B.3 reliance separately.
- Scale drift. A template id survives changed Scale, model, unit, or calibration semantics. Publish a successor and state the relation; do not mutate historical readings.
- Arithmetic on ordinal. Encoded levels are averaged or ratio-compared. Stay with order-preserving operations or introduce a separately governed scoring method and Scale.
- Multi-Characteristic stuffing. One reading carries a vector while pretending to be one measurement. Create separate results and declare any later aggregation.
- Result-to-verdict shortcut. A value inside a tolerance is called accepted without performed criterion evaluation. Ground the separate evaluation work, exact clause application, verdict episteme, and later decision.
Consequences
Benefits. Measurement results become interpretable and reusable without pretending to be raw reality or later judgment. A practitioner can inspect the measurand, Scale, method, model, calibration, work, uncertainty, episteme, and provenance, then enter the smallest pattern for the next question for comparison, diagnosis, acceptance, assurance, causality, or decision.
Trade-offs. The chain is longer than a dashboard field. Model assumptions, calibration status, and uncertainty can make a formerly crisp number conditional or set-valued. That cost is the information needed to avoid false precision and hidden result substitution.
Failure containment. Missing model validity, stale calibration, ungrounded work, absent actual bindings, or unreported uncertainty narrows or blocks the measurement claim. It does not authorize a generic evidence, result, or acceptance relation as fallback.
Rationale
Measurement is not merely reading a carrier. It is performed work under a method and model that attributes one or more values to a measurand and supplies the information required to interpret those values. That architecture explains why indication, actual subject state, measurement result, result episteme, diagnosis, and verdict must remain distinct.
SoTA-Echoing
Source qualification was checked against the publishers' current surfaces on 2026-07-30. It remains qualified through 2027-07-30 unless an edition, amendment, correction, Recommendation status, or normative definition changes earlier. External terms guide the bounded C.16 rules named below; no source imports its ontology wholesale or establishes a measurement, work occurrence, result, episteme, calibration fact, or later-use relation.
Lineage and domain examples not listed here are informative comparators, not decision-governing sources. A source refresh is local: replay the row's named rule, case, and checklist items, then widen only if that replay reveals a contradiction elsewhere.
Relations - Placement (Informative)
Architecture measurement boundary. C.32.P2S, C.32.PAD, and C.32.ADA may cite C.16 readings only after the characteristic, bearer, scale, coordinate, value, unit when relevant, and admissible use are declared. C.16 readings do not become architecture characteristics, decision criteria, eval programs, evidence, gates, or decision authority by themselves.
Structural-information measurement boundary. C.33, C.34, and C.35 may name captured structure, lost structure, similarity, preservation, entropy, epiplexity estimate, compression, generated-carrier adequacy, or search-output context. When any of those become a value, score, coordinate, threshold, dashboard reading, or eval result, state the measurement construction and admissible-use assertions under the exact C.16 and evaluation/criteria predicates, with their subject patterns used as locators.
Precision-restoration relation. C.16.P is the first-stage wording-use restoration pattern for characteristic, scale, coordinate, score, metric, axis, dimension, and related characterization wording when the measurement object is not yet recoverable. C.16 resumes after the measurand or subject, Characteristic, Scale, value, method, model, calibration, work, uncertainty, result episteme, or exact non-C.16 governor has been recovered.
C.27 temporal-claim relation.
- C.27 may flag: a rate/rate-change reading whose admissible use depends on admissible measurement construction, evidence, sampling window, or finite-difference method.
- This pattern keeps: measurand and measurement-subject identity, method, model, calibration, input/output quantities, uncertainty, dated work, measurement result, result episteme, comparability basis, units, sampling window, and provenance routing.
- Non-admissible use: a rate-change label is not a measurement template, and temporal words such as velocity, acceleration, throughput, cadence, or recovery speed are not admissible measures by themselves.
- Neighboring-pattern use: when load-bearing, the claim cites
baseCharacteristicRef, the relevant measure reference, sampling window, construction method such asDHCMethodRef, andC16RouteRef; C.27 keeps only the temporal-claim adequacy question.
C.28 causal-use relation. C.16 governs measurement construction, result interpretation, uncertainty, and direct comparability. C.28 governs the causal-use relation when the same result episteme is used to claim effect, intervention success, causal fairness, policy optimality, counterfactual comparison, off-policy causal evaluation, causal-RL evaluation, or causal method superiority. A C.16-admissible measurement result is therefore not by itself admissible for causal use under C.28.
Evidence, currentness, and assurance. Use A.10 and G.6 for source recovery and provenance for the exact method, model, calibration, Work, inputs, result episteme, and later use. Use G.11 for currentness and B.3 for assurance when its threshold is met. Evidence, provenance, currentness, and assurance do not by themselves establish the C.16 measurement result.
Kernel. MM‑CHR imports the canonical Characteristic vocabulary and the CSLC discipline fixed by A.17 and A.18; it does not redefine them. CharacteristicSpace reasoning (for change) lives in the patterns that consume MM‑CHR readings.
Using patterns. KD‑CAL, Arch‑CAL, G.4, and other consumers cite C.16 measurement-result epistemes and then ground their own comparison, evaluation, acceptance, aggregation, or decision work. They do not produce a measurement merely by naming a template, score field, criterion, or evidence profile.
Unification (F‑cluster). External standards (e.g., ISO 80000 quantity types; W3C SOSA/SSN observable properties; QUDT units/quantity kinds) are related via Concept‑Set rows and Bridges; MM‑CHR treats those alignments as context supplied by F‑patterns, not as local re‑definitions.
Measurement and probe note for quantum-like readings
Use C.16 first when the live object is a sensor reading, survey response, dashboard value, score, probe result, or state coordinate. Noise, probability, discreteness, gaming, or difficult interpretation does not by itself make a case quantum-like.
Recover the ordinary measurement chain first:
- name the exact measurand or subject, Characteristic, Scale, value or Level, Unit, polarity, and time stance;
- separate reusable method and model from dated work and actual bindings;
- name input quantities, output quantity, calibration basis, uncertainty propagation, and one measurement-result episteme;
- distinguish emitted output, indication, actual subject state, measurement result, result episteme, diagnosis, criterion verdict, and decision; and
- attach provenance through A.10/G.6 and state the exact supported and unsupported later uses.
Only after that repair ask whether the probe order, frame, publication, or export changes the state or the inferences that remain admissible. If it does, C.26 may govern that residual contextual or probe-order question. If it does not, remain in C.16 and the ordinary evidence, assurance, or receiving-use patterns.
Minimum probe note:
C.29 mathematical-lens use relation
If a mathematical lens depends on a measurement, recover the C.16 measurand, Scale, model, calibration, work, uncertainty, result episteme, and comparability basis first. C.29 may then state the lens-use admissibility claim; it does not construct the measurement, make values comparable, or provide provenance. A.10/G.6 retain provenance and B.3 retains assurance.
C.16:End
Characteristic and Scale Precision Restoration
Type: Characterization precision-restoration pattern Status: Stable Normativity: Normative unless explicitly marked informative
Plain-name. Characteristic-scale wording repair.
Intent.
Recover characteristic, scale, coordinate, score, metric, indicator, threshold, comparison, and scalar-quality wording whose construction is hidden before a reader applies C.16, A.17, A.18, A.19, C.25, C.29, E.21, or another subject pattern.
This pattern is not a metrics-only pattern, not a measurement-method replacement, not a Q-bundle pattern, and not a gate or decision pattern. It repairs overloaded characterization wording so the exact Characteristic, Scale, Coordinate, Value, Score, Unit, ScoringMethod, indicated characteristic or claim, direct indicator or proxy relation, comparison reference or comparator set, admissible use, and subject pattern become recoverable.
Builds on. E.10, E.10.ARCH, A.17, A.18, C.16, A.19, C.25, C.29, E.21, F.18, and A.6.P.
Coordinates with. C.16.Q, A.19.ECS, CHR mechanism patterns, G.0, G.5, G.9, C.11, A.10, B.3, A.20, A.21, C.28, A.15, and the evidence, assurance, gate, decision, causal-use, release, work, benchmark, and publication patterns that define or constrain those claims.
E.10.ARCH relation-function boundary. When E.10 encounters metric, score, axis, dimension, feature, property, indicator, strong, weak, robust, level, coordinate, threshold, benchmark, or scalar-quality wording whose characteristic and scale construction is hidden, E.10.ARCH selects C.16.P only until bearer, characteristic, scale, value or score construction, comparison reference or comparator set, threshold rule or reference, proxy relation, admissible use, and subject-pattern locator are recovered. After that recovery, state the subject assertion under its exact invariant or predicate.
Use this when
Use this pattern when wording such as axis, dimension, feature, property, metric, indicator, score, strong, weak, robust, level, coordinate, threshold, rating, benchmark, quality coordinate, or architecture score carries a characterization claim but does not yet show the recoverable construction.
What goes wrong if missed. A metric becomes a measure without a scale, a score becomes proof, strong becomes a verdict without a characteristic, a level becomes an undefined maturity status, an indicator becomes the thing indicated, or a benchmark result becomes gate passage or release permission.
What this buys. The reader can recover the bearer, characteristic, scale, value, score, unit, scoring method, indicated characteristic or claim, exact direct indicator or proxy relation, comparison reference or comparator set, threshold, admissible use, and subject pattern before treating a number, adjective, coordinate, or comparison as actionable.
First useful move. Ask which bearer, characteristic, scale, value or score construction is recoverable; then apply C.16, A.19, C.25, C.29, E.21, or the neighboring pattern governing that claim instead of letting the compact word decide.
Not this pattern when.
- If the
Characteristic,Scale, value set, scoring method, and admissible use are already recoverable, useC.16,A.17,A.18, orA.19directly. - If the claim being made is a Q-bundle, quality-term or evaluative characterization, or pattern-quality coordinate, use
C.25,C.16.Q, orE.21directly after any needed characteristic-scale repair. - If the claim being made is mathematical-lens use, use
C.29. - If the claim being made is evidence, assurance, gate, work, decision, causal-use, release, benchmark harness, or project-side authority claim, use the subject pattern for that claim after characteristic and scale construction is recovered or blocked.
Problem frame
Working texts often need compact characterization words. The problem starts when compact words begin to carry comparison, proof, selection, gate, readiness, release, quality, or decision claim without recoverable characteristic and scale construction.
The repair question is:
What characteristic or scale construction is recoverable, what exact assertion states the remaining claim, and where is its defining or constraining
ClaimGraphlocated?
The recoverable item may be:
- a
CharacteristicunderA.17; - a
Scale, coordinate, value, unit, scoring method, measure, or measurement use underA.18andC.16; - a
CharacteristicSpaceunderA.19; - a Q-bundle under
C.25; - quality-term or evaluative characterization under
C.16.Q; - pattern-quality coordinate use under
E.21; - mathematical-lens use under
C.29; - a comparison, threshold, indicator, proxy, benchmark, gate, evidence, decision, or work claim under a neighboring pattern that defines or constrains it;
- ordinary prose with no FPF-governed use.
Problem
How can FPF repair characterization wording without:
- treating
metricas a universal measurement kind; - treating
scoreas proof, readiness, gate passage, release permission, or decision; - treating
axis,dimension,feature,property, orlevelas a recoverable characteristic by appearance; - treating
strong,weak,robust,high,low, orbetteras meaningful without a scale and comparison reference or comparator set; - turning
C.16.Pinto a CHR super-pattern or replacement forC.16,A.17,A.18,A.19,C.25,C.29, orE.21; - copying first-stage characterization repair lists into every subject pattern.
Forces
Solution
Repair compressed characterization wording by producing a characteristic-scale repair note or equivalent local rewrite.
Minimum fields when a note is needed:
Use the full note only when the repair must remain inspectable. Use a local rewrite when one sentence clearly states the characteristic and scale construction and subject pattern. Keep necessary subject applicability or stop conditions in the repaired wording or admissibleUse. Include nonAdmissibleUse as an explanatory guard only under F.19:4's full independent-ground, plausible-reader, contribution, and smallest-clear-correction test; an unused guard needs no absence entry.
Recovery sequence
- Capture the trigger. Copy the exact word or phrase and the sentence that uses it.
- Recover the bearer. Name what is being characterized: holon, pattern, design-rationale record, architecture description, structure, model, method, work result, publication, candidate, relation, decision option, evidence relation, or another FPF kind named by value.
- Recover the construction. Decide whether the trigger means
Characteristic,Scale, coordinate, value, score, unit, scoring method, indicator, threshold, comparison reference or comparator set, proxy, Q-bundle, mathematical lens, gate, evidence, decision, or ordinary prose. - Select subject pattern when possible. If
C.16,A.17,A.18,A.19,C.25,C.29,E.21, or another subject pattern is already recoverable, use it directly. - Repair hidden characteristic and scale construction. When construction is hidden, recover the minimal needed set: characteristic, scale, value set, score, unit, scoring method, indicated characteristic or claim, exact direct indicator or proxy relation, comparison reference or comparator set, threshold rule or reference, admissible use, and any necessary applicability or stop condition. Add an explanatory non-admissible-use guard only under the full F.19:4 test. If the text relies on an indicator relation but none is recoverable, return
missing-governorrather than storing anindicatorRolelabel. - Separate adjacent claims. Evidence, assurance, gate, work, decision, causal-use, release, benchmark, publication, or authority claims are governed by their direct patterns.
- State remaining reader use. Say what the reader can now compare, measure, score, block, or assign to a neighboring pattern. If the result is type-correct but gives no action or recognition reason, the repair is incomplete.
Trigger split
Adjacent Claim Governance Named by Value
Refresh and reopen conditions
Reopen or narrow C.16.P when current pattern-language ecology changes the first characteristic and scale entry:
- a new characteristic named by value, scale, evaluation, benchmark, proxy or indicator, gate or decision, mathematical-lens, quality, OEE, NQD, or publication pattern can receive one row directly;
- current best-known practice changes comparability, proxy-risk, threshold, measurement, scoring-method, or benchmark-harness discipline adopted in the SoTA-Echoing section;
- README, ToC,
E.11, retrieval, or local Problem-frame entry cues change the first practical entry for hidden characteristic and scale wording; - a subject pattern starts copying first-stage
metric,score,axis,strong, orindicatortrigger lists that belong here; C.16.Pbegins to act as a metrics catalog, maturity scheme, or CHR super-pattern rather than a wording-use repair pattern for hidden construction.
The refresh action is to remove, narrow, or reassign the first-stage row. It is not to preserve stale routing language as history.
Archetypal Grounding - Worked cases
Bias-Annotation
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
Benefits. C.16.P gives a first-stage repair point for overloaded characterization words, so patterns for the next questions do not need to copy long trigger lists. It makes the next subject pattern visible before a number, adjective, level, score, metric, or benchmark result is treated as actionable.
Trade-offs. Some compact phrases become longer because the bearer, characteristic, scale, threshold, proxy, or subject pattern must be named. The gain is that measurement, quality, mathematical-lens, evidence, assurance, gate, decision, and causal-use claims do not hide inside one scalar word.
Stop condition. Stop using C.16.P once the characteristic-scale construction and the subject pattern are recoverable. The repaired claim then belongs to C.16, A.17, A.18, A.19, C.25, C.29, E.21, or the neighboring pattern named by value.
Rationale
The rationale for C.16.P is narrow: compact characterization wording is useful, but FPF cannot let compact words decide the kind of claim. The pattern restores the bearer, characteristic, scale, value or score construction, proxy relation, threshold rule, admissible use, and subject pattern before the text is allowed to support measurement, comparison, assurance, gate, decision, causal-use, benchmark, or mathematical-lens work.
SoTA-Echoing
Current measurement, quality, proxy-risk, and comparison practice distinguishes characteristics, scales, measures, scores, indicators, thresholds, comparability, proxy status, and decision use. FPF adopts this line only where it changes examples, non-comparability boundaries, indicator and proxy boundaries, scale and scoring method fields, gate and comparison exits, or conformance checks.
This row blocks scalar verdicts without declared scale and admissible use. It does not import metric lists, maturity-status schemes, or external scoring traditions as FPF ontology.
Relations
E.10catches hidden characteristic and scale wording and selects this pattern only when construction is hidden.E.10.ARCHdefines the shared wording-use recovery order and applicability row.A.17,A.18, andC.16govern characteristics, scales, values, measures, and measurement use.A.19governs characteristic-space construction.C.25governs Q-bundles.C.16.Qgoverns quality-term or evaluative characterization wording.E.21governs pattern-quality evaluation characteristic spaces.C.29governs mathematical-lens use.- Exact evidence, assurance, gate, work, decision, causal-use, release, benchmark, and publication patterns define or constrain their own claims.
C.16.P:End
Quality-Term Precision Restoration
Type: Characterization precision-restoration pattern Status: Stable Normativity: Normative unless explicitly marked informative
Plain-name. Quality-term precision restoration.
Intent. Provide a reusable discipline for repairing overloaded quality and evaluative-characterization wording in FPF texts.
This pattern lives in the C.16 characterization pattern nest. It rewrites bare evaluative prose either into the evaluative form already defined for a chosen endpoint or, while endpoint selection is being stabilized, into one transitional quality-term repair form with a named bearer, QualitySense, effective ReferenceScheme, separate probe/model and comparison configurations, evaluator and U.ViewpointRef, U.ClaimScope, admissible normal form (SignalPack | Characteristic | Bundle | Objective), result/evidence/grounding boundaries, reference-plane accountability, and lexical guardrails.
It allows philosophical, neuro-symbolic, control-theoretic, engineering, and open-ended-search uses to coexist without false identity by label. It does not treat quality-term or evaluative characterization as relation construction by default. When the found problem is relation construction, bridge, basedness, action-invitation relation, endpoint mismatch, or another relation-shaped claim, use A.6.P or the relation named by value specialization.
Placement.
Part C > C.16 characterization pattern nest > precision-restoration pattern for overloaded quality and evaluative-characterization wording.
Builds on.
E.10, E.10.ARCH, C.16.P, C.16, C.25, E.21, A.17, A.18, A.19, A.7, C.2.1, E.8, F.9, and F.18.
Coordinates with.
A.6.P for relation-construction exits; A.6.A for action-invitation exits; C.2.2a, A.16, A.16.1, A.16.2, and B.4.1 for language-state positions, admissible moves, early cues, next-use docking, and retreat; A.16.0 only when lineage, branch, loss, or an actual responsibility-handoff history itself needs an explicit trajectory account; B.5.2.0 for an open explanatory probe; C.2.LS, C.2.4, C.2.5, C.2.6, and C.2.7 for articulation, closure, anchoring, and representation-factor facets; C.2.1 for effective ReferenceScheme, result-episteme identity, and optional empirical grounding; A.2.6 for ClaimScope; A.19.CPM for comparison; E.17.0, E.17, and E.18 for exact viewpoint resolution and publication; C.30.AD and C.30.ASV for architecture-description and structural-view use; A.10 and B.3 for evidence and assurance; F.9 for direct cross-local Bridges and bounded-use claims; F.9.1 only for optional stance notes about those claims; A.19.CN for comparability governance; and C.3.3 for explicit kind-bridge repair when endpoint kind mismatches appear.
E.10.ARCH handoff.
When E.10 encounters quality, good, fit, high-quality, quality metric, quality score, quality characteristic, quality requirement, model quality, architecture quality, solution quality, or evaluative -ility wording whose quality sense, bearer, effective ReferenceScheme, probe/model or comparison configuration, ClaimScope, endpoint normal form, or endpoint rule is hidden, E.10.ARCH uses C.16.Q only until those values are recovered. Once the recovered claim is about a characteristic or bundle, relation, action invitation, representation, evidence, assurance, gate, work, decision, source use, or another named use, apply C.16.P, C.25, E.21, A.6.P, A.6.A, C.29, A.10, B.3, A.20, A.21, C.11, C.2.P, or the pattern that defines, constrains, or tests that claim. C.16.Q does not absorb those neighboring rules after the handoff is clear.
Non-goal.
This pattern does not assert that phenomenal character or qualia, phenomenological preconceptual fit, Pirsig-style dynamic quality and static quality, latent fit in learned representations, explanatory merit, engineering -ilities, QD and NQD selector value, and control adequacy are one concept.
Its job is to publish a disciplined evaluative-characterization use across those traditions while preventing false identity by shared label.
It also does not assert that every trigger use of "quality" is admissibly repaired by the transitional quality-term repair form: where the repaired statement is primarily about an action invitation under A.6.A, relation construction under A.6.P, or a requirement or commitment over explicit heads, apply the pattern for that recovered claim rather than assigning a quality-term or evaluative characterization.
Use this when
Use this pattern when wording such as quality, good, fit, high-quality, quality characteristic, quality improved, or an evaluative -ility claim hides which quality or evaluative-characterization use is live.
Lowest sufficient use. Keep ordinary praise or quoted source-local wording ordinary when it carries no FPF-governed use. When the evaluative endpoint is already known, publish the form defined for that endpoint directly. Use qualityTermAscription(...) only when transitional ambiguity must remain inspectable. Its core bearer, scheme, frame, scope, evaluator/viewpoint, and result boundaries stay explicit; add optional witness, evidence, grounding, Bridge, bounded-use-claim, Card, stance-note, time, plane, and substrate refs only when those branches are live.
What goes wrong if missed. A broad quality word becomes a scalar verdict, gate, evidence claim, relation, Bridge, action invitation, or bundle by appearance, while the bearer, scheme, probe/model configuration, comparison configuration, ClaimScope, quality sense, admissible normal form, and applicable endpoint rule remain hidden.
What this buys. The reader can recover the bearer and interpretation basis, see which probe/model and comparison configurations are active, distinguish evaluator from viewpoint, identify the candidate quality sense and admissible normal form, and take any result, evidence, grounding, Bridge, or relation claim to the pattern that defines or tests it before using the quality word as action guidance.
First useful move. Name the bearer, effective ReferenceScheme, probe/model frame, comparison frame or none, and ClaimScope; then decide whether the wording is evaluative characterization, characteristic-scale construction, Q-bundle, pattern-quality coordinate, relation construction, an F.9 Bridge or bounded-use claim, an optional F.9.1 stance note, action invitation, or ordinary prose, and apply the pattern for that use.
Not this pattern when.
- If the issue under repair is hidden characteristic, scale, score, metric, coordinate, threshold, or comparison construction, use
C.16.Pfirst. - If the claim being made is already a Q-bundle, pattern-quality coordinate, relation construction, action invitation, evidence, assurance, gate, work, decision, causal-use, release, or source-use claim, apply the pattern for that claim directly after any needed quality-word repair.
- If the word is ordinary praise or source-local wording with no FPF-governed use, keep it ordinary, quote-only, or reduced-use rather than publishing a quality-term repair.
Problem frame
FPF repeatedly encounters a predictable precision failure mode around the token quality:
drafts say:
- “this design has quality”
- “the model quality improved”
- “quality matters before formalisation”
- “quality characteristics”
- “quality in QD and NQD”
- “the world model is higher quality”
- “the explanation is high-quality”
…but the intended meaning is actually one of several different evaluative families, for example:
- Phenomenal character or qualia when the experienced quality itself is the topic of description rather than an externally measured characteristic.
- Preconceptual fit or felt rightness before stable EntityOfConcern characterization.
- Latent and distributed fit signals in learned representations, world models, or active inference loops.
- Explanatory merit of a theory, problem frame, or conjecture.
- Architectural-description fitness and compression merit of an architecture description or architecture model under a declared viewpoint.
- Engineering quality families such as reliability, maintainability, security, evolvability.
- Usefulness and selection value in open-ended search, novelty–quality–diversity, or portfolio selection.
- Control adequacy of a policy, model, or controller in a closed loop.
The failure modes are recurrent:
- Sense elision. One broad evaluative noun hides several non-equivalent evaluative kinds.
- Bearer confusion. The bearer of the evaluation is unclear: record, publication carrier when the carrier itself is evaluated, episode, model, policy, explanation, candidate, architecture, relation, or action loop.
- Form confusion. A non-metric signal is rewritten as a metric; a bundle is treated as one scalar; an objective is mistaken for a characteristic.
- Substrate confusion. Embodied and preconceptual, latent and distributed, and symbolic-local representations are silently collapsed.
- Plane confusion. Quality of the EntityOfConcern being described, quality of the description, quality of the carrier, and quality of the publication face are silently collapsed across
ReferencePlanevalues and A.7 lanes. - Bridge illusion. Similar wording across traditions is mistaken for sameness.
- Illegal scalarisation. Composite engineering families or explanatory merit are compressed into one number without an admissible scoring method.
- Viewpoint conflict. One stakeholder means architectural attributes, another means usefulness, another means preconceptual fit.
Problem
How can FPF let working texts keep the communicative convenience of the word quality while preventing category errors when the term crosses:
- phenomenological and epistemological discourse,
- architecture-description fitness discourse and viewpoint-fit discourse,
- representation-learning and neuro-symbolic discourse,
- Popper- and Deutsch-style explanation-and-criticism discourse,
- engineering architecture and quality-characteristic discourse,
- open-ended evolution, NQD, and selection discourse,
- control, world-model, and active-inference discourse,
- ecological affordance discourse, including source-tradition
affordancecases that must leave quality-term restoration forA.6.Aor another applicable action-invitation pattern?
Forces
- Breadth vs precision. “Quality” is attractive because it is broad; that same breadth makes it unsafe at boundaries.
- Preconceptuality vs auditability. Some uses refer to something real but not yet stably characterised.
- Distributed substrate vs local publication. Some evaluative signals arise in distributed or embodied substrates but must later be published in explicit local forms.
- Comparability vs non-reduction. Engineering and selection settings need comparability, but not every evaluative signal is an admissible metric.
- Cross-tradition dialogue vs false unification. The framework should permit parallels without asserting identity.
- Progressive articulation. A term may begin as a felt signal and later become a bundle, proxy set, or objective.
Solution
Stable repair frame > Sense Family > Slots > Normal Form > Change Lexicon > Guardrails
Trigger rule
A use of quality is in scope for C.16.Q when any of the following holds:
- the token quality or high-quality or low-quality appears in Tech or normative prose;
- a boundary statement relies on “quality” for admission, selection, explanation, comparison, assurance, or requirement-setting;
- different traditions are compared using the same word quality;
- a draft introduces quality metric, quality score, quality characteristic, quality requirement, model quality, architecture quality, solution quality, or quality in QD without a declared sense;
- the occurrence is intended to carry more than one of: evaluative fit, measurable characteristic, bundle, utility, or optimization objective.
Operational repair sequence
When the trigger fires, follow the E.10.ARCH recovery order specialized to quality-term or evaluative characterization:
-
Capture the trigger span. Copy the trigger phrase using quality or a red-flag derivative such as high-quality, quality metric, quality characteristic, or model quality.
-
Recover the bearer and publication lane. Name the bearer and the relevant A.7 lane or kind: EntityOfConcern being described, description,
epistemeor publication face, carrier when the carrier itself is evaluated, pattern, model, policy, explanation, candidate, architecture description, work result, relation, action loop, or ordinary prose. -
Recover interpretation locality and reconstruct candidates. Recover the effective ReferenceScheme, probe/model frame, separate A.19.CPM comparison frame or
none,U.ClaimScope, evaluator, andU.ViewpointRefornone. Then enumerate plausible senses and the patterns or source relations for their candidate endpoints. If the occurrence is decision-bearing, publication-bearing, or cross-local, record these alternatives in a short quality-term Candidate-Set Note before selecting the repair. -
Exit when the claim being made is not quality-term or evaluative characterization. If the occurrence is primarily action invitation, relation construction, bridge, basedness, endpoint mismatch, evidence, assurance, gate, work, decision, causal-use, release, mathematical-lens use, characteristic and scale construction, or source-use, do not assign a
QualitySense. ApplyA.6.P,A.6.A,C.16.P,C.29,C.2.P, or the pattern for the recovered claim. -
Select one explicit quality sense. Pick one
QualitySensetoken and state why rival senses were rejected in this local context. -
Emit an endpoint-explicit or transitional rewrite. Rewrite the sentence either into the evaluative form defined for a known endpoint (
Characteristic | Q-Bundle | Objective | ExplanatoryMeritBundle | selector-value endpoint) or, while endpoint choice is still being stabilized, into one explicitqualityTermAscription(...)transitional repair form with bearer, effective ReferenceScheme, probe/model and comparison frames, evaluator andU.ViewpointRef,U.ClaimScope, normal form, result boundary, and separate witness/evidence/grounding and cross-local qualifiers. -
Classify boundary-bearing consequences. If the repaired statement is used for admissibility, commitments, publication, evidence-bearing decisions, gates, release, or work, apply the pattern for that downstream claim instead of letting quality carry it by itself.
Transitional repair frame: evaluative classification anchored by qualityTermAscription(...)
C.16.Q stabilizes the ambiguity cluster by treating every in-scope quality statement as explicit evaluative content under one effective ReferenceScheme and a named endpoint pattern or source relation, not as a bare adjective, generic context field, or evidence-bearing result by implication.
qualityTermAscription(...) is the canonical transitional quality-term repair form when the endpoint choice is not yet fixed. It is not the universal resting place, not a relation kind by default, and not a shadow endpoint source.
Entry into C.16.Q presupposes enough articulation explicitness to name the bearer, effective scheme, probe/model frame, comparison frame or explicit none, ClaimScope, and at least one candidate evaluative family. Closure degree may remain low while qualityTermAscription(...) is transitional, but content that is still only a cue pack, forwarded cue, or open explanatory probe stays in A.16.1, B.4.1, or B.5.2.0. If a published record later loses an interpretation-bearing scheme, frame, scope, or direct source relation required for its stated use, retreat via A.16.2; changed witnesses, evidence use, or grounding reopen only the exact neighboring result or reliance claim they bear on.
The transitional form is:
effectiveReferenceScheme, probeOrModelFrameRef, comparisonFrameRef, and claimScope are explicit even when the comparison value is none; no generic context or frame slot defines their semantics. A probe or model frame remains the exact domain-local probe/model configuration. A comparison frame resolves the applicable CG-Spec, comparator edition, comparison scope, reference plane, and interval under A.19.CPM; it is not a universal Frame kind.
The record designates, but does not embed, a viewpoint. A non-none viewpointRef is one U.ViewpointRef whose governed resolution yields an exact viewpoint episteme; the reference, the viewpoint episteme, and the evaluator remain different objects. qualityResultClaimRef is not assessment work, while witness refs and an A.10 evidence-provenance path establish neither a result nor empirical grounding. Cite empiricalGroundingRelationRef only for a separately obtaining C.2.1 relation between the identified episteme and exact holon under governed observation, intervention, measurement, test, or evaluation relations. Likewise, cite an F.9 Bridge occurrence and bounded-use claim only when each independently exists. Cite a Card only when that optional package exists. Cite a stance note only when its reference resolves a C.2.1 episteme whose EntityOfConcern is that exact use claim. At least one of endpointPatternLocator and endpointSourceRelationRef is required. The locator identifies the pattern passage that defines or tests the endpoint; it does not make the pattern an actor or require a separate assertion or ClaimGraph unless a named later use depends on that rule identity.
So the sentence "X has quality" is never accepted as a terminal form. It must be rewritten either into the evaluative form for a known endpoint or into this transitional repair form with its interpretation-bearing and neighboring-object boundaries declared.
Discipline note.
QualitySense is a slot value inside the transitional repair form; it is not a replacement for the endpoint FPF pattern or explicit endpoint source reference. The sense token refines what kind of evaluative characterization is being made while the endpoint source, applicable pattern, or EntityOfConcern remains explicit.
Separation note.
evaluatorRef and viewpointRef are not synonyms. The evaluator is the observing, criticizing, or selecting party or policy. viewpointRef is a governed reference whose resolution yields one exact U.Viewpoint episteme; selecting or resolving it grants no membership, conformance, authority, or evaluation result.
The checked bearer, any dated assessment work, the resulting claim episteme, witness carriers, an A.10 evidence-provenance path, and an optional EpistemeEmpiricalGroundingRelation remain independently governed. A filled qualityTermAscription(...) may refer to each, but record completion, a result label, or stored witnesses makes none of the neighboring relations obtain.
Polarity discipline (bearer-centred; no silent inverse)
qualityTermAscription is bearer-centred.
Tech and normative prose SHALL keep the evaluated participant in the bearer position and SHALL publish evaluatorRef and governed viewpointRef separately, using none when either is absent.
- “Architects rate the system highly” rewrites to
qualityTermAscription(bearerTuple={System}, evaluatorRef=ArchitectureReviewBoard, viewpointRef=none, …). - “The benchmark says model quality is high” rewrites to
qualityTermAscription(bearerTuple={Model}, evaluatorRef=BenchmarkPolicy, viewpointRef=none, …).
There is no inverse token that silently makes the evaluator the bearer. If inverse wording is used in Plain prose, rewrite it into the bearer-centred form, or use the explicit inverse form supplied by the applicable pattern.
Endpoint-first discipline
When the endpoint pattern or explicit endpoint source relation is already known, publish the evaluative form it defines directly. Keep qualityTermAscription(...) only when preserving the transitional ambiguity is itself informative. qualityTermAscription(...) is therefore a transitional characterization record, not a shadow endpoint source.
Typical direct endpoints are:
- engineering
-ilityheads published as oneCharacteristicor oneQ-Bundle, - selector-context uses published as an
Objectiveheaded byQS.UseValueunless overridden explicitly, - architecture-description uses published under the description-side evaluative head already selected by the viewpoint bundle,
- explanatory-merit uses published under the explicit merit bundle when that bundle head is already known.
Core construct: QualitySense
Every in-scope use SHALL resolve to an explicit QualitySense token.
A QualitySense token publishes at least:
Where:
articulationMode∈{ preconceptual, exemplar-grounded, proxy-grounded, characteristic-bound, bundle-bound, objective-bound }representationSubstrate∈{ embodied-kinesthetic, latent-distributed, symbolic-local, hybrid }defaultNormalForm∈{ SignalPack, Characteristic, Bundle, Objective }admissibleNormalFormsis the explicitly declared set of admissible evaluative normal forms for the sense.defaultNormalFormnames the primary evaluative normal form; any additional endpoint forms MUST be declared here rather than inferred ad hoc.probeOrModelFrameKindconstrains only the domain-local probe/model configuration, whilecomparisonFrameRequiredstates whether a separate A.19.CPM comparison configuration must be named.bridgePolicycan require F.9 recovery or forbid silent reuse, but it cannot establish a Bridge. If the quality ascription is published, handle publication face, form, unit, carrier, and rendering questions under E.17, E.8, or the applicable publication pattern.
Normative starter set of sense families
A declared local vocabulary under one effective ReferenceScheme MAY add local senses, but the following starter set is normative as the initial disambiguation menu:
Default-form note.
QS.EngineeringQualityFamily and QS.ControlAdequacy default to Bundle.
A declared local use under one effective ReferenceScheme MAY operationalize one explicit head as a Characteristic, but that is a declared operationalization, not a second default normal form.
Normative rewrite note.
-
In NQD, QD, or selector contexts, bare quality SHALL rewrite to
QS.UseValueunless a differentQualitySenseis explicitly declared. -
In engineering contexts, bare quality SHALL rewrite either to:
- one explicit
U.Characteristic+ CSLC Scale, or - one explicit
Bundle, preferably published as aQ-Bundlewhen composite.
- one explicit
-
In phenomenological contexts, bare quality SHALL rewrite to
QS.PhenomenalCharacterwhen the experienced quality itself is the topic of description, and toQS.PreconceptualFitwhen the talk is about preconceptual fit or felt rightness before stable characterisation. -
In representation-learning and world-model contexts, bare model quality SHALL rewrite to
QS.LatentFit,QS.ControlAdequacy, or both, with the distinction made explicit. -
In epistemic evaluation contexts, “good explanation” SHALL rewrite to
QS.ExplanatoryMerit. -
In architecture-description fitness or viewpoint contexts, bare architecture quality or architectural quality SHALL first disambiguate the bearer lane: if the bearer is the system-side bearer, use
QS.EngineeringQualityFamily; if the bearer is the description or episteme, useQS.ArchitecturalDescriptionFitness.
Required slots for a conforming qualityTermAscription
A conforming qualityTermAscription SHALL make explicit:
-
Bearer tuple. Name the exact evaluated bearer designator or tuple and its arity. A description, carrier, evaluator, or result claim cannot silently replace that bearer.
-
QualitySense. Name the intended evaluative family. -
Effective ReferenceScheme. State the effective
U.ReferenceSchemeby value so every designator and local sense in the ascription is interpretable. A generic context label or a representation scheme is not a substitute. -
Probe or model frame. Name the exact domain-local exemplar pack, probe pack, test or criticism pack, Q-bundle definition, CG-frame, acceptance specification, control horizon, or other governed probe/model configuration.
-
Comparison frame. Name the exact A.19.CPM-governed comparison configuration separately, including the effective comparator and comparison scope when a comparison is made. Publish
nonewhen the ascription proposes no comparison; do not let the probe/model frame silently select one. -
Evaluator and viewpoint reference. State the evaluator or policy and, independently, either one
U.ViewpointRefornone. A non-nonereference SHALL resolve to one exact viewpoint episteme under E.17.0; neither the reference nor its resolution is the evaluator. -
Normal form and result boundary. State whether the ascription uses
SignalPack,Characteristic,Bundle, orObjective. If separately performed assessment work produced a result claim, cite that exact C.2.1 episteme throughqualityResultClaimRef; do not identify the work, result, bearer, or transitional record with one another. -
ClaimScope, selected slices, and time. State one
U.ClaimScopeand its exactU.ContextSlicemembership when the members matter. StateΓ_timewhen omission changes meaning.U.WorkScopeandU.PublicationScoperemain with their own work or publication claims rather than substituting for this claim scope. Freshness, qualification, and evidence-decay windows remain in their exact evidence, capability, or currentness lanes rather than being smuggled into quality. -
Reference plane when relevant. Name the plane when the same trigger phrase could concern the EntityOfConcern being described, its description, a carrier, or a publication face.
-
Representation scheme and substrate when relevant. Keep the effective reference scheme distinct from any representation scheme, viewpoint-specific decoding convention, or embodied-kinesthetic, latent-distributed, symbolic-local, or hybrid substrate. Name each when omission changes interpretation.
-
Witnesses, evidence use, and empirical grounding. Name exact exemplars, probes, measurements, bundle members, tests, traces, closed-loop performance carriers, or other witnesses. If an evidence-provenance path is relied on, cite its exact direct relations under A.10. Independently cite an obtaining
EpistemeEmpiricalGroundingRelation, or statenone; witness or record presence does not create that relation. -
Cross-local and endpoint boundaries. Cite an exact F.9 Bridge occurrence and bounded-use claim only when they independently exist. Cite a Card only when that optional package exists, and cite an F.9.1 stance note only when its
EntityOfConcernis that claim. State the endpoint pattern or endpoint source relation, the admissible use, and nearest non-admissible use rather than letting quality or a stance token carry them.
Normal-form discipline
A QualitySense SHALL declare one admissible default evaluative normal form and MAY declare additional admissible evaluative normal forms explicitly.
The normal forms in this section are endpoint or evaluative forms. They are not publication forms by themselves. Publication face, publication form, publication unit, carrier, rendering, export, and front-end questions remain with E.17, E.8, or the applicable endpoint-publication pattern.
QNF-1 - SignalPack.
Use for QS.PhenomenalCharacter, QS.PreconceptualFit, and many cases of QS.LatentFit.
A conforming SignalPack contains:
- exemplar or contrast set or probe set,
- articulation notes,
- source episode, carrier, and observer,
- optional ordinal or thresholded summaries,
- explicit warning that the signal is not yet a
Characteristicunless an admissible proxy is later declared.
QNF-2 - Characteristic.
Use only when the sense is truly one measurable characteristic on one declared scale.
This uses A.17, A.18, and C.16 and inherits full scale legality.
QNF-3 - Bundle.
Use when the sense is composite.
Typical for QS.ExplanatoryMerit, many engineering quality families, and QS.ControlAdequacy.
A conforming bundle contains:
- member heads,
- whether each head is Characteristic, status, mechanism, scope, or test,
- aggregation policy if any,
- prohibition on hidden scalarisation.
Engineering note.
For engineering -ility families, the preferred bundle endpoint is Q-Bundle (C.25), because it keeps Measures[CHR] distinct from ClaimScope and WorkScope and from Mechanisms and Status.
Q-Bundle is a C.25-governed bundle endpoint rather than a fifth normal form beside SignalPack | Characteristic | Bundle | Objective.
Do not use a free-floating bundle with hidden metric semantics.
QNF-4 - Objective.
Use for QS.UseValue in selection, generation, or search contexts.
A conforming objective contains:
- CG-frame or objective endpoint source reference,
- admissible comparators,
- acceptance or selector policy,
- reference plane and window,
- relation to novelty, diversity, and constraints.
Functional vs quality-family discipline
C.16.Q SHALL prevent the collapse of function or capability claims into quality-family claims.
- A statement about what a system does uses
A.6.Ffirst when function-like wording hides the FPF kind, relation, or claim, then applies the pattern for the recovered capability, Method, Work, system-role kind or assignment,A.6.Mmodule-interface, architecture, mathematical, evidence, assurance, gate, decision, or release claim. - A statement about how well, how safely, how robustly, or how maintainably it does so belongs to
QS.EngineeringQualityFamily. - “Quality characteristic” and “functional characteristic” SHALL NOT be used as interchangeable labels.
- In engineering contexts,
-ilitynames are quality-family labels, not automatically Characteristics. They become admissible only as one explicitU.Characteristicor one explicitBundle(preferably expressed throughQ-Bundlewhen composite). - Cross-references are allowed; category collapse is not.
Local repair stances and cross-local Bridge discipline
Within one exact <ReferenceScheme, LocalSenseClaim> interpretation basis, lexical restoration may choose a local sense or rename without asserting an F.9 Bridge. When two quality senses have different interpretation bases, first resolve both exact F.17 SchemeSenseCell values and test the direct F.9 Bridge predicate. Scheme difference, shared spelling, an analogy, a loss note, or a quality record establishes no Bridge.
If the Bridge obtains, cite its exact occurrence and state any proposed comparison, substitution, operationalization, or projection as a separate F.9 bounded-use claim. That claim names the direction, rule, tolerated loss, polarity, and effective ReferenceScheme. Apply A.10 or B.3 only for the reliance branch that is actually live. A Bridge Card remains optional reusable packaging.
Add an F.9.1 stance note only when a short interpretive cue helps a reader understand that exact bounded-use claim. The note is a separate C.2.1 episteme whose EntityOfConcern is the claim. Its optional label may be, for example:
localRename— read this use as near-renaming within its declared local boundary; do not infer cross-local identity.operationalizes— read the receiving expression as a procedural or measurable aid for this use; do not infer work, implementation, permission, or suitability beyond the cited claim.partialAnalogy— read the stated correspondence as partial; do not infer substitution.projection— read this use as a deliberate reduction of the source reading; the F.9 claim still carries its rule and tolerated loss.nonEquivalent— treat this as a warning against equivalence and silent substitution; the label alone asserts neitherDisjoint, negative polarity, nor an evidence score.
These tokens are optional reading labels inside a stance note. They are not Bridge kinds, direct relations, result claims, or substitutes for the Bridge, bounded-use claim, evidence, or loss account.
Examples:
QS.PreconceptualFitandQS.LatentFitare usually only candidates for partial correspondence. If their exact F.17 cells are cross-local, test an F.9 kind such asPartial-overlap; an optionalpartialAnalogynote may help read the resulting bounded-use claim but cannot establish identity.- A progression from
QS.PreconceptualFittoQS.PhenomenalCharacterneeds its exact direct relation or bounded-use account; shared articulation history does not make the senses identical. - Using
QS.PreconceptualFitto choose engineering measures is a proposed operationalization or projection use. Name the actual Bridge, separate use rule and tolerated loss, and direct measurement or characterization result. Add a stance note only if it improves the reading. - Relating
QS.EngineeringQualityFamilytoQS.UseValueis normally a directional, loss-bearing proposed use under a declared CG-frame, not identity and not permission to substitute one score for the other. QS.ExplanatoryMeritandQS.UseValueremain non-identical unless an exact F.9 Bridge obtains. An F.9.1nonEquivalentnote may help read an existing bounded-use claim but cannot replace the Bridge finding or claim polarity.- Pirsig-style dynamic quality may locally cue
QS.PreconceptualFitor sometimesQS.LatentFit. Within one exact interpretation basis this may be a local rename; across bases it needs exact F.17 cells and F.9 treatment. The label alone supplies neither identity nor empirical grounding. - Pirsig-style static quality usually cues a
CharacteristicorBundlepublication under another declared sense; it is not identical with dynamic quality. QS.ArchitecturalDescriptionFitnessandQS.EngineeringQualityFamilyhave different bearer lanes. Any cross-local correspondence must keep the exact description-side and system-side cells, Bridge occurrence, bounded-use claim, and losses separate and must name which description-fitness heads, if any, are proposed to proxy which system-side characteristics.
Change lexicon
A conforming quality-term repair publication SHALL narrate changes with a stable change lexicon aligned to A.6.P:
declareQualityTermAscription(...)— create a new explicit quality-ascription record.withdrawQualityTermAscription(...)— retire a prior record.retargetBearer(...)— retarget the evaluated bearer ref or tuple while keeping the repair-form schema.reviseSense(...)— change the value in thequalitySenseslot.reArticulate(...)— changearticulationModewhile preserving the sense family.reProxy(...)— change proxy, probe, or operationalization details.reBundle(...)— change bundle members or aggregation policy.reScale(...)— change characteristic scale or scale type.reProbeOrModelFrame(...)— change the exact domain-local probe or model frame.reComparisonFrame(...)— change the independently governed A.19.CPM comparison configuration.retargetEvaluator(...)— change the evaluator or policy ref without changing the viewpoint by implication.retargetViewpointRef(...)— retarget the governedU.ViewpointRef; resolution yields another exact viewpoint episteme only when the new reference resolves.reReferenceScheme(...)— change the effective ReferenceScheme explicitly; because that changes interpretation, re-check C.2.1 identity for any published claim episteme.rescopeClaim(...)— changeU.ClaimScopeor its exactU.ContextSlicemembers.retime(...)— changeΓ_time.refreshWitnessRefs(...)— refresh witness bindings without silently changing an evidence-provenance path or grounding relation.replaceEvidenceProvenancePath(...)— replace the cited A.10 path of exact direct relations without manufacturing a quality result.replaceEmpiricalGroundingRelationRef(...)— cite another independently obtaining C.2.1 grounding occurrence; a record edit cannot make it obtain.retargetBridgeOccurrenceRef(...)— retarget an exact F.9 occurrence ref; it does not retarget a bounded-use claim, optional Bridge Card, or optional stance note by implication.exitQualityAscription(...)— end use of the quality-ascription form and continue with the pattern for the recovered non-quality claim; never silently retype the old record.
A silent sense rewrite is a breaking semantic change.
If the ascription ceases to mean “quality ascription” at all, close it with exitQualityAscription(...) and publish the recovered claim in the form needed for its use rather than pretending the same record survived unchanged.
A.6.P rewrite note.
retargetBearer(...) is the family-specific form of retargetParticipant(BearerSlot, …). It, retargetEvaluator(...), retargetViewpointRef(...), and retargetBridgeOccurrenceRef(...) are reference-retargeting moves and SHALL preserve the A.6.5 distinction between a reference and the object it resolves. reviseSense(...), reArticulate(...), reProxy(...), reBundle(...), reScale(...), reProbeOrModelFrame(...), and reComparisonFrame(...) refine reviseByValue(...). reReferenceScheme(...) and rescopeClaim(...) change interpretation-bearing values and require an identity check for any published C.2.1 episteme. Witness, evidence-path, result-claim, grounding-relation, Bridge, bounded-use-claim, Card, and stance-note refs change independently; no edit silently rewrites another.
A.6.B boundary classification template for quality-term repair
When a repaired quality statement becomes boundary-bearing, classify it explicitly:
- L —
qualityTermAscriptionrepair-form skeleton,QualitySensesemantics, normal-form admissibility, cross-local routing, and the rule that any F.9.1 stance note remains a separate optional episteme about an already constituted bounded-use claim; - A — admissibility conditions for using the ascription in selector, gating, and publication lanes (required qualifiers, witnesses, thresholds, qualification windows);
- D — publication requirements (lexical firewall, mandatory rewrites, publication duties);
- E — carrier-anchored evidence and work effects (measurements, traces, critique sheets, probe packs, selector logs).
Where this family is published as a reusable boundary publication, stable L-Q*, A-Q*, D-Q*, and E-Q* claim ids SHOULD be published (or the reused L/A/D/E-classified claim set should be cited by location), and paraphrase drift across quadrants SHALL be avoided.
Do not let the bare word quality carry L/A/D/E claim by itself.
Lexical guardrails
In Tech and normative prose:
-
bare quality MUST NOT appear without immediate resolution to a
QualitySense; -
high-quality, low-quality, quality metric, quality score, quality requirement, model quality, architecture quality, and solution quality are red-flag tokens;
-
quality characteristic MAY appear only as:
- a bridge label to an external standard or tradition, or
- a family label immediately rewritten into one explicit
U.CharacteristicorQ-Bundle;
-
quality requirement or quality requirements MUST NOT remain bare noun phrases; rewrite them into explicit requirement-use, source-use, gate, commitment, acceptance-spec, characteristic,
Q-Bundle, objective, or publication-use claims or relations using the applicable pattern and one namedU.Characteristic,Q-Bundlehead, or objective head; the wording itself establishes none of those objects; -
architecture quality or architectural quality MUST NOT appear without an explicit bearer lane (
EntityOfConcern being described,description,epistemeor publication face, or carrier when the carrier itself is evaluated) and, when omission changes meaning, an explicitreferencePlane; -
in QD and NQD contexts, bare quality MUST default to
QS.UseValue; -
preconceptual uses MUST NOT be presented as if they were already Characteristics;
-
latent and distributed fit MUST NOT be presented as if it were automatically explanatory merit;
-
if the occurrence is primarily action-invitation talk, the text MUST NOT assign a
QualitySense; useA.6.Aor another applicable action-invitation pattern, with source-traditionaffordancewording kept only as a quoted cue when needed; -
scope words (applicability, envelope, generality, validity) MUST NOT be used as hidden substitutes for
U.ClaimScope,U.WorkScope,U.PublicationScope, or another exact governed scope; -
quoted metalinguistic uses of the token quality are allowed, but SHALL be marked as token-under-discussion, not as a boundary-bearing term.
Progressive elaboration
C.16.Q permits monotone elaboration:
- Select a
QualitySenseand retain rival candidates while ambiguity is live. - Name the exact bearer, effective ReferenceScheme,
U.ClaimScope, and any meaning-changingΓ_time, reference plane, representation scheme, or substrate. - Name the probe or model frame and the separate comparison frame or explicit
none; then name evaluator andU.ViewpointRefindependently. - Choose an admissible normal form and identify any separately constituted quality-result claim.
- Add exemplars, probes, characteristic heads, bundle members, objective pins, witness refs, and exact A.10 evidence-provenance paths as needed. Cite empirical grounding only through an independently obtaining relation.
- If cross-local correspondence is live, resolve exact F.17 cells, the obtaining F.9 Bridge, and the separate bounded-use claim. Add a Card only as optional packaging and an F.9.1 stance note only as optional reader help about that claim.
- If the repaired sentence is boundary-bearing, emit
L/A/D/Ehooks rather than letting quality carry them implicitly. - Never move between sense families, frames, schemes, scopes, result claims, or neighboring relations silently.
Archetypal Grounding
Tell
If a draft says quality, the draft has not yet named the evaluative family.
A conforming rewrite publishes either the evaluative form for one known endpoint or one explicit qualityTermAscription(...) transitional record with bearer, one QualitySense, effective ReferenceScheme, separate probe/model and comparison frames, evaluator and U.ViewpointRef, ClaimScope, admissible normal form, endpointPatternLocator or endpoint source relation, and explicit boundaries among result claim, witnesses, evidence use, empirical grounding, Bridge, bounded-use claim, optional Card, and optional stance note.
Show (System lane)
The identifiers below denote distinct objects. Each comparisonFrameRef resolves its exact A.19.CPM configuration; each non-none viewpointRef resolves one E.17.0 viewpoint episteme. A named result claim is not assessment work, witness refs do not establish an A.10 evidence-provenance path, and neither witnesses nor a result label establish the grounding relation cited beside them.
Draft: “The model quality improved.”
Repair A — latent representation line
qualityTermAscription( bearerTuple = {Model_v5}, qualitySense = QS.LatentFit, effectiveReferenceScheme = RepLearningScheme_5, probeOrModelFrameRef = ProbePack_PP2, comparisonFrameRef = LatentFitComparison_CF2, evaluatorRef = RepLearningReviewBoard, viewpointRef = none, normalForm = SignalPack, claimScope = U.ClaimScope({RepresentationLearningSlice_RL5}), Γ_time = Window_W5, qualityResultClaimRef = LatentFitResultClaim_22, witnessRefs = {ProbeSeparationRun_22, AliasRiskCard_9}, evidenceProvenancePathRefs = {LatentFitEvidencePath_22}, empiricalGroundingRelationRef = EGR_LatentFitResult_22, endpointPatternLocator = C.16 )
Here EGR_LatentFitResult_22 denotes a separately established relation between the exact result episteme and exact grounding holon under the governed probe or measurement relations. The run and card alone would not establish it.
Repair B — closed-loop control line
qualityTermAscription( bearerTuple = {PolicyModelPair_PM5}, qualitySense = QS.ControlAdequacy, effectiveReferenceScheme = ClosedLoopControlScheme_5, probeOrModelFrameRef = Horizon_H × EnvClass_E, comparisonFrameRef = ControlBaselineComparison_CF5, evaluatorRef = ControlReviewBoard, viewpointRef = ControlViewpointRef_7, normalForm = Bundle, claimScope = U.ClaimScope({ControlDeploymentSlice_7}), Γ_time = RunWindow_RW, qualityResultClaimRef = ControlAdequacyResultClaim_41, witnessRefs = {ClosedLoopTraceSet_41}, evidenceProvenancePathRefs = {ControlEvidencePath_41}, empiricalGroundingRelationRef = EGR_ControlAdequacyResult_41, endpointPatternLocator = C.25 )
Show (Episteme lane)
Draft: “Quality matters before definition.”
Repair A — preconceptual or phenomenological line
qualityTermAscription( bearerTuple = {ProblemFramingEpisode_PF3}, qualitySense = QS.PreconceptualFit, effectiveReferenceScheme = FeltFitArticulationScheme_3, probeOrModelFrameRef = ExemplarPack_EP3, comparisonFrameRef = ExemplarContrastFrame_ECF3, evaluatorRef = ReviewerGroup_A, viewpointRef = none, normalForm = SignalPack, claimScope = U.ClaimScope({ProblemFramingSlice_PF3}), representationSubstrate = embodied-kinesthetic, qualityResultClaimRef = PreconceptualFitClaim_PF3, witnessRefs = {EpisodeNotes_3}, evidenceProvenancePathRefs = none, empiricalGroundingRelationRef = none, endpointPatternLocator = A.16.1 )
The explicit none values matter: episode notes are witnesses to articulation, not automatic provenance or empirical grounding.
Repair B — explanatory line
qualityTermAscription( bearerTuple = {Explanation_N5}, qualitySense = QS.ExplanatoryMerit, effectiveReferenceScheme = ExplanationCriticismScheme_5, probeOrModelFrameRef = CriticismBundle_CB4, comparisonFrameRef = RivalExplanationComparison_CF4, evaluatorRef = TheoryReviewPanel, viewpointRef = none, referencePlane = episteme, normalForm = Bundle, claimScope = U.ClaimScope({ExplanationReviewSlice_N5}), qualityResultClaimRef = ExplanatoryMeritResultClaim_14, witnessRefs = {CritiqueSheet_14, CounterexampleSet_2}, evidenceProvenancePathRefs = {ExplanationEvidencePath_14}, empiricalGroundingRelationRef = none, endpointPatternLocator = C.25 )
Show (Architecture description lane)
Draft: “The architecture quality improved.”
Repair A — quality of the system-side bearer
qualityTermAscription( bearerTuple = {PaymentPlatform_v4}, qualitySense = QS.EngineeringQualityFamily, effectiveReferenceScheme = PlatformEngineeringQualityScheme_4, probeOrModelFrameRef = Q_Bundle_AvailabilitySecurityEvolvability_3, comparisonFrameRef = PlatformVersionComparison_CF4, evaluatorRef = ArchitectureReviewBoard, viewpointRef = ProjectSystemEngineeringQualityViewpointRef_4, referencePlane = world, normalForm = Bundle, claimScope = U.ClaimScope({PaymentPlatformEngineeringSlice_4}), qualityResultClaimRef = PlatformQualityResultClaim_8, witnessRefs = {AvailabilityReport_8, CouplingCheck_3, EvolvabilityNote_2}, evidenceProvenancePathRefs = {PlatformQualityEvidencePath_8}, empiricalGroundingRelationRef = EGR_PlatformQualityResult_8, endpointPatternLocator = C.25 )
Repair B — quality of the architecture description
qualityTermAscription( bearerTuple = {ArchitectureDescription_AD12}, qualitySense = QS.ArchitecturalDescriptionFitness, effectiveReferenceScheme = ArchitectureDescriptionFitnessScheme_12, probeOrModelFrameRef = ArchitectureDescriptionProbeFrame_AD12, comparisonFrameRef = DescriptionEditionComparison_CF12, evaluatorRef = ArchitectureReviewBoard, viewpointRef = ProjectArchitectureDescriptionFitnessViewpointRef_12, referencePlane = episteme, normalForm = Bundle, claimScope = U.ClaimScope({ArchitectureDescriptionReviewSlice_AD12}), qualityResultClaimRef = DescriptionFitnessResultClaim_7, witnessRefs = {CoverageMatrix_4, CorrespondenceCheck_7, ViewConsistencyNote_2}, evidenceProvenancePathRefs = {DescriptionFitnessEvidencePath_7}, empiricalGroundingRelationRef = none, endpointPatternLocator = C.25 )
ArchitectureDescriptionProbeFrame_AD12 is one project-local probe frame: it may cite DecisionQuestionSet_DQ7, an architecture-description result under C.30.AD, structural-view adequacy under C.30.ASV, and the retained U.ViewpointRef members resolved from a constituted E.17.1 catalogue. It is neither a viewpoint-family value nor a substitute for the selected viewpoint. C.25 supplies the Bundle endpoint; the architecture-description and viewpoint patterns supply their own checks. The shared evaluator does not collapse the two repairs: their bearers, schemes, probe/model frames, scopes, viewpoint references, result claims, and evidence paths differ.
Show (QD or selector lane)
Draft: “Quality in our QD loop.”
Repair
qualityTermAscription( bearerTuple = {Candidate_7}, qualitySense = QS.UseValue, effectiveReferenceScheme = QDUseValueScheme_9, probeOrModelFrameRef = CG_Frame_9, comparisonFrameRef = ArchiveComparatorFrame_9, evaluatorRef = SelectorPolicy_P4, viewpointRef = none, normalForm = Objective, claimScope = U.ClaimScope({QDSelectionSlice_9}), Γ_time = SelectionWindow_SW, qualityResultClaimRef = UseValueResultClaim_9, witnessRefs = {ObjectiveCard_9, AcceptanceSpec_4}, evidenceProvenancePathRefs = {QDSelectionEvidencePath_9}, empiricalGroundingRelationRef = none, endpointPatternLocator = C.17 )
Bias-Annotation
Lenses tested: Gov, Arch, Onto-Epist, Prag, Did. Scope: Universal for overloaded evaluative uses of quality in FPF-governed wording.
- Gov bias: this pattern favors explicit evaluative publication and explicit L/A/D/E hooks, which improves auditability but adds drafting overhead.
- Arch bias: this pattern prefers one stable transitional ascription record over free-form philosophical prose, which improves reuse but can feel rigid in exploratory notes.
- Onto-Epist bias: this pattern refuses to collapse preconceptual, latent, explanatory, engineering, and selector senses into one concept; that increases honesty at the cost of extra lexical work.
- Prag bias: this pattern defaults QD and NQD uses toward
UseValue, which improves selector clarity but can feel narrower than colloquial “quality”. - Did bias: this pattern is intentionally teachable through repeated rewrites; the risk is over-formalizing early exploratory language.
Conformance Checklist (CC-C16Q)
A text or pattern conforms to C.16.Q iff:
- CC-C16Q-1 - Explicit endpoint classification and explicit sense.
Every in-scope use resolves either to the evaluative form for one declared endpoint or to one declared
qualityTermAscription(...)transitional record with aQualitySenseand explicit endpoint classification. - CC-C16Q-2 - Exact bearer and arity. The evaluated bearer designator or tuple is explicit; description, carrier, evaluator, viewpoint, work, and result are not substituted for it.
- CC-C16Q-3 - Exact probe/model and comparison frames.
The domain-local probe or model frame and the separately governed comparison frame or explicit
noneare stated and reviewable; no generic field silently selects either frame. - CC-C16Q-4 - Effective scheme, evaluator, and viewpoint reference.
The effective
U.ReferenceSchemeis explicit. Evaluator andU.ViewpointRefare separate; a non-nonereference resolves one exact viewpoint episteme and grants no conformance, membership, authority, or result. - CC-C16Q-5 - Substrate and referencePlane are declared when relevant.
Cross-talk between preconceptual, latent-distributed, symbolic-local, and
ReferencePlanevaluesworld,concept, andepistemeis not allowed without explicit substrate and, when live, plane declarations. - CC-C16Q-6 - ClaimScope, slices, and
Γ_timeare explicit. OneU.ClaimScope, its meaning-changingU.ContextSlicemembers, and any meaning-changingΓ_timeare stated; work or publication scope does not substitute for claim scope. - CC-C16Q-7 - Admissible normal form and result boundary.
The ascription uses
SignalPack,Characteristic,Bundle, orObjectivewith the corresponding normal-form discipline; any checked object, assessment work, result claim, witnesses, evidence-provenance path, and empirical-grounding relation remain independently identified. - CC-C16Q-8 - No illegal scalarization. Composite senses are not collapsed into one score without an explicit admissible scoring and comparison method.
- CC-C16Q-9 - No silent sense rewrite. Any semantic change uses the declared change lexicon; changing sense, scheme, frame, scope, or neighboring relation silently is forbidden.
- CC-C16Q-10 - QD default.
In search, selection, or NQD practice, quality resolves to
QS.UseValueunless overridden explicitly. - CC-C16Q-11 - Engineering family discipline.
Engineering
-ilityuses resolve to one explicitU.Characteristicor one explicitBundle, preferably aQ-Bundlewhen composite; they do not remain free-floating adjectives. - CC-C16Q-12 - Functional separation. Function or capability claims remain distinct from quality-family claims.
- CC-C16Q-13 - Bridge accountability.
Cross-local comparison resolves exact F.17 cells and cites an obtaining F.9 Bridge plus the exact bounded-use claim when a use is proposed. Any optional Card and F.9.1 stance note remain separate; the stance note's
EntityOfConcernis that claim. A stance word,CL, shared label, or loss note establishes none of them. - CC-C16Q-14 - Boundary-claim hook when needed.
If a repaired ascription is used for admissibility, commitment, publication, evidence-bearing decision, or adjudication, the downstream
L/A/D/Eclaims and the patterns used to define or test them are explicit. - CC-C16Q-15 - Lexical firewall. Bare quality is absent from Tech and normative prose except as quoted and marked metalinguistic discussion.
- CC-C16Q-16 - Transitional skeleton is complete.
The published skeleton carries bearer position and bearer-kind mismatch repair, sense, effective scheme, exact frames, evaluator,
U.ViewpointRef, ClaimScope, qualifier expectations, normal form, result, witness/evidence/grounding discipline, admissible change classes, and cross-local boundaries without minting universal context, frame, evidence, or grounding kinds. - CC-C16Q-17 - Candidate-Set Note is used when ambiguity is live.
If sense selection, bearer facet, or A.7 lane or kind (
EntityOfConcern being described,description,epistemeor publication face, or carrier when the carrier itself is evaluated) is non-obvious, the text records a short Candidate-Set Note before decision-bearing or publication-bearing use. - CC-C16Q-18 - Reference resolution is not object substitution. Designators, governed refs, their resolved viewpoint or bearer objects, evaluator, result, frame, scope, grounding holon, and any selected structure remain distinct.
- CC-C16Q-19 - Change verbs dock cleanly with A.6.P and A.6.5.
retargetBearer(...)and the other declared reference moves are used only for ref retargeting; by-value revisions use their declared verbs; a scheme or scope change triggers claim-identity review; edits to witnesses, evidence paths, grounding, Bridge, bounded-use-claim, Card, or stance-note refs do not silently rewrite one another; and silent retyping is forbidden.
Common Anti-Patterns and How to Avoid Them
Consequences
Benefits. This pattern makes evaluative language auditable across phenomenology, engineering, and search and selection contexts. It also makes subsequent wording repair easier because one explicit quality-term repair form carries the open ambiguity while a reference to the applicable endpoint pattern closes it.
Trade-offs and mitigations. The pattern adds drafting overhead and can feel heavy in exploratory notes. Mitigation: allow bare quality in Plain commentary during exploration, but require repair before the term enters Tech and normative, boundary, selector, or assurance use.
Rationale
C.16.Q makes one strategic move:
The word “quality” is not treated as one concept. It is treated as a family of evaluative ascriptions whose members differ by substrate, articulation mode, bearer, effective scheme, probe/model configuration, comparison configuration, ClaimScope, and admissible publication form.
This lets FPF discuss:
- Pirsig-like preconceptual fit,
- representation-learning and neuro-symbolic latent fit,
- explanation quality in criticism-driven inquiry,
- architecture-description fitness under a viewpoint,
- engineering quality families,
- use-value in open-ended evolution,
- control adequacy in action loops,
without forcing them into one false universal scalar.
It also makes the distributed-vs-local issue explicit:
- some senses originate in embodied or latent-distributed substrates,
- some are only publishable as symbolic-local CHR, bundle, and objective forms,
- and some require an explicit projection from the first into the second.
It also makes the bearer and plane issue explicit:
- some uses evaluate the EntityOfConcern being described,
- some evaluate its description under a viewpoint,
- some evaluate a carrier or publication face,
- and those uses must not be collapsed without an explicit bearer lane and, when needed, a declared
referencePlane.
That is exactly where semantic drift usually starts; C.16.Q turns that drift into an auditable design choice.
SoTA-Echoing
Evidence binding note. If the selected authoring environment maintains a SoTA Synthesis Pack for evaluative language, architecture-quality vocabularies, selector and objective semantics, world-model evaluation, or embodied and preconceptual articulation, this section SHALL cite its ClaimSheet IDs, CorpusLedger entries, and BridgeMatrix rows and keep the adoption statuses below consistent with those IDs. Otherwise, use the table below as the current source-use and source-currentness record for this pattern revision, not as a generic seed list.
This section follows the required structure: claim > practice > source use and currentness > source > alignment > adoption status. C.16.Q aligns with contemporary practice across architecture-description standards, software-quality standards, evolutionary architecture, QD search, active-inference and world-model research, phenomenology and TAE, source-tradition affordance work, and philosophy of explanation, while adding one explicit FPF move: repair the overloaded token quality into an endpoint form, or keep qualityTermAscription(...) temporarily with its bearer, QualitySense, effective scheme, separate probe/model and comparison configurations, ClaimScope, admissible normal form, and endpoint reference visible.
Source-use convention. Current-best source use means the row is used as the best-known current line for the narrow effect named in the alignment cell. Current-standard and reference-only use means an official standard supplies a useful distinction but does not by itself solve C.16.Q's quality-term restoration question. Current-practice reference use means the source family records a widely used current practice that C.16.Q adapts. Lineage and local-gloss material means the row helps recognition or terminology only. Rejected import states what C.16.Q refuses to import as FPF ontology.
Short alignment notes.
Architecture-description practice. ISO 42010 is a current-standard reference for not collapsing the selected system or other entity under description into its description. C.16.Q adopts that guardrail and adds lexical discipline: a draft may not say architecture quality without publishing which bearer lane is under evaluation and whether the evaluation is description-side or system-side.
Engineering quality practice. ISO 25010 gives a mainstream current-standard reason not to leave quality as a free noun: contemporary quality work is organized around named characteristics and subcharacteristics that are specified, measured, and evaluated. C.16.Q adopts that explicit-head discipline, but adapts it by assigning composite cases to Bundle or Q-Bundle and by treating quality requirement(s) as requirements over explicit heads rather than as self-standing nouns.
Evolutionary-architecture practice. Fitness functions treat architecture-relevant concerns as continuously monitored heads tied to change and governance, not as one mystical scalar. C.16.Q adopts that operational spirit, but adapts it by keeping engineering-family evaluation, control adequacy, and selector value distinct and by forbidding function and quality-family collapse.
QD and NQD practice. Modern QD work is explicit that search returns a collection of solutions that are high with respect to an objective and diverse with respect to declared measures. C.16.Q therefore adopts the default rewrite of selector-context quality to QS.UseValue in Objective form and rejects any rewrite that silently blends novelty, diversity, constraints, and utility into an unexplained scalar.
World-model and active-inference practice. Contemporary world-model and active-inference work uses generative and predictive models for perception, planning, learning, and action, which makes evaluation inherently multi-factor: latent representation quality, model evidence or predictive adequacy, policy adequacy, and task and objective value are not one thing. C.16.Q adapts this by separating QS.LatentFit, QS.ControlAdequacy, and QS.UseValue, and by requiring effective schemes, separate probe/model and comparison configurations, ClaimScopes, and witnesses for each ascription.
Phenomenology and TAE practice. TAE-style work treats a felt sense as something that can be clarified and worded progressively, with tentative language that stays responsive to lived experience. C.16.Q adopts this progressive-articulation stance by giving QS.PreconceptualFit an admissible SignalPack form and by keeping QS.PhenomenalCharacter separately available when the experienced character itself, not action-guiding fit, is the topic.
Action-invitation boundary. Recent source-tradition affordance work emphasizes that affordances can be experienced as action possibilities that position or invite an agent to act. C.16.Q uses that insight only as a boundary cue: when quality is really action-invitation talk, close the quality ascription and apply A.6.A or another applicable action-invitation pattern. Name the action invitation and relevant relation when later use depends on them; do not force a QualitySense or qualityTermAscription(...).
Explanation practice. Contemporary philosophy of explanation keeps explanatory understanding and epistemic value distinct from engineering performance or utility maximization. C.16.Q adapts this by publishing QS.ExplanatoryMerit as its own evaluative family, typically Bundle-shaped, and by rejecting hidden scalarization into “high-quality explanation” without explicit heads.
Scale legality. The rows above do not license free arithmetic on the word quality. Whenever C.16.Q operationalizes engineering heads, selector objectives, or control adequacy numerically, it SHALL bind the comparison to an explicit ComparatorSet, CG-Spec, or declared aggregation policy and SHALL reject covert scalarization of bundles, explanations, or preconceptual signals.
Cross-local and plane note. This section states alignment and non-identity only. Any actual reuse of a quality vocabulary, selector head, or viewpoint-bound family across different <ReferenceScheme, LocalSenseClaim> bases SHALL resolve two exact F.17 cells and cite an obtaining F.9 Bridge. The proposed use, direction, rule, tolerated loss, polarity, evidence reliance, and any cross-plane representation relation remain separate; a stance word or note, CL, loss note, shared label, or plane policy makes none of them obtain.
Historical-lineage note. Earlier touchstones such as Pirsig, Popper, and Deutsch remain useful as lineage and local-gloss resources, but C.16.Q does not use them as formal SoTA anchors here because E.8 requires post-2015 primary sources for Architectural patterns unless the row is explicitly lineage or local-gloss material.
This SoTA alignment backs the pattern’s central move: quality is not one universal evaluative noun. In contemporary practice, the relevant work is already distributed across explicit characteristics, objectives, viewpoints, world-model criteria, explanatory virtues, felt signals, and action invitations; C.16.Q makes that distribution first-class and auditable.
Refresh and reopen conditions
Reopen or narrow C.16.Q when any of these current-pattern-language conditions becomes live:
- a recurring quality or evaluative family appears that is not covered by the current
QualitySensestarter set and cannot use an existing endpoint form; - an endpoint pattern can now handle a class of uses that currently require transitional
qualityTermAscription(...); A.7,C.2.P,C.2.1, or bridge-policy vocabulary changes the admissible lane, EntityOfConcern, publication-face, carrier, orReferencePlanewording used by this pattern;- current best-known practice changes a
QualitySense, normal-form boundary, action-invitation boundary, scale-legality boundary, or source-use and currentness row used inC.16.Q:11; - README, ToC,
E.11, retrieval, or local Problem-frame first-entry cues change for quality, characteristic, action-invitation, architecture-description, selector, or explanation wording; - other patterns begin copying quality trigger lists,
QualitySenserows, or transitional repair-form slots that belong in this first-stage quality-term precision-restoration pattern.
The refresh action is to remove, narrow, or redirect the affected row or exit. Do not preserve a stale QualitySense, endpoint exit, lane wording, or source row as historical compatibility text.
Relations
- Lives in: C.16 characterization pattern nest as the quality-term realization of E.10.ARCH and C.16.P.
- Builds on: E.10.ARCH for shared wording-use restoration architecture; C.16.P for characteristic and scale exits; A.2.6 for explicit scope and
Γ_time; A.17, A.18, and C.16 for admissible measurable characteristics; C.25 for engineeringQ-Bundlepublication. - Coordinates with: A.6.P when recovered content is relation construction rather than evaluative characterization; A.6.A or another applicable action-invitation pattern when the trigger invites action; C.2.2a, A.16, A.16.1, A.16.2, B.4.1, and B.5.2.0 for language-state positions, early cues, next-use docking, and retreat or reopen; use A.16.0 only when lineage, branch, loss, or an actual responsibility-handoff history itself must be published as an explicit trajectory account; C.2.LS, C.2.4, C.2.5, C.2.6, and C.2.7 for language-state facets; C.2.1 for effective ReferenceScheme, exact result-episteme identity, and optional
EpistemeEmpiricalGroundingRelation; A.2.6 forU.ClaimScopeandU.ContextSlice; A.19.CPM for comparison; A.10 for evidence-provenance and bounded reliance; C.17, C.18, and C.19 for selector value, novelty, diversity, and policy; E.17.0 and E.17.2 for exact viewpoint epistemes andU.ViewpointRef; C.30.AD and C.30.ASV for architecture-description and structural-view use; F.9 for exact cross-local Bridge occurrences and bounded-use claims; F.9.1 only for separate optional stance notes about those claims; and A.6.B when repaired ascriptions become boundary-bearing. - Publishes vocabulary through: E.10, F.17, and F.18 when the
qualityTermAscriptionrepair-form skeleton, theQualitySensestarter set, and the red-flag rewrites become stable shared vocabulary.
Language-space refactor note
This pattern uses endpoint-first assignment rather than universal governance of all quality language. qualityTermAscription(...) remains useful as a transitional repair form, but it is not the required resting place or durable local record kind for every repaired use of quality.
Explicit endpoint selection
Admissible endpoints after repair include:
- a single
Characteristic, - a
Q-Bundle, - an
E.21 PatternQualityQBundle, when the bearer is one FPF pattern version and the evaluative claim asks whether the pattern is good enough for a declared reader, use, and scope. In this case, do not assign the claim to generalC.25unless the bearer is a non-pattern engineering quality family, - an
Objective, - an explanatory-merit bundle,
- a selector-value endpoint.
Bare quality in Tech prose should therefore be banned or rewritten immediately using the applicable endpoint pattern or explicit endpoint source relation. If that endpoint is already known, qualityTermAscription(...) need not remain in the published normal form.
What C.16.Q leaves to other patterns
C.16.Q does not define or test articulation-state characteristics, Bridge truth, bounded-use claims, stance-note identity, evidence-provenance, empirical grounding, comparison operations, viewpoint resolution, or representation factors. Use A.16, C.2.LS, C.2.4, C.2.5, C.2.6, C.2.7, F.9, F.9.1, A.10, C.2.1, A.19.CPM, E.17.0, or the applicable representation pattern for those questions.
C.16.Q:End
Characterising Generative Novelty and Value
Status. Evaluation and measurement-use pattern; normative where stated.
Depends on. A.17, A.18, and A.19 for Characteristics, Scales, and CharacteristicSpaces; A.19.ECS for the evaluation-space specification; C.16 for measurement; C.2.1 and A.1.1 for claim-bearing results and models; A.10 and B.3 for evidence, reliance, and assurance; and the patterns that define the current objective, acceptance criterion, and must-constraints.
Coordinates with. E.10.LRN when learning progress or related wording still hides the bearer or result; C.18 for generation, Archive, Front, and possibility-space change; C.19 for pool policy and tie-break use; G.5 for selector-facing declarations; C.11.CRC for a missing finite configuration-relative comparison; C.11 for choice; F.9 for an actual cross-reference-scheme Bridge; F.18 for naming-candidate diversity; B.4 and G.11 for evolution and refresh; A.13 and A.15.1 for exact evaluator recovery and independently admitted dated overall-assessment Work; A.2.1 and F.6 only when exact assignment-bound attribution is expressly consumed; A.3.1 for the enacted Method; A.3.2 when a relied-on MethodDescription matters; and A.6.1 only when the assessment also uses one exact operation declared by a separately admitted U.Mechanism and a claim needs that operation's application or bindings.
Use this when
Use C.17 when someone must say whether a design, code change, theory, policy proposal, dated Work occurrence, or finite candidate set—the bearer being discussed—is new relative to a named comparison basis and useful for a stated objective or must-criterion.
If the claim arrives as learning progress, learned novelty, or information gain described as learning, and the bearer or result is still hidden, apply E.10.LRN and the direct result owner first. Enter C.17 only after the bearer and the novelty, use, surprise, creativity, or other characterization question are exact. Stop at the direct result when no such characterization is current.
Begin with the smallest useful answer:
- identify the bearer being discussed;
- say what it is new compared with;
- say which objective, acceptance criterion, or must-constraint matters;
- state the supported difference, its practical consequence, the evidence used, and the limit of that support.
Stop there when a qualitative answer is enough. A discussion does not need a score, profile, reusable record, or dated assessment merely because it uses the words novel, useful, or creative.
Open the stronger branch only when the receiving use needs a quantified coordinate, a comparison-ready result, later reliance, or an audit trail. Then every coordinate must follow its truthful measurement or ascription route before the coordinate claims can support a bounded aggregate result.
What changes in practice. A team can replace an unqualified creativity label with the comparison basis, practical criterion, supported difference, consequence, uncertainty, and stopping point. When numbers matter, it can also reproduce the complete result chain.
Not this pattern when. Use C.18 to generate candidates or maintain an Archive or Front, C.19 to change pool treatment, G.5 to declare selector-facing set results, C.11 to make a choice, and A.13 to characterize agency or autonomy. Use C.17 to report characteristics and bounded conclusions, not to generate, retain, rank, approve, fund, enact, make a service promise, classify a person as creative, measure a person's creative capacity, organize a team, or prescribe a workflow.
Do not infer a person's or System's creative capacity from a C.17 result. Strong agency can still yield a weak result, while useful scaffolding can help produce a strong result; C.17 characterizes the bearer and evidence named in the current claim.
The practitioner route
Qualitative first move
Name the bearer, comparison set, practical objective or must-criterion, observed or argued difference, supported consequence, evidence, and limitation. A useful statement can be as simple as:
Compared with the admitted five-year pump-design set, P-22's inspected split-clamp arrangement is a supported difference. The cited assembly evidence supports shorter assembly, and the design must not require new tooling. The inspection does not support claims about other pump families.
This is already a valid C.17 result for an ordinary design discussion. It does not imply a numerical Novelty value or an overall assessment occurrence.
Quantified or reusable branch
When a quantified, comparison-ready, or reusable result is needed:
- select one A.19 CharacteristicSpace and its
A.19.ECSspecification; - fix the finite comparison corpus, inclusion rule, source editions, scope, comparison window, and evidence;
- identify the objective, acceptance criterion, and must-constraints actually used;
- identify the similarity or measurement Method used and any model, encoder, distance definition, invariances, calibration, and uncertainty basis it needs;
- for each coordinate, cite an existing complete
C.16measurement result, perform and constitute the missing C.16 measurement, or state aC.2.1non-measurement ascription under its declared rule; - form only the aggregate conclusion needed by the receiving comparison;
- add an optional profile payload, representation, or record only when a named receiver needs it.
Return only the missing premise that blocks the current coordinate or conclusion. A missing measurement does not invalidate independent qualitative claims or other coordinates.
Dated overall-assessment branch
Open this branch only when the claim says that an overall assessment actually occurred and later reliance needs that fact. Recover the evaluator System through A.13, then let A.15.1 independently admit the dated Work and enacted Method. Add the exact A.2.1 assignment occurrence and F.6 relation only when later reliance expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; missing or failed F.6 leaves the assessment Work intact. Only the evaluator System performs the Work. A separate MethodDescription may explain the reusable Method; it is not enacted. Coordinate-measurement Work remains its own C.16 Work, and the aggregate result states claims.
Do not infer an A.6.1 operation application from the Method, Work, configuration, or result. If a receiving claim separately asserts an exact operation application or binding, satisfy the current A.6.1 application account and cite that application. Otherwise retain only the C.17-local evaluator System, assignment, Method enactment, dated assessment Work, coordinate results, and aggregate result that the claim actually needs.
Keep the evaluation objects distinct
Changing a space slot, corpus membership or inclusion rule, model claims or training basis, objective, criterion, constraint, Scale meaning, scope, or window reopens only the coordinate claims that depend on that change and any aggregate conclusion that uses them.
Retired predecessor heads
The following names no longer introduce root kinds:
Earlier results remain historical epistemes under their original editions. Relate an earlier and later result as editions only when both results and the continuity claim are recoverable; do not retype an old result merely because the current ontology is clearer.
Evaluation configuration
The configuration must make these questions answerable:
- Which bearer is evaluated, for which use and ClaimScope, over which selected slices and window?
- Which CharacteristicSpace and
A.19.ECSspecification supply the Characteristics, Scales, value meanings, missingness rules, and admissible comparisons? - Which finite corpus or reference set supplies the comparison basis, and how were its members admitted?
- Which Method, model, encoder, distance definition, calibration, and uncertainty basis produced or supports each value?
- If the Method compares a representation or observation instead of the bearer directly, which bearer and representation or observation are related, what describing, projection, measurement, or other stated relation supports the inference, and do the corpus members use a compatible comparison basis? If not, state the mapping and relevant loss.
- Which objective, acceptance criterion, and must-constraints are current, and which source epistemes state them? Their inclusion in the configuration does not make their claims true.
- If the result claims improvement or gain, which baseline and comparison or counterfactual Method make the difference testable?
- Which evidence supports the difference, consequence, coordinate, or comparison conclusion, and what use may rely on it?
For each objective, criterion, or constraint on which the result depends, keep its EntityOfConcern, effective ReferenceScheme, edition or currentness basis, and subject-defined predicate recoverable. Do not use a generic container label to answer several of these questions at once. Add only the source, scheme, scope, model-use, comparison, or evidence relation the current claim needs.
Keep prospective and observed readings distinct. A prospective reading may use a surrogate model and stated assumptions to compare designs before use; an observed reading uses later Work, service, or other outcome evidence. Do not overwrite the prediction as though it had been an observation. Preserve both result editions when the comparison matters, and reopen only the coordinates and conclusions that relied on the superseded prediction.
Core characteristics
Each selected characteristic has a declared Scale, polarity, admissible operations, missingness rule, and evidence route. An ordinal value is not averaged unless a declared model justifies an interval interpretation.
Novelty: unlike which admitted set?
Novelty describes supported difference from a finite comparison corpus under one declared similarity Method. When that Method returns a calibrated similarity result on [0,1] for each like-for-like comparison, that source result keeps its declared Similarity Scale. The following transformation defines a bounded value on a corresponding declared Novelty Scale, whose meaning is difference from the corpus and whose positive polarity increases as maximum similarity falls:
Novelty = 1 - max similarity(bearer, corpus member)
A declared normalization to [0,1] may be part of the Method; state its source Scale and transformation. If the Method uses another similarity or distance Scale, state the lawful coordinate construction and resulting Scale instead of reusing this formula. Subtracting an unrestricted result from one does not make it bounded.
When the Method compares representations or observations rather than the evaluated bearers themselves, name each bearer and the value actually compared, together with the describing, projection, measurement, or other stated relation that lets the comparison support the bearer-level claim. Use a compatible basis for corpus members, or state the mapping and relevant loss. A direct like-for-like comparison of epistemes needs no extra representation relation.
A robust top-k variant is allowed when declared. The result identifies the Novelty Characteristic and Scale editions, corpus and inclusion rule, source editions, comparison window, Method, model or encoder edition, distance definition, invariances, calibration, uncertainty, ClaimScope, evidence, and intended use. Changing any load-bearing element creates a different comparison basis or result edition. Those identifiers make the result reproducible; they do not by themselves show that the value is robust. When the value materially affects a comparison or pool treatment, use diagnostics suited to the claim. For example, inspect the nearest corpus members and their distances, repeat the reading with a plausible alternative corpus or similarity Method and report the sensitivity, and remove a claimed invariance to see whether it materially changes the result. These are bounded diagnostic examples, not one mandatory algorithm. If no robustness check was performed, report the supported value and uncertainty without calling it robust.
Novelty is neither timeless originality nor a property detached from its comparison basis. A label such as Novelty@context is not an executable input and must not substitute for the result chain.
Use-Value: useful for which objective?
Use-Value, historically also called ValueGain, reports the bearer's supported usefulness or contribution to one declared objective or acceptance criterion. An ordinary usefulness statement may use an ordinal Scale such as Fail | Partial | Pass; it does not need a counterfactual merely because the bearer is useful for the stated purpose.
When the result claims an improvement or gain, identify both the baseline and the comparison or counterfactual Method that makes the difference meaningful. One bounded measured construction is ValueGain = metric_after - metric_before under a fixed metric and window. An A/B comparison, back-test, or causal-inference Method may provide the comparison when it fits the claim. Cite the before and after measurements and the Work or other evidence on which they rely. A predicted gain identifies its model, error, baseline, and intended later update. Without a baseline and an appropriate comparison Method, say what usefulness is supported; do not report an observed gain.
Use-Value may be one member of a declared Q-set, but it is not the whole Q-set by default. If it stays outside Q, name its actual use as a side condition or tie-breaker. Do not silently promote Novelty, Surprise, DeltaDiversity_P, or Illumination into dominance.
Surprise: unexpected under which model?
Surprise reports how improbable one declared sample of the bearer is under one generative model. For a discrete probability, a common raw result is -log p(sample) in bits or nats. State the modeled sample unit and encoding and how bearer size is handled. Compare bearers only under a justified common extent, a declared per-unit or code-length normalization, or another calibrated rule suited to the model. For a continuous model, identify the measure as well as the representation; a density value alone is not representation-independent. Otherwise keep the raw model result within its exact basis and do not treat it as a comparable Surprise coordinate. Also identify the model episteme and edition, training basis, preprocessing, fit and out-of-distribution checks, calibration, refresh condition, and limits.
Novelty and Surprise answer different questions. A bearer may be unlike the selected corpus yet unsurprising under a broad model, or close to known examples yet surprising under a narrow model. Keep both results visible when both matter.
ConstraintFit: which must-criteria hold?
ConstraintFit reports satisfaction of the declared must-constraints under their predicates and source epistemes. Use E.5, D.1-D.5, or a service-acceptance pattern only when it supplies the actual predicate or source for the current must-criterion. A ratio such as passed declared must-constraints / all declared must-constraints is allowed when the set and any criticality weights are explicit.
A failing must-constraint makes the bearer ineligible for the affected use unless the receiving constraint or decision pattern recognizes an independently obtaining exception or waiver effect. A waiver speech act alone does not change eligibility. If no pattern defines the needed effect, return the missing relation rather than treating communication as authorization.
AttributionIntegrity
AttributionIntegrity reports how completely the applicable provenance, authorship, source, and licence duties are met. First identify the duty set and the source that makes each duty applicable. One bounded local construction is satisfied required duties / all applicable required duties on a declared ratio Scale; mark unresolved and inapplicable duties separately rather than treating them as satisfied. Provenance links, licence scans, and acknowledgements are example evidence routes.
When the applicable-duty set is empty, do not compute the ratio. Omit AttributionIntegrity when the receiving use does not need it; when that use needs an explicit disposition, return not applicable under the declared Scale and missingness rule. That disposition is not a pass and cannot by itself pass a filter, break a tie, establish legal adequacy, or satisfy a must-constraint. Keep it distinct from an unresolved duty that does apply.
This reading does not by itself establish legal adequacy. It is measurable but not in the default dominance set; an applicable policy may use it as a filter or tie-breaker. When a duty is a must-constraint, its pass or failure belongs in ConstraintFit and affects eligibility there.
EffortCost
EffortCost reports actual resource outlay through A.15.1 dated Work, B.1.6 resource aggregation, C.16 measurement, and A.10 evidence. Planned effort remains A.15.2 WorkPlan content. Use cost-normalized readings for planning or comparison only under a declared rule; cost is not itself creativity, and a profile does not carry operational actuals.
Retained-set and optional applied readings
Diversity and illumination
Diversity_P describes coverage or dispersion of one declared retained set under a named measurement policy. A local policy may, for example:
- take the average pairwise distance among the admitted members under one declared descriptor map, distance Method, and Scale; or
- report how much of a declared feature partition is covered, using a stated covering radius or k-cover rule.
Neither construction is universal. The result identifies the retained set and membership rule, measurement-policy and Scale editions, descriptor or feature source editions, distance or covering definition, comparison window, and evidence. A distance matrix or coverage map can show the calculation. When the reading affects a decision, vary a plausible kernel, distance definition, covering threshold, or admitted-member set and report whether the conclusion changes.
For a candidate h and retained set S, the same local policy may use the marginal reading DeltaDiversity_P, also written ΔDiversity_P:
DeltaDiversity_P(h | S) = Diversity_P(S plus h) - Diversity_P(S)
Illumination is a report over Diversity_P, such as a coverage map or QD-score summary. It is telemetry, not a primitive characteristic and not part of the default dominance set. Use C.18 to maintain an Archive or Front and C.19 to state any pool policy that uses these readings.
Optional retained-set readings include:
FamilyCoverage: coverage of locally defined families under a named policy and Scale;MinInterFamilyDistance: the smallest distance among declared families, with descriptor map, distance definition, Scale, and family-representation rule;AliasRisk: a near-duplicate or alias diagnostic with collision policy, descriptor source edition, and Scale;DescriptorVector: an optional descriptor payload whose dimensions and interpretation the same local policy declares.
These readings characterize the named set. They do not admit sources, select members, establish universality, or widen applicability. For naming candidate sets, apply F.18's head-term-family anti-inflation rule rather than restating that lexical rule here.
Optional applied characteristics
The following are executable local examples, not required universal templates. Use one only when the receiving question needs it and identify its bearer, rule, Scale, and evidence.
ReframeDelta. The bearer is an ordered pair of problem-frame epistemes. One local rule compares the earlier and later frame on an ordinal Scale such asNone | Local | BoundaryShift | Systemic; a boundary or scope diff and a changed causal map support the reading. The frame change does not by itself prove improvement, so state Use-Value separately.Compositionality. The bearer is the design or episteme being assessed. One local rule requires reuse of at least a declared number of components and evidence of at least one new relation among them; it may return a boolean plus a separately defined structure reading. Cite the component graph and component provenance.Transferability. The bearer is the design, result, or episteme whose use is tested in one named receiving setting. One local ordinal Scale isnot supported | supported with stated loss | supported for the stated use. Cite receiving-use pilot evidence and the preserved and lost meaning; use an F.9 Bridge only when a relation between different reference-scheme senses actually obtains.DiversityOfSearch. The bearer is a finite set of dated Work attempts. Count distinct approach classes under a declared local typology, optionally as a rate over a stated time window, and cite the tagged Work and typology. Cosmetic variants do not create new classes.Time-to-First-Viable. The bearer is one Work episode. Measure elapsed time from a declared start to the first dated result that passes the stated viability criterion; cite the timestamps and passing evidence. If no result passed, reportnot yet obtainedor a right-censored duration rather than the time to the first runnable output.Risk-BudgetedExperimentation. Compare the applicable WorkPlan with the resulting dated Work set. One local rule reports planned exploratory resource use divided by the allowed risk budget and the realized ratio separately, with any overrun visible. Cite the WorkPlan, actual Work, and resource evidence; the reading does not grant the budget or authorize the Work.
These examples do not create another universal characteristic family. Readings about actual attempts, elapsed time, or realized experimentation depend on dated Work; planned experimentation depends on a WorkPlan.
Other domain characteristics
The six applied readings above are examples, not the extension boundary. A configuration may select other Characteristics already established for the current use—for example, time or cost to probe, evidence sufficiency, safety or ethical risk, option value, or regret risk. Keep each selected Characteristic's bearer, Scale, polarity, defining source, Method, and evidence. A safety or ethical must remains an eligibility condition through ConstraintFit; evidence sufficiency does not become creativity; and scope does not become another coordinate merely because every claim needs one.
When one comparison covers several components, attempts, or Work occurrences, identify the lawful aggregation separately for each Characteristic. For example, compatible costs may sum, all declared must-constraints may have to pass, a domain risk rule may use its own conservative combination, and evidence may follow an applicable B.3 relation. These are examples, not C.17 defaults. If no declared aggregation supports the combined reading, keep the component results separate.
Any prior or default used for Novelty, evidence, risk, or another selected reading remains a separately supported model or policy claim with its source and edition. C.17 does not publish domain priors merely because a reusable configuration is convenient.
Results, profiles, and assessment Work
Coordinate claims
For each selected characteristic, choose one truthful route:
- cite an already constituted
C.16measurement-result episteme and its complete measurand, Characteristic, Scale, Method, application, dated measurement Work, bindings, time, uncertainty, and evidence chain; - if the current action measures the coordinate, constitute that complete C.16 chain before using the value;
- if the claim applies a declared criterion without measuring, state a
C.2.1ascription and its rule.
A numeric model output, criterion label, dashboard cell, or formula alone is not a measurement result.
Aggregate result
CreativityEvaluationResult is one bounded C.2.1 episteme about the bearer. Its ClaimGraph cites the selected coordinate claims, CharacteristicSpace and specification, scope, use, window, evidence, current eligibility consequence, and any frontier or incomparability conclusion. It is not an arithmetic total and does not create a universal creativity kind.
The result may say that a bearer is eligible for one comparison, incomparable on a missing coordinate, or non-dominated within one declared set. It does not choose, approve, publish, retain, or enact the bearer.
Optional payload, record, and rendering
Use CreativityProfile only as the local name for the optional non-arithmetic payload of coordinate-claim references, their arrangement, and current frontier or incomparability annotation. A table, chart, or dashboard is a separate representation. A CreativityEvaluationRecord is a separate optional episteme that packages references for a named receiver.
Do not alternate among result, profile, record, and dashboard as if they were synonyms.
Comparison, gates, and selection boundary
- Never use Novelty alone to approve or prefer a bearer. Pair it with Use-Value or the relevant ConstraintFit gate.
- State the selected characteristic subset, polarities, eligibility conditions, and comparability basis of every dominance claim.
- Preserve partial orders and incomparability. A Pareto or constraint-bounded Front follows from the declared rule; a visually pleasing hull is not a frontier.
- Do not force one scalar creativity score. If a receiving policy uses an index, publish its weights or curves, admissible transformations, uncertainty treatment, sensitivity, and drift rule while keeping the primitive coordinates queryable.
- Do not average ordinal Scales without an accepted model that supports the conversion.
- A result may state a frontier relation over a declared set. Use
C.18to maintain the current Front and Archive,C.19to state pool treatment and tie-break policy,G.5to declare selector-facing results, andC.11to make the choice.
Evidence, uncertainty, and resistance to gaming
Every quantitative result names its evidence, calibration, uncertainty, and validity window. Keep aleatory and epistemic uncertainty separate and state any rule that combines them. A claim imported from another source or scale states the preserved meaning, lost meaning, direction, receiving use, and evidence limit; use F.9 only when an actual Bridge between reference-scheme senses is needed.
Apply these anti-Goodhart guards:
- pair Novelty with Use-Value or ConstraintFit;
- freeze the comparison corpus, encoder or model, and Scale edition for the result; a load-bearing change creates a new result basis;
- keep Illumination as telemetry unless an explicit policy promotes it for a named use;
- check delayed practical consequences, such as retention, maintenance burden, or cost-to-serve, before celebrating a proxy win;
- connect
DiversityOfSearchto the declared experimentation allowance and report overspend; - retain primitive coordinates and sensitivity when a composite index is used.
When a corpus, inclusion rule, model, encoder, Scale, criterion, window, or cross-source premise changes, leave a compact change account: the previous and new editions, what changed in the basis, which coordinates and aggregate conclusions reopen, whether eligibility or frontier membership changed, and which next observation can settle the difference. Latest is not a reproducible selector. Use B.4 and G.11 for the refresh; the change account explains the comparison and does not replace the new result.
Goodhart's law is a useful historical warning, not evidence for any result. The safeguards above do the operational work.
Evidence can support a result without establishing assurance. Ordinary use stops with proportionate evidence. Enter B.3 only when the receiving assurance claim or material-reliance threshold requires it.
When that receiving use requires independent assessment or segregation of duties, name the Systems that performed any bearer-producing, coordinate-measurement, or overall-assessment Work and the assignments relevant to the independence claim. State the relevant conflict or independence evidence. Do not impose this assurance arrangement on an ordinary qualitative discussion that makes no independence claim.
Cross-scale and cross-source limits
When a reading moves across scales, state which Characteristics are preserved, aggregated, projected, or lost and cite the actual aggregation, projection, transition, temporal cross-scale, or Bridge relation on which the reading depends. Keep a plain distortion note next to the projection. If the receiving use needs the named A.0 qualifier structure, use A.0:QF.2a and its optional OutcomeMapRef, TransitionRelationRef, or BridgeDistortionNote; otherwise the plain loss statement is enough.
Different projections of the same retained set or frontier may preserve different information. A useful projection is not automatically information-preserving, and one atlas-like view does not cancel the original Front, Archive, or result.
When claims come from different source schemes or corpora, do not compare by matching labels. State the actual mapping, Bridge when required, direction, loss, calibration, and receiving use. A target-use pilot may improve evidence for that use; it does not make the source and target bases identical.
Worked cases
Pump design: stop early or open the measurement branch
Identify P-22 as the exact design episteme. Compared with the admitted five-year pump-design set, its inspected split-clamp arrangement is a supported difference. Assembly evidence supports shorter assembly, and the candidate must not require new tooling. State what was inspected and the limit of that support. Stop here when the discussion needs neither a quantified coordinate nor a reusable result.
To use Novelty value 0.42, cite P22-NoveltyResult-4, an already constituted C.16 measurement-result episteme. Its chain identifies P-22 as measurand, the Novelty Characteristic and Scale, exact similarity Method, the calibrated [0,1] CAD-graph similarity result used by the declared Novelty construction, encoder and model edition, uncertainty, dated measurement Work, actual bindings, time, and evidence. The Method compares P22-CADGraph-7, produced from and representing P-22 under CADGraphProjection-2, with graphs produced by the same projection for every corpus design; the result states that this projection omits surface finish and manufacturing tolerances. If the current action measures novelty, constitute that chain first. State the no-tooling-change coordinate as a C.2.1 ascription under its declared criterion unless it was independently measured.
One CreativityEvaluationResult may cite those coordinates and state only that P-22 is eligible for the current comparison and lies on the declared non-dominated set. Building that result does not assert separate overall-assessment Work.
If an audit later asserts that an overall assessment occurred, identify the evaluator System, its exact assignment, PumpCreativityAssessment-17 Work, and PumpCreativityAssessmentMethod-2; state that the Work enacts the Method. The MethodDescription explains the Method, the result states claims, and coordinate-measurement Work stays separate. Do not add an A.6.1 operation application merely because those values are recorded. If the audit separately asserts an exact operation application or binding, satisfy the current A.6.1 application account and cite that application.
Software and algorithmic design
Software design. In this worked example, ETL-Parallel-12 is compared with 40 admitted internal pipeline designs through ASTGraphSimilarity-3, whose declared Novelty construction uses calibrated [0,1] similarities. The Method compares AST-graph representations produced by the same declared parser and projection for the evaluated design and every corpus design; the result states that runtime configuration and deployment topology are not preserved by that projection. Its Novelty result is 0.36. A fixed-workload benchmark reports an 18% lower p95 latency than the serial baseline, but the segregation-of-duties test fails. The benchmark run, corpus edition, nearest-neighbour report, and policy test are the evidence. The result therefore supports a latency gain but leaves the design ineligible for the stated use; redesign the isolation boundary and repeat the affected tests before any pool or choice decision.
Algorithmic search Work. SpikeSet-7 contains nine dated attempts in three declared approach classes over six hours. Tagged Work records support DiversityOfSearch = 3 classes; the first runnable output appeared after 2 h 10 m. The held-out viability test was never run, so Time-to-First-Viable is not established. The practical action is to run that test, not to relabel time-to-first-runnable as viability.
Health analytics
For Cardio-Readmit-H4, the held-out AUROC is 0.79 against a 0.75 baseline under the frozen test set, clearing the declared uplift threshold of 0.03. The model card, held-out plot, and evaluation Work support that local Use-Value result. No receiving-use pilot has yet been performed at Hospital B, so Transferability there remains unsupported. Use the local result for the applicable pool or choice question, but leave the target-hospital claim open until pilot evidence exists. Use an F.9 Bridge only if the two hospitals' reference schemes require one.
Product reframing
OnboardingFrame-v1 treats onboarding as one completion task; OnboardingFrame-v2 separates job setup from obtaining the first result. The declared ReframeDelta rule returns BoundaryShift, supported by the frame diff and a simpler causal map. In a four-week A/B comparison, v2 reduces median time-to-value by 22% against the control baseline, clearing the 20% objective. Exploratory Work used 9 of the 12 allowed staff-days, so the realized risk-budget ratio is 0.75 with no overrun. The frame diff, A/B report, WorkPlan, and Work records support the result. This evidence can inform the later choice; it does not make the choice.
Scientific and policy proposals
Scientific proposal. ScalingRelation-S4 has Novelty 0.61 from the declared calibrated [0,1] similarity construction relative to the admitted literature corpus. The Novelty Method compares one text embedding that describes the proposal with embeddings produced by the same encoder for every corpus paper; the result names that projection and states that notation and experimental detail may be lost. Its Surprise is 4.1 bits per token under PriorModel-2, using the same versioned tokenizer and abstract-text sample unit for the proposal and model basis; the per-token normalization handles text length but does not support a claim about equations or full papers. The corpus, neighbour report, model calibration, and derivation evidence support those coordinates, but independent replication is missing. Report the proposal as a preliminary bounded result and seek replication before a reliance claim.
Policy proposal. In a municipal permit-triage pilot, Policy-P8 reduces median processing time by 12% against the prior-procedure baseline and passes the declared legal-form test. Subgroup error evidence required by the equity must-criterion is missing, so ConstraintFit and eligibility are not established. Keep the proposal out of an approval-facing comparison until the subgroup test is complete; the time result remains usable for its narrower operational question.
Manager quick start
- Name the bearer, comparison corpus, objective, and must-criteria.
- State the smallest supported difference and consequence; stop if that answers the question.
- When numbers matter, select the space and specification and build each coordinate through C.16 or C.2.1.
- Compare with declared gates and a partial order; keep incomparability visible. When a retained set matters, report its declared
Diversity_Por other needed set reading without turning that reading into selection policy. - Pass any generation, retention, policy, or choice question to C.18, C.19, G.5, or C.11 with the result references they need.
Optional one-page comparison brief
When several people must reuse the same comparison, publish one short view containing only the fields they need:
- the working question, bearer, intended use, and stop;
- the finite corpus or reference set, inclusion rule, source editions, and window;
- the selected Characteristics, Scales, polarities, admissible operations, and missingness rules;
- the objective, must-criteria, eligibility consequence, and their sources;
- the Methods, models or priors actually used, with calibration, uncertainty, and evidence;
- the coordinate-result references and any declared set, frontier, or incomparability statement;
- the applicable C.19 policy, G.5 declaration, or C.11 choice reference when later work relies on one; and
- the basis-change and reopen condition when editions or evidence change.
This brief is a representation of the selected configuration and results. It does not create a result, policy, choice, WorkPlan, prior, or domain default. Put a reusable transform or objective form in the pattern that defines it and cite that definition here; do not make the brief a second source of the rule.
Conformance checklist
Common failures and repairs
Consequences
Benefits. Teams can discuss novelty and value before building a metric stack; stronger results remain reproducible and comparable; trade-offs and incomparability stay visible; and generation, policy, choice, Work, evidence, and publication keep their own boundaries. No particular tool or rendering is required: an implementation is suitable when it preserves the declared configuration, result chain, evidence, and limits.
Costs. Quantified claims require a fixed corpus, explicit Scales and Methods, evidence, uncertainty, and edition discipline. Cross-source and cross-scale comparisons sometimes remain incomparable.
Limits. A C.17 result does not prove that a bearer is good, authorize Work, define universal novelty, supply a selection policy, or establish assurance. It makes the bounded claims and their dependencies inspectable.
SoTA-Echoing and source use
Source-currentness boundary (reviewed through 2026-08-15). The sources below were selected because they change what a C.17 user inspects or reports. They do not install one creativity theory, automated judge, metric, or search algorithm as the FPF default. Reopen this source-use judgement when a cited source is corrected, retracted, or materially superseded; when new cross-domain evidence overturns one of the stated consequences; or when a proposal would make one automated metric, corpus, encoder, QD descriptor, or proxy score normative. Use G.11 for that refresh.
These decisions reinforce the existing route rather than add another assurance layer. In the pump case, inspect the admitted design set and tooling constraint; in the hospital case, keep the held-out result separate from unsupported transfer; in the policy case, keep the missing subgroup evidence as an eligibility gap. The source record therefore changes the comparison and robustness work already required by the cases and checklist, not the practitioner-first entry.
Open questions
The following are research questions, not current requirements:
- Under what evidence can a domain justify a stable distance across several creativity Characteristics without hiding their different Scales?
- How can several agents' partial frontiers be related without importing team-governance assumptions or forcing one scalar objective?
- What evidence is sufficient to treat an ordinal reading as interval-like for one declared frontier-estimation use?
- Which delayed observations best reveal when Novelty, Use-Value, or Illumination has become a gamed proxy?
Relations
- Builds on:
A.17,A.18,A.19,A.19.ECS,C.16,C.2.1,A.1.1,A.10, andB.3. - Coordinates with:
E.10.LRNfor ambiguous learning-family wording,A.13for exact evaluator recovery and any separate agency or autonomy claim,F.9for an actual Bridge,F.18for lexical candidate-family diversity,A.0:QF.2afor an optional structured cross-scale qualifier,B.4andG.11for evolution and refresh,A.15.1,A.15.2,B.1.6,A.3.1, andA.3.2for Work, plans, resources, and Method descriptions,A.2.1andF.6only for an expressly consumed precise assignment-bound attribution, andA.6.1only for a separately claimed application of one exact declared Mechanism operation. - Supplies results to:
C.18,C.19, andG.5for their exact set-side questions,C.11.CRConly when one finite configuration-relative comparison is missing, andC.11for choice, without taking over generation, set stewardship, pool policy, comparison, declaration, or choice.
C.17:End
Open-Ended Search Archive and Front Stewardship
Tech-name:
OpenEndedSearchArchiveAndFrontStewardshipPlain-name: open-ended search archive and front stewardship Type: C-pattern Status: Stable Normativity: Normative unless explicitly marked informative Placement: Part C Builds on:C.16,A.19.CPM,A.19.SelectorMechanism, andE.18. Coordinates with:C.19,C.11.CRC,C.11,C.28,G.5,G.9,G.11,E.23,E.18.1,E.17,E.24.PUB, theC.30family,C.32.P2S,C.32,C.35,C.36,F.17,F.18,F.9, and the A.15 family. Purpose: make archive, front, Q-front, descriptor, telemetry, retained exploration value, stepping-stone value, lineage, edition, architecture-candidate generation, and cultural-variant generation usable without turning them into publication, decision, work permission, or cultural-evolution authority.
Use This When
Use this pattern when a project needs to generate, retain, compare, or report many candidate variants while preserving descriptor editions, distance definitions, archive policies, front semantics, telemetry, lineage, retained exploration value, and any action-bearing claim that generation stayed inside or changed the effective possibility space.
Typical cases include quality-diversity archives, open-ended engineering variant sets, Pareto or Q-front treatment, phenotype-like descriptor maps, architecture-candidate generation, style or tradition variant generation, scientific or engineering school variants, and candidate pools whose value is not captured by one immediate selected set.
What Goes Wrong If Missed
The project treats an archive as a shortlist, a front as a decision, illumination telemetry as dominance, a retained stepping stone as current best, or a cultural-style variant as a root cultural kind. Generation looks productive, but the next relation is unclear—for example, whether to retain, compare, declare a selected-set result, choose locally, plan work, measure effects, refresh, or write a cultural-evolution case.
What This Buys
The practitioner gets separate records for archive, front, and generation. Each record pins descriptors, characteristic spaces, edition refs, retention policy, telemetry, lineage, and next governing relation. Downstream selection, architecture, cultural evolution, work planning, measurement, and refresh then start from named records rather than from a broad archive label.
Problem Frame
Open-ended search and quality-diversity work deliberately keep more than one candidate alive. That is useful for engineering, science, design, music, dance, AI-agent frameworks, medical method families, and other evolving practices. The same archive or front label can hide strong candidates, weak but promising stepping stones, coverage-expanding variants, architecture candidates, cultural variants, and telemetry-only signals.
The primary EntityOfConcern in C.18 is the archive or front relation being stewarded: which variants are generated or retained, under which descriptor and characteristic space, with which edition and lineage pins, and with which next relation available. C.18 does not answer a local-choice, selector-result declaration, cultural-evolution, or architecture question.
Problem
Without C.18, a team often compresses several different objects into one word such as archive, front, Q-front, portfolio, style pool, or candidate set. That loses four distinctions:
- a front answers current non-domination under a declared comparator or dominance set;
- an archive answers retained exploration value, coverage, stepping-stone value, or future reachability under a declared retention policy;
- telemetry reports search health, coverage, novelty, diversity, or lineage but does not by itself dominate alternatives;
- use
G.5for downstream selected-set result declaration,C.11for local choice, the applicableC.30orC.32pattern for an architecture claim or candidate,C.36for cultural-evolution case work,A.15.2for planning,A.15.1for performed Work, andG.11for currentness and refresh.
Forces
Solution
Keep archive, front, telemetry, generation, and downstream relations as separate records.
Archive Record
Use this record when the current question is about archive use—for example, retained exploration value, coverage, novelty, diversity, stepping-stone value, future reachability, curriculum expansion, lineage, or archive policy. Do not use the archive record as a selected-set result declaration or work permission.
Front Record
Use this record when the current question is about front use—for example, non-domination, Pareto relation, Q-front membership, comparator currentness, admissibility, or partial-order preservation. The front may feed a later G.5 use, but it is not itself a declared selected-set result; declare that result from the front through [G.5](/generated/patterns/G.5) under its own basis.
Filled Archive And Front Micro-Records
For this example's current question, the field names [C.36](/generated/patterns/C.36) as the next applicable pattern. If one of the stated changes makes refresh current, [G.11](/generated/patterns/G.11) becomes the next applicable pattern instead; it is not a second simultaneous locator.
For this example's current question, the field names [C.30](/generated/patterns/C.30) as the next applicable pattern. Omit selectedSetResultRef? until an exact G.5 result exists. If declaring a selector outcome later becomes current, start a separate [G.5](/generated/patterns/G.5) use; if the front's basis changes, start [G.11](/generated/patterns/G.11) refresh. Neither possible continuation belongs in the current locator.
Generation And Downstream-Use Record
When loop-engineering practice generates many candidates—for example, agent prompts, harness variants, workflow variants, or framework seeds—use C.18 to record generation, archive, front, descriptors, telemetry, retained exploration value, lineage, and the next applicable pattern. This does not say that the loop improved. Use E.23 only when one retained object version is changed and re-evaluated; use G.9 for parity between variants and G.5 when a selected-set result must be declared.
Across the archive, front, and generation records, currentnessAsOf names the replay date or window together with the relevant pinned editions; currentStatus states whether the recorded archive/front/generation relation is active, held, closed, or stale for its declared use; and stopOrRefreshReason names the condition that ended it or the exact trigger that would reopen its currentness. These fields record the boundary but do not perform refresh. When source, descriptor, comparator, policy, evidence, or edition currentness becomes the live question, nextGoverningRelation points to [G.11](/generated/patterns/G.11) and refreshRef? may cite the separately governed refresh record.
Here @Project is a compatibility and retrieval cue, not a project kind or relation assertion. Fill projectLocality? only after both Work occurrences have been admitted independently and the cited relation actually obtains under its direct governor. generationWorkOccurrenceRef names the exact dated generation U.Work; compositeProjectWorkOccurrenceRef names the selected composite project U.Work; and exactGenerationToProjectRelationRef cites, rather than creates, the exact work-part, containing-work, decision-use, source-use, or other governed relation. Use work parthood only when the complete [A.15.1](/generated/patterns/A.15.1) basis holds. Otherwise omit projectLocality?: the @Project suffix remains retrieval-only and establishes no project Work, parthood, authority, context, or viewpoint.
For example, a completed harness-generation run may state:
Every optional field whose name ends in Ref? points to a separately identified object, claim, policy profile, or measurement basis. dedupThreshold? is not a reference: it carries one declared scalar threshold value. deduplicationUnit? carries its unit literal. Fill emitterPolicyRef? and insertionPolicyRef? only when the cited C.19 profile or insertion policy applies to the current pool treatment. When a threshold is inherited, the cited profile supplies dedupThreshold, deduplicationBasisRef, and deduplicationUnit; when it is not inherited, carry the scalar in dedupThreshold? and its basis and unit in deduplicationBasisRef? and deduplicationUnit?. These references and scalars do not give C.19 a generation operation or change the archive and front relations stated through C.18. In particular, problemCardRef? may cite a C.22.2 problem-side episteme but creates neither an actual Problem nor a ProblematicForRelation under [C.22.PFR](/generated/patterns/C.22.PFR). A generated variant, archive entry, front membership, telemetry value, or retained-exploration claim is neither an improvement-result nor a work-result identity and creates no relation from generation Work to a result. nextGoverningRelation is a locator for the next applicable pattern; it does not itself make a choice, declare a selected-set result, authorize work, perform refresh, or make any relation obtain.
Use this record when generation is current. architectureCandidateRefs become architecture moves only through [C.30](/generated/patterns/C.30), [C.30.ASV](/generated/patterns/C.30.ASV), or [C.30.AD](/generated/patterns/C.30.AD). culturalVariantRefs become cultural-evolution cases only through [C.36](/generated/patterns/C.36). Local choice uses [C.11](/generated/patterns/C.11); work planning and performed work use the A.15 family; effect measurement uses its direct measurement and evaluation patterns; refresh uses [G.11](/generated/patterns/G.11). P2W carry-through uses [E.18.1](/generated/patterns/E.18.1) when an accepted problem-side distinction must be preserved into the next relation.
Distinguish exploration inside a space from change to the space
Apply this branch only when whether the effective possibility space changed can alter retention, comparison, generation, architecture, or the next decision. Start by declaring the current space through the candidate grammar or type boundary, generator and operators, available building blocks, evaluator or comparator, retention or reproduction rule, goals or actions, and environment that matter for this case. The declaration may be ordinary domain content or a cited description; it does not create a universal PossibilitySpace kind.
Then state the smallest supported mode:
The first result is one ordinary C.2.1 claim naming the earlier and candidate space declarations, exact changed component, mode wording, counterfactual or trajectory evidence, uncertainty, blocked stronger claim, and next governing relation. Use C.28 for a causal claim that the component change produced the new reachability. Use C.11.CRC when a finite space-changing intervention must be compared with the current configuration, and C.11 for the later choice.
Stop at ordinary same-space exploration when no action depends on the stronger mode. Reopen only when the candidate grammar, generator, operator set, evaluator, retention/reproduction rule, goals/actions, environment, evidence, or receiving decision changes.
Worked micro-case. A cooling-module search previously admits only fixed rectangular layouts assembled by the same connection operators and evaluated under the same thermal/maintainability comparator. A new layout far from the archive remains exploratory if those rules still admit it. Adding a validated curved-channel building block and operator is expansive only when the earlier generator could not express the resulting layouts and the comparison still uses a compatible higher-order regime. Replacing candidate admission and retention with a context-adaptive rule that changes which successors count is transformational only when the earlier/candidate rule mapping and observed reachability support that stronger claim. A higher novelty score alone establishes none of these transitions.
Front And Archive Are Different Returns
- Start from one declared candidate or eligibility set.
- Return the non-dominated front over the declared comparator, dominance set, or relation-token set.
- Return the exploration archive separately when retained exploration value, coverage, novelty, diversity, stepping-stone value, or future reachability is current.
- Keep tie-breakers and telemetry explicit so diversity, illumination, or popularity signals do not rewrite front semantics.
- Before promoting telemetry or a popularity-like signal into the comparator, dominance set, or selected-set criteria, state which intended archive/front use or value becomes worse when that signal improves and cite the policy or decision authority that admits the trade-off. If either answer is missing, keep the signal as telemetry or an explicitly bounded tie-breaker rather than silently promoting it.
- Use
RetentionIntent=steppingStonewhen retention exists for frontier expansion or later curriculum value rather than current dominance. - If one source line keeps both returns, say that the front answers current non-domination while the archive answers retained exploration value.
Cultural And Architecture Variant Boundaries
For architecture-candidate generation, C.18 records generation, archive, front, descriptor, telemetry, and retained exploration value. C.30 governs the architecture claim: ArchitectureOf@Context, selected structure or structure kind, affected characteristic, and next architecture move.
For cultural variants, C.18 records the generated or retained variant set and its descriptors, lineage, telemetry, and archive or front relation. Use C.36 for a cultural-evolution case when collective-holon or discipline-facing Method, Work, system-role kind or assignment, canon, memory, recognition, selection, mediation, style, tradition, or intervention relations are current. Use F.17, F.18, and F.9 for durable term and bridge work for labels such as style, tradition, genre, scene, school, and technique.
Conformance Checklist
CC-C18-1Descriptor, characteristic, distance, and family-coordinate refs are named before generation, archive update, or front publication.CC-C18-2Archive and front returns are separate from a selected-set result unless one is explicitly declared from them throughG.5.CC-C18-3Telemetry remains telemetry unless a declared policy promotes it into the comparator, dominance set, or selected-set criteria and the governing record names both the intended archive/front use or value made worse by that promotion and the authority that admits the trade-off.CC-C18-4Retained exploration value, stepping-stone use, lineage, and edition pins are recorded for archive use.CC-C18-5Architecture candidates use C.30 family patterns before becoming architecture moves.CC-C18-6Cultural variants use C.36 or term-bridge patterns before becoming cultural-evolution claims.CC-C18-7Refresh usesG.11with the smallest affected archive, front, descriptor, edition, or lineage locus.CC-C18-8Agent-loop, harness-loop, workflow-store, or DPF-seed variants retained in an archive name their descriptor, lineage, telemetry, and next governing relation; archive membership does not claim quality improvement withoutE.23re-evaluation.CC-C18-9A filledprojectLocality?names independently admitted dated generation and composite projectU.Workoccurrences, the subject pattern, and one exact obtaining relation;@Projectalone remains retrieval-only.CC-C18-10Problem-card, result, selected-set, choice, work, and refresh references remain references to separately governed objects or next subject patterns and create none of those identities or relations.CC-C18-11The SoTA basis names its reviewed-through boundary and exact mutable editions; a material source revision, newer field survey, or contrary archive, descriptor-generalization, or OEE-evaluation evidence records a reopen trigger and hands refresh toG.11.CC-C18-12Any exploratory, expansive, or transformational wording names the earlier and candidate effective space declarations, changed component, counterfactual or trajectory evidence, uncertainty, blocked stronger claim, and next relation; distance, rarity, novelty, or local progress alone does not prove space change.
Archetypal Grounding
System-facing case. A robotics team generates gait variants. The front records non-dominated speed and energy relations under declared measures. The archive retains diverse coordination patterns because some are stepping stones for new terrain. Telemetry reports coverage. A selected-set result may later be declared through G.5. If it must be available to an audience, use E.17 for its source-backed publication face and return to source and E.24.PUB for the publication occurrence and availability. Performed test runs use A.15.
Architecture case. A cooling-module project keeps an archive of modular layout variants and a front over maintainability and energy use. C.18 records descriptors, archive policy, front relation, and telemetry. C.30 decides whether any retained variant becomes an architecture move by naming the selected structure and affected architecture characteristic.
Cultural case. A dance-lab project generates movement variants around several source labels. C.18 records generated variants, descriptors, archive membership, front relation, and lineage. C.36 decides whether the lab is deliberately changing a cultural-evolution case; F.17, F.18, and F.9 handle the label bridges.
Bias-Annotation
Lexical and semiotic bias are controlled by keeping archive, front, telemetry, selected-set result declaration, audience publication, local choice, cultural-evolution case, architecture move, work permission, and evidence relations distinct. Mathematical descriptions of descriptor maps, fronts, distances, coverage, or novelty use the mathematical-lens pattern when lens adequacy matters.
Consequences
Positive consequences:
- archives keep exploration value without pretending to decide;
- fronts preserve partial-order and comparator semantics;
- architecture and cultural-variant generation become usable without creating parallel root kinds;
- refresh and source-currentness have clear loci.
Costs:
- teams must keep at least archive and front records separate;
- one generated variant may need several downstream records before it becomes selected, chosen, planned, worked, measured, or refreshed;
- descriptor editions and distance definitions require maintenance.
Rationale
Current quality-diversity, illumination search, open-ended engineering, and evolutionary-engineering practice shows that retained diversity, stepping stones, archive lineage, and descriptor currentness often matter before a single choice is justified. FPF keeps that practical gain while preventing archive and front language from replacing comparison, selected-set result declaration, audience publication, architecture, cultural evolution, work, evidence, decision, or refresh patterns.
SoTA-Echoing
Source-currentness boundary. This source-use basis was reviewed through 2026-08-26. Mutable preprints are pinned below to the edition actually used; the Qin et al. survey is pinned to its DOI-fixed journal article. Reopen the affected source-use row through G.11 when a cited revision changes the archive, front, generation, or evaluation claim used here; when a newer field survey materially changes the known QD/OEE boundary; or when contrary evidence changes what can be claimed about bounded archives, descriptor generalization, or open-ended evaluation. C.18 records that trigger and the affected row but does not itself perform refresh.
Relations
Builds on: C.16, A.19.CPM, A.19.SelectorMechanism, and E.18.
Coordinates with: C.19 for current-pool treatment, C.11.CRC for a finite configuration-relative comparison, C.11 for local choice, C.28 for causal support of a space-change claim, G.5 for selected-set result declaration, E.17 and E.24.PUB for actual audience availability, G.9 for parity and benchmark comparison, G.11 for refresh, E.23 when an archived object version enters a declared quality-improvement loop, E.18.1 for P2W carry-through, C.30 family, C.32.P2S, C.32, and C.35 for architecture candidates, problem-to-structure carry-through, candidate palette admission, and generated or discovered carrier adequacy before archive or front use, C.36 for cultural-evolution cases, F.17, F.18, and F.9 for term and bridge work, and the A.15 family for planning or performed work.
C.18:End
Scaling‑Law Lens Binding (SLL)
Status: Stable Type: Pattern
Use this pattern when. Use C.18.1 when a generator, selector, method family, benchmark, or comparison claims that behavior changes with scale, budget, data, model capacity, iteration budget, freedom of action, or another monotone scale variable.
What goes wrong if missed. Teams compare unequal budgets, call coverage telemetry an objective, claim a knee without probe evidence, or assume more scale means linear improvement across a window where the behavior has already changed.
What this buys. A compact scale-law lens: declare the scale variables, ScaleWindow, probe points, elasticity class, parity notes, and policy thresholds before treating a scale claim as usable in selection, parity, refresh, shipping, or mathematical-lens work.
One‑screen purpose (manager‑first). Make generation/selection scale‑savvy: at the level of conceptual descriptors, declare (a) which monotone knobs we would scale, (b) the ScaleWindow over which we claim behaviour, and (c) the elasticity class we observed—without imposing numeric fits or vendor tools at Core level. This surfaces knees early and keeps comparisons lawful and fair across families. (Parity is handled by G.9; illumination remains a report-only telemetry unless a CAL policy promotes it.)
Builds on. C.16 (MM‑CHR), C.17 (Creativity‑CHR), and C.18 (NQD‑CAL); resource-use and work-cost claims use A.15.1, A.15.2, B.1.6, C.16, and A.10 as applicable. Planned C.5 (Resrc-CAL) may later consolidate that guidance but supplies no current governing semantics. Coordinates with. C.19 (E/E‑LOG), G.5 (Selector & Registry), G.9 (Parity Harness), G.10 (Shipping), G.11 (Refresh‑Telemetry), C.24 (Agent‑Tools‑CAL). Keywords. scaling law; Scale Variables (S); ScaleWindow; knee; diminishing returns; iso‑scale parity; UNM/NormalizationMethod‑based mapping; scale‑probe; DoE (design‑of‑experiments); segmented regression; knee detection.
Problem frame
Teams often say a method “scales” without disclosing which resources, across what window, and how outcomes respond (convex rise → knee → plateau). Without that, parity is skewed (unequal budgets, unmatched windows), coverage/illumination report-metrics leak into dominance, and “knees” are found late. SLL supplies a notation‑independent lens to make scale behaviour explicit and comparable.
Problem
Omitting Scale Variables and the comparison window causes: (i) unfair parity (compute/data/FoA mismatched), (ii) illumination/coverage report-metric creep into dominance by default, (iii) late detection of knees and budget waste. G.9 already forbids scalarising mixed scales and mandates equal FreshnessWindows/pinned editions; SLL complements this with ScaleWindow & elasticity.
Forces
Notation independence vs useful scaling heuristics; local context vs cross‑context generality; telemetry vs objectives (illumination stays report‑only telemetry unless policy promotes it); early exploration vs reproducible policy.
Solution — binding lens for generator/selector profiles (normative)
Types (aliases; ΔKernel = 0).
SLL.Profile is an annotation on a MethodFamily/Generator or a Selector profile; no durable U-kinds are minted (LEX discipline).
Fields (conceptual descriptors).
- S — Scale Variables. Minimal set of monotone knobs for the Context:
compute(steps/tokens/FLOPs/time/energy),data(size/quality),model capacity(params/branches),iteration budget,freedom‑of‑action (FoA)/environment richness, etc. Declare units under C.16 and bindSto a ScaleWindow. Keep planned budget values with A.15.2; bind dated resource-use accounts to A.15.1, B.1.6, and A.10. Where training/inference trade, name the phase the claim concerns. - ScaleWindow. Declared range of
Svalues for which behaviour claims hold (editioned). This is distinct from FreshnessWindow used by parity. - Scale‑Probe. At least two (preferably ≥ 3) parity‑respecting points in
Swithin the ScaleWindow, recorded with replicates/seeds and CI/error bars to support elasticity classification. Pick points via a small factorial or Latin‑hypercube when multiple knobs vary. - ElasticityClass
χ ∈ {rising, knee, flat, declining}— a qualitative class; numeric exponents/fits live in domain annexes, not Core. - ParityNotes.
iso‑scale parity?flag and loss notes if not achieved, plus Bridge, Φ, and Ψ IDs when crossing contexts; penalties affectRonly.
Norms (SLL).
- SLL‑1 (Declaration). Any profile claiming scale behaviour SHALL declare
Sand a ScaleWindow for the Context. - SLL‑2 (Probe). Early investigation SHALL include a scale‑probe (≥ 2 points in
S, with replicates/CI) and record χ. Multi‑knob probes SHALL hold unspecified knobs fixed or pinned, and disclose invariants. - SLL‑3 (Parity). Where
Sis declared, comparisons SHALL ensure iso‑scale parity and lawful UNM/NormalizationMethod‑based mapping across heterogeneous knobs (e.g., FLOPs↔tokens) before comparing outcomes; FreshnessWindows/editions must be equal/pinned per G.9. Record seeds/replicates, ComparatorSet, and policy‑ids in telemetry/SCR. - SLL‑4 (Selection lens). Within the same Context and ScaleWindow, if other heads (N/U/C) are tied, selectors MAY use illumination as a tie‑breaker, but it SHALL NOT change default dominance; illumination remains report‑only telemetry unless a CAL policy promotes it.
- SLL‑5 (Knee test). A knee is claimed only where a monotone rise is followed by a statistically significant slope drop across adjacent probe points within the ScaleWindow; thresholds (e.g., Δslope & CI level) are policy‑defined (E/E‑LOG) and must be cited. Absent such evidence, classify as rising.
- SLL‑6 (Telemetry invariants). Probes SHALL export seeds/replicates, edition pins, policy‑ids, and resource-account units governed by C.16 and B.1.6, with dated-work and provenance links under A.15.1 and A.10, to G.11.
Method — minimal SoTA probe recipe (notation‑agnostic; informative).
- Choose knobs
Sthat are plausibly monotone in the Context (compute/data/capacity/FoA). - Pick 3–5 probe points per active knob (edge/mid/edge) under iso‑scale parity; use a fractional factorial if >2 knobs.
- Run replicates (≥ 3 preferred) and bootstrap 95% CI on the primary objective(s); log seeds.
- Estimate local slopes on a log‑log grid; apply piecewise/segmented regression or a knee detector (e.g., L‑curve/Kneedle) to support
χ. - Record invariants (pinned knobs, safety envelope) and publish SLL.Card@Context.
- If χ changes across the window, split the ScaleWindow and re‑classify per segment.
Consumer relation fields - minimal inputs and outputs (conceptual)
G.9 parity planning and run evidence consumes S and ScaleWindow to align budgets, pin editions, and perform UNM or NormalizationMethod mapping; G.11 carries policy-id, PathSliceId, seeds and replicates, CI level, and edition pins per parity CC.
Archetypal Grounding (post-2015; informative)
- LLM scaling. Kaplan-style & Chinchilla-optimal regimes; Mixture-of-Experts and retrieval-augmented families shift effective capacity with different inference budgets; prompt-policies often transfer better than narrow pipelines.
- RL/Planning. Model-based optimization & general agents vs hand-tuned controllers; slopes reported wrt budget/FoA under safety envelopes.
- QD/OEE. MAP-Elites, CMA-ME, DQD, QDax; POET/Enhanced-POET families: coverage/illumination as telemetry metrics; parity uses fixed grids/spaces and edition pins.
Bias-Annotation
Conformance Checklist (CC-SLL)
Sdeclared orS = N/Awith rationale.- Scale-probe performed; χ recorded with replicates and CI; invariants disclosed.
- iso-scale parity or loss notes + penalties → R only; editions/seeds pinned; ComparatorSet cited.
- If used as tie-breaker, the selector cites χ and lens id in E/E-LOG provenance.
- Knee claims cite the policy threshold and CI level used.
Common Anti-Patterns and How to Avoid Them
Hidden budget mismatches; averaging ordinals across families; illumination in dominance by default; unpinned editions; slope claims without replicates/CI; training/inference phase mixing → cure with G.9 parity (equal windows/editions; normalize‑then‑compare; return sets), phase‑label the claim, and record slope uncertainty per Scale‑Audit discipline.
Payload — exports
SLL.Card@Context (UTS row; editioned):
⟨S{knobs, units, phase}, ScaleWindow, Scale‑Probe{points≥2, design=one‑liner, seeds, CI}, ElasticityClass χ, ParityNotes{iso‑scale?|loss, invariants}, BridgeIds?/Φ/Ψ, PolicyIds? (E/E‑LOG), PathSliceId?⟩.
UTS row template (conceptual; pencil‑ready).
SLL.Card@Context := S=(COMPUTE|DATA|CAPACITY|FOA; units=…; phase=TRAIN|INFER), ScaleWindow=[LOW…HIGH], Probe=(points=…, design=factorial|LHD, seeds=…, CI=…), χ=rising|knee|flat|declining, ParityNotes=(iso=true|false; invariants=…), Bridge/Φ/Ψ=(…), PolicyIds=(…), PathSliceId=(…).
Consequences
Benefits. SLL prevents scale claims from becoming rhetoric. A comparison can show which knobs were scaled, what window is covered, how much probe evidence supports the slope class, and whether parity or normalization losses only affect assurance rather than silently changing dominance.
Trade-offs. Early work must spend probes on at least two scale points and record invariants, phase, seeds, uncertainty, or policy thresholds. The gain is that selectors, parity harnesses, refresh telemetry, and mathematical-lens uses can cite one bounded scale claim instead of guessing whether the observed behavior transfers.
Stop condition. Stop at C.18.1 when the scale variable, ScaleWindow, probe basis, elasticity class, and parity notes are enough for the current comparison. Move to G.9, C.19, G.11, C.29, or a domain annex when parity, selector policy, telemetry refresh, mathematical lens, or numeric fit becomes the live object.
Rationale
C.18.1 exists because scale claims are easy to overread as universal improvement claims. The pattern keeps scale behavior bounded by a declared scale variable, scale window, probe basis, uncertainty, elasticity class, and parity notes before the claim is reused.
SoTA-Echoing
Current scaling-law practice in machine learning, quality-diversity, optimization, planning, and resource-aware experimentation treats scale behavior as windowed and regime-dependent rather than as one universal “scales well” label. C.18.1 adapts that line into FPF by requiring scale variables, windows, probe points, uncertainty, and elasticity classes before scale claims are reused.
The pattern also keeps SoTA scaling practice from overriding FPF ontology. Scaling-law fits, knee detectors, segmented regressions, and experimental-design methods are mathematical or methodological support for the scale claim; they do not replace C.16 measurement construction, G.9 parity, selector policy, or C.29 mathematical-lens admissibility.
Relations
C.27 temporal-claim relation.
- C.27 may flag: a claim that more review capacity, tool calls, tokens, data, model capacity, parallelism, freedom of action, sprints, or another declared scale variable changes rate, learning, recovery, throughput, stabilization, or improvement.
- This pattern keeps: scale variable, scale window, scale probes, and elasticity value.
- Non-admissible use: more scale is not linear improvement, and a scale word does not create a C.27 rate-change claim by itself.
- Neighboring-pattern use: if comparison or benchmark use is current, cite G.9 for parity; if the statement is only a linear effort fantasy, name the scale variable and scale window or downgrade.
Builds on: C.16/17/18. Coordinates with: C.19 (lenses/policies), G.5 (set‑returning selector), G.9 (parity; ParetoOnly default; UNM/NormalizationMethod‑based mapping), G.10 (shipping).
Pedagogical cue. Say what you would scale, probe it twice, and use the slope‑class to steer.
C.29 mathematical-lens use relation
C.18.1supplies scale-window and scaling-law evidence forC.29when a mathematical lens claims scale behavior, universality, knees, exponents, coarse-graining validity, or diminishing returns.C.29cannot treat mathematical compression as scalable without an SLL or BLP-compatible scale-window account where scale is load-bearing. If no scale claim is live,C.29uses a local stop condition rather than opening scale-law work.
C.18.1:End
Explore-Exploit Live-Pool Governor
Type: C-pattern Status: Stable Normativity: Normative
Plain-name. Explore-exploit governor.
Intent. State and test exploration and exploitation policy over still-live candidate pools so frontier treatment, graduation, narrowing, and sunset treatment stay explicit and auditable. A C.19 result governs pool treatment only; C.19:4.4 routes a question that has moved to another operation or result.
Export relation. C.19 defines no generation operation. Use it to state and test live-pool treatment records over candidate pools, fronts, archive regions, family regions, and cultural live pools.
Depends on. C.18 for archive and front stewardship, C.16 for characteristic and measurement claims, A.19.CPM and A.19.SelectorMechanism for comparison and selection kernels, B.3 for assurance-sensitive confidence claims, and G.5 for ordinary selector and default tokens.
Coordinates with. E.10.LRN only while learning-family wording hides an input's exact identity; C.17 for compatible characteristic results; C.11.CRC for a missing finite configuration-relative comparison; and G.9 for parity comparison. C.19:4.4 names the exact next-pattern coordination when the live question changes.
Use this when
- several candidate lines, family regions, or frontier segments remain live under one declared exploration and exploitation policy and the question is now policy over that pool rather than one more local choice result
- the next result should say whether to widen, keep the frontier, narrow to a subset, or sunset a line
- if the question is no longer pool policy, the C.19 use closes by naming the next subject pattern and the reason that pattern now applies
- the governing lens or policy state must be explicit rather than inferred from vague exploration language
If a proposed pool-policy premise is expressed as learning progress, information gain, novelty, or an articulated former cue, recover its exact result owner first. Use E.10.LRN only while learning wording hides that result, A.10 only when an evidence-bearing or source-bearing claim is actually relied on, C.17 or C.18 only when characterization or possibility-space change is current, C.11.CRC only when a finite configuration-relative comparison is missing, and C.11 for local option or probe choice. Stop before C.19 unless the remaining question is policy over a still-live pool.
What goes wrong if missed
- scalarized top-1 picks are mislabeled as "the frontier", so it becomes unclear whether the result names one lens-ranked winner or the admissible live set
- exploration continues without one named pool, one named governing lens, or one explicit next treatment
- local option choice, pool policy, enactment planning, selector-result declaration, and publication availability collapse into one blurred result
What this buys
- one explicit pool-governance result for exploration, graduation, narrowing, and sunset treatment
- one explicit link from lens or policy state to the next pool-side treatment
- one repeatable way to preserve heterogeneity and frontier discipline without forcing inadmissible totalization
First-minute questions
- Which still-live pool, frontier segment, or family region is actually under governance now?
- Which lens or policy state is governing it?
- Is the next admissible pool treatment to widen, keep the frontier, narrow to a subset, or sunset a line?
- If none of those treatments is current, which subject pattern now applies, and why is the question no longer pool policy?
- What event or threshold would justify changing that treatment next?
First output
For loop-engineering practice, use this first output only when the live question is pool policy over still-live candidates such as loops, harnesses, workflows, method families, or framework seeds. A C.19 record may say that the pool should widen, keep its frontier, narrow to an internal subset, or sunset a line under a declared lens. If the question leaves pool policy, finish this record and use the handoff in C.19:4.4.
The first useful output is one explicit pool-policy record that names the live pool, governingLens, one currentTreatment token from the closed set widen | keep_frontier | narrow_to_subset | sunset_line, and the exact event that would justify changing that treatment next. If another question has become current, set nextQuestionPatternLocator from C.19:4.4 instead of inventing another currentTreatment.
The word result in PoolPolicyResult means the stated conclusion of this pool-policy pass; it does not mint a universal result kind. The record and its inputs create neither an actual Problem nor a ProblematicForRelation, improvement-result or work-result identity, project Work or work parthood, ChoiceResult, public shortlist, work permission, nor refreshed edition. When a durable claim episteme about the pool treatment is needed, constitute that episteme separately under C.2.1 and keep its exact EntityOfConcern and claim content explicit.
That record states pool treatment only. Use C.19:4.4 for the next result rather than adding its fields or claims to PoolPolicyResult. If the output still cannot name the pool, governing lens, current treatment, and change trigger honestly, the current C.19 pass is unfinished.
Problem frame
C.19 describes named, versioned policies and lenses for treating a still-live pool after C.18 generation, archive, or front records exist.
When C.11 has already made local choice among one fixed OptionSet explicit, C.19 begins where the question becomes policy over several still-live candidate lines, family regions, or frontier segments rather than one more local ChoiceResult record.
Immediate failure indicators for this pattern:
- the current pool-policy result cannot name the still-live candidate pool whose treatment it states
- the governing lens or policy state is missing
- the next pool-side treatment exists only as one vague promise to continue exploration later
If the live question is not treatment of a still-live pool, use the exact exit in C.19:4.4. C.19 begins or continues only while the pool-policy question is current.
Problem
Ad-hoc exploration mixes ordinal and interval claims, silently scalarizes partial orders, and loses lens or policy provenance, undermining admissibility and reproducibility.
Forces
- Graduation vs. discovery — a direct policy condition must be satisfied while
explore_sharekeeps discovery alive; assurance is cited only when the condition actually depends on a named assurance use. - Heterogeneity vs. focus — fairness quotas by family vs. depth on proven lines.
- Lens expressiveness vs. audit — scalarised choices must not be called 'the frontier' and MUST record lens ids.
Solution
Causal data and causal-policy exploration hook
When exploration collects data for a causal claim, learns or evaluates a causal policy, or uses counterfactual replay as a reason to treat a live line, the pool-policy result stays within C.19 and cites C.28 for the causal-support conclusion.
Optional PoolPolicyResult.causalUseSpec?:
Omit this tail when the pool treatment makes no causal claim and consumes no causal-support result. Include it when effect, counterfactual replay, causal-policy support, or causal evidence changes the treatment. The C.28 result remains evidence support; it does not authorize ranking, retirement, deployment, or graduation. C.19 makes the pool-treatment decision under its own policy.
Policy fields. EmitterPolicy is a context-local, versioned policy with canonical fields:
{ emitterPolicyId, name?, regimeKey ∈ {UCB, Thompson, BO-EI, GP-UCB, PES, InformationGain, …}, params, explore_share∈[0,1], temperature τ≥0, rebalance_period, wild_bet_quota≥0, graduationConditionRef?, assuranceResultRef?, epsilon_dominance ε, cell_capacity K, insertionPolicyRef, dedupThreshold, deduplicationBasisRef, deduplicationUnit }.
graduationConditionRef cites the direct domain or policy condition that changes pool treatment. assuranceResultRef is present only when satisfying that condition relies on one exact B.3 result for a named assurance use and bounded scope. Neither field is an assurance level. emitterPolicyId is cited as emitterPolicyRef; the profile is not a U-kind, generation operator, staffing instruction, budget approval, or Work record.
Decision-subject clarification. Attribute any later choice to one declared DecisionSubject at explicit DecisionSubjectGranularity. Record measurement spaces and admissible policies in the semantic-frame epistemes that state them. Use LOG to describe lenses and policies; that description does not enact a choice.
EmitterPolicy use. The canonical profile and its assurance boundary are defined above. A C.18 generation or archive record cites it only when pool treatment, insertion, or deduplication actually uses that profile. The profile is not a staffing or budget instruction.
Use the ordinary default tokens defined in G.Core and [G.5](/generated/patterns/G.5). The rules below explain their pool-policy consequences without defining a rival default family.
Decision-theory bridge. Use [C.11](/generated/patterns/C.11) for theory-side choice among already-available options and for the meaning of ProbeBudget, ValueOfInformation, and ValueOfComputation. A pool-policy record may use those outputs only as criteria for graduation, keep-frontier, or sunset treatment; it does not restate local choice doctrine.
Ordinary default references (if policy is unspecified):
- Dominance: consume
DefaultId.DominanceRegimefromG.Coreand[G.5](/generated/patterns/G.5); in ordinary Q-front use this means{Q components}withConstraintFit=passas eligibility gate. - Tie-breakers: the current policy may use a Novelty coordinate,
DeltaDiversity_P/ΔDiversity_P, Surprise, or Illumination only when it names that tie-breaker. It need not fabricate results for optional tie-breakers it does not use.- For Novelty, cite each bearer's exact coordinate-result episteme: a complete C.16 measurement result for a measured value, or a C.2.1 ascription when the declared rule permits a non-measurement reading. Before comparing bearers, confirm compatible Novelty Characteristic and Scale editions, corpus/reference set and inclusion rule, similarity Method and encoder/model editions, ClaimScope, window, uncertainty, and evidence.
- For Surprise, cite the exact coordinate result and its generative-model and training-basis editions, Scale, ClaimScope, window, uncertainty, and evidence.
- For
DeltaDiversity_P, cite the retained set, candidate, measurement-policy and Scale editions, descriptor or distance basis, window, evidence, and resulting marginal reading. - Illumination remains telemetry over
Diversity_Punless the named policy explicitly promotes it. A promoted use still cites the report and its measurement basis. The words Novelty, Surprise, and diversity alone are not executable policy inputs.
- Archive:
K=1,ε=0, deduplication inCharacteristicSpace. - Policy family: one uncertainty-aware explore policy family with one declared regime key and explicit change triggers;
UCB-class with moderate temperature andexplore_share ≈ 0.3–0.5is one didactic starter profile, not the semantic default family. - Provenance (minimum): record
DescriptorMapRef.edition,DistanceDefRef.edition,DHCMethodRef.edition,emitterPolicyRef,insertionPolicyRef, scalardedupThreshold,deduplicationBasisRef,deduplicationUnit,timeWindow, andseeds.
Use-value and declared-Q boundary. [C.16.Q](/generated/patterns/C.16.Q) is the pattern for the selector-context meaning of use-value and its Objective form. When use-value participates in the current Q, declare QS.UseValue as an objective head in that exact Q and cite the current Q/comparator basis. When it does not participate in the current Q, keep the use-value criterion explicitly outside Q as a declared side condition or tie-breaker. A pool-policy record may use either declared position but cannot silently promote use-value into Q or construct the Q model.
Scalarization lenses (policy‑level). A lens J_ℓ declares: (a) hard eligibility conditions (e.g., ConstraintFit=pass), (b) soft aggregation (weights or curves), (c) trust policy (how assurance and CL discounts enter).
Conformance. A pool-policy record MUST name the lens used to pick from a frontier; scalarized rankings MUST NOT be presented as “the frontier”; the lens id MUST be recorded in provenance of each selection.
Promotion rules (policy).
- Tie-breaks. Use only the constituted and compatible results named by the current policy. Promotion of Surprise or Illumination into the dominance set MUST be declared by lens or policy id and captured in provenance.
- Graduation. A candidate line or pool member moves from Explore to Exploit only when eligibility holds and the direct condition cited by
graduationConditionRefis satisfied. When that condition relies on assurance,assuranceResultRefcites the exact B.3 result whose named use and bounded scope support the judgement. An optional profile may supply evidence; neither the profile nor a label graduates the line. - Sunset or pivot. A candidate line or pool member that fails the applicable VOI or direct graduation condition receives the sunset or pivot treatment at
rebalance_period. Its optional profile remains evidence, not the treated object. Policy logic is not generation or work. In one C.19 use, compute and record a treatment over an already identified live pool. It does not recompute a C.18 front or archive, update a generator, seed a candidate, constitute datedU.Work, create or classify a local system-role kind, create or change an assignment occurrence or its state, establish responsibility, authority, or permission, approve a budget or plan, or authorize enactment. At enactment, recover only the branches that independently obtain; send unresolved claim-bearing “role” wording through[E.10.ROLE](/generated/patterns/E.10.ROLE).
Pool-policy pass (per rebalance_period).
- Read the current C.18 archive/front reference and its replay boundary; do not recompute either object inside C.19.
- Record the governing lens and desired policy values, such as
explore_share, emitter-profile preference,wild_bet_quota, or an admitted heterogeneity constraint. These are policy values, not generation actions. - Apply eligibility and the direct condition cited by
graduationConditionRef: record graduation pressure and choose exactly onecurrentTreatmentfromwiden | keep_frontier | narrow_to_subset | sunset_line. If assurance is part of that judgement, cite the bounded B.3 result separately. - If that judgement requires fresh candidates, a changed emitter mix or temperature, archive insertion, or front recomputation, set
nextQuestionPatternLocator = [C.18](/generated/patterns/C.18)and pass only the desired emitter profile, quota or constraint, and the exact generation/archive/front reason. Apply C.18 to decide and record the generation, archive, and front operations. - If carrying out the treatment requires dated implementation, planning, staffing, or budget use, pass the policy record to the A.15 family; the policy record itself grants none of them.
- Emit one
PoolPolicyResultwithlivePool,governingLens,currentTreatment,changeTrigger, and any inputs required by the next subject pattern. The result may justify keeping, narrowing, graduating, or sunsetting a line without taking over the named next subject pattern's operation.
Named lenses (heuristics; policy‑level, not norms) The following lens profiles are illustrative heuristics. Practitioners MAY reuse or modify them; they are not normative.
- Frontier‑sweeper — maintain attention on the full front; promote only when the direct graduation condition holds.
- Barbell — enforce
explore_share ≥ θwith awild_bet_quota; otherwise exploit top‑trust region. - Spike‑first — pick highest Use‑Value subject to
ConstraintFit=passand a small Cost‑to‑Probe cap. - Safety‑first — minimize SafetyRisk subject to
Use‑Value ≥ θandConstraintFit=pass. - Platform‑option — maximize Option‑Value under probe cost bounds.
- Pilot-then-scale — optimize Use-Value on the declared pilot scope. Set
currentTreatment = widenonly whenassuranceResultRefcites the exact B.3 assurance result whose supported scope includes the proposed wider pool, andchangeTriggernames the satisfied assurance condition and that newly supported scope; otherwise keep the pilot scope. - Heterogeneity-first (illustrative profile). Use only when the applicable policy already admits a heterogeneity constraint or sampler policy. The applicable policy may declare a
FamilyCoverageorMinInterFamilyDistancegate, a family or subfamily quota, or a diversity-promoting sampler; no universalk,δ_family, quota vector, sampler class, DPP rule, or max-min rule is supplied here. Record only the admitted policy values and ids actually used. Conformance (lens recording). A pool-policy record that uses a lens MUST record its lens id alongsideemitterPolicyRef. (This restates and localizes C19-3.)
Explicit pool-policy result
Canonical record vocabulary. A serialized PoolPolicyResult uses the field governingLens and exactly one currentTreatment token from widen | keep_frontier | narrow_to_subset | sunset_line. Reader prose may say widen, keep the frontier, narrow to a subset, or sunset a line, but those phrases are labels, not alternate serialized values. Do not use lens as a second field name.
At the end of a C.19 use, write one explicit pool-policy record rather than one atmospheric statement that exploration will continue somehow.
That result should state:
- the still-live pool, frontier, or family scope under governance now;
- the governing lens id or policy state;
currentTreatment, chosen fromwiden | keep_frontier | narrow_to_subset | sunset_line;- the event or threshold that would justify changing that treatment next.
A compact result may therefore state, for example:
livePool = frontier_FgoverningLens = barbell_policy_v2currentTreatment = keep_frontierchangeTrigger = graduation_condition_v3 is satisfied for one retained line
or, for one narrower family region:
livePool = family_region_betagoverningLens = heterogeneity_firstcurrentTreatment = narrow_to_subsetchangeTrigger = quota satisfaction plus a compatible cited C.17 Novelty coordinate result clearing novelty_floor_policy_v2
Those fields define the result: live pool, governing lens, current treatment, and change trigger.
Closure rule over the live pool
A C.19 pass may close only when one explicit pool and one explicit next treatment are both visible.
- Close as
widenwhen the current frontier is too narrow for the declared exploration policy or when the evidence basis is too thin to justify current narrowing. - Close as
keep_frontierwhen several lines must remain live under the current lens and no narrower admissible subset is yet justified. - Close as
narrow_to_subsetwhen one declared lens now justifies retaining one smaller internal live set without pretending that one scalar winner has already been chosen. - Close as
sunset_linewhen one line or family region no longer clears the current lens, quota, or direct graduation condition.
When the question has stopped being pool policy, finish the pool-policy result and use the exact handoff in C.19:4.4; the next pattern is recorded outside currentTreatment.
One internal retained subset here is still one pool-treatment result. It is not yet a declared Shortlist or RankedShortlist, and it has no ShortlistId merely by being retained. When a downstream use needs declaration or audience availability, use C.19:4.4.
If the result still cannot say which pool remains live, which lens and policy apply, and which event would justify changing the treatment, it is still unfinished pool policy rather than one finished C.19 result.
Minimal pool-policy record
The smallest useful C.19 record usually states:
livePool = ...governingLens = ...currentTreatment = widen | keep_frontier | narrow_to_subset | sunset_linechangeTrigger = ...nextQuestionPatternLocator? = ...only when the question is no longer pool policy- one or more native direct-owner reference fields only when an already constituted result or claim supports the treatment; retain the field name, kind, identity, claim episteme when applicable, and subject-pattern locator supplied by that owner—for example the A.2.2
capabilityInstanceRefand itscapabilityStatementRef; an information-gain or articulated-endpoint use keeps the ref name and kind defined by its own direct owner—rather than replacing them with one C.19 signal or cue a10RelianceRef? = ...only when the pool treatment actually relies on one evidence-bearing or source-bearing claim; the cited A.10 account keeps the exact relied-on claim, bounded pool-treatment use, evidence-provenance path, window, andRelianceDispositioncompetenceModelRef? = ...only when it cites one exact model episteme used by the pool policy; that model is neither the capability, the owner-defined result, nor proof that the treatment may rely on eithergoalSpaceExpansionPolicyRef? = ...only when one independently declared archive or curriculum expansion policy governs goal- or task-space growthassuranceResultRef? = ...when graduation, scaling, or widening relies on one exact B.3 assurance result and its bounded supported scopewhyNotLocalChoice = ...when the result might otherwise be mistaken forC.11
An admissible short record may therefore read:
When currentTreatment = narrow_to_subset, livePool still names one internal retained subset or one live pool subset. It does not yet mint one public Shortlist, one public RankedShortlist, or one ShortlistId. If selector-facing result declaration is now required, the admissible [C.19](/generated/patterns/C.19) record leaves currentTreatment as the last pool treatment and fills nextQuestionPatternLocator = [G.5](/generated/patterns/G.5), with the reason that result declaration rather than pool policy is now current.
Goal and task space growth is one pool-policy doctrine over the archive or curriculum side. When autotelic or capability-discovery pressure is active, cite goalSpaceExpansionPolicyRef only for an independently declared policy. Retain every supporting information-acquisition, capability, novelty, objective, articulated-endpoint, or other result or claim through its native direct-owner reference and kind. Add a10RelianceRef only for an evidence-bearing or source-bearing claim on which this treatment actually relies. Use competenceModelRef only for one exact model episteme, never as an alternative name for the capability, result, or reliance account. These inputs may support widen, keep_frontier, narrow_to_subset, or sunset_line; none becomes a generic signal or cue, default Q, dominance coordinate, probe choice, or selector-facing shortlist by entering the record.
If the record does not already state which pool remains live, which lens and policy apply, and what would change that treatment next, it is still one unfinished [C.19](/generated/patterns/C.19) result.
Worked closure slice
Four short contrasts keep the closure law practical.
Several family regions remain live. When the point is to keep several lines active under one declared lens, the pool-policy result must not imply that one local choice has already been made:
An exact capability claim supports pool treatment.
An A.2.2 capability instance for diagnostic_agent_v4 is qualified for task region alpha, while its current statement does not establish transfer into region beta. A separately declared curriculum-expansion policy keeps both regions live until that transfer question changes. Because the pool treatment actually relies on the capability statement, the record cites its exact A.10 reliance account:
capabilityInstanceRef retains the A.2.2 U.Capability identity; capabilityStatementRef retains its governed episteme identity; and a10RelianceRef qualifies only the stated bounded reliance. None is renamed as a signal or cue, entered into the declared dominance set, or emitted as a ChoiceResult.
One region should now be sunset. When a region's compatible cited Novelty coordinate result no longer clears the active floor, or the region no longer clears the direct graduation condition, state that treatment directly rather than leaving the retirement implicit:
The pool has already been narrowed and the next question is selector-facing result declaration. When one internal retained subset is already explicit and the next question is to declare it for downstream use, close the pool-policy question by naming the applicable pattern instead of presenting that subset as though it were already one selector result:
Cultural and style live pools
Use the same minimal pool-policy record for cultural or style live pools when the current question is how several style, tradition, method-family, work-family, canon, scene, or technique variants remain live under one lens.
The record states pool treatment only. If a label is unstable across communities, first recover its exact source-local meanings through [F.17](/generated/patterns/F.17) and use [F.18](/generated/patterns/F.18) for naming. Include termBridgeRefs only for an actual F.9 relation between exact sense cells. That reference identifies the sense relation; it does not by itself support this pool treatment. Any claim that relies on the Bridge for the treatment stays separate from PoolPolicyResult: state the named use, direction, correspondence rule, and tolerated loss in a C.2.1 claim, and establish the current A.10 or B.3 reliance required by F.18. If the question becomes the cultural-evolution case, finish the pool-policy result and set nextQuestionPatternLocator = [C.36](/generated/patterns/C.36). For result declaration, audience availability, or currentness, use the exact exit in C.19:4.4 rather than extending the pool-policy record.
Exit from pool treatment
When fresh candidates, a changed emitter mix or temperature, archive insertion, or front recomputation are current, use C.18 with the desired policy values and exact reason as the pool-policy pass requires. When the current question is whether one bearer or version should improve, use E.23 and pass the exact bearer or version, objective or criterion, evidence, and pool-policy reason that made improvement current. A C.19 treatment is neither a generation operation nor an improvement result.
An internal subset retained by narrow_to_subset is still the live pool named by one C.19 policy record. It is not a public Shortlist, RankedShortlist, or ShortlistId-bearing selector artefact, and no public selector artefact is emitted by this pool-policy use. Front and Archive retain their C.18 meanings; a scalarized pick does not rename either one.
When the retained set must be declared for downstream comparison, registry use, or another selector-facing use, finish the pool-policy result and pass G.5 the exact declared source set, lens or policy id, eligibility conditions, dominance set, tie-breakers, promotion policy, and provenance pins. Use G.5 to declare the selected-set result and any stable public shortlist identity required by a named use. The C.19 record supplies only the preceding pool treatment and the reason result declaration is now current. If actual audience availability is also current, use E.17 for a source-backed publication face and return to source and E.24.PUB for the publication occurrence and availability.
When the live question becomes which option to choose, finish the pool-policy result and pass the fixed option set and comparison basis to C.11; a C.19 subset is not a ChoiceResult. When the question becomes enactment or performed work, use C.24 and the A.15 family. Resource bounds, CostToProbe, ValueOfInformation, ValueOfComputation, explore_share, and the direct graduation condition may explain a pool treatment, but they establish no budget, plan, Work occurrence, local system-role kind, separate System-classification judgment, assignment occurrence or state, responsibility, authority, permission, or enactment. Recover each needed fact independently, and send unresolved claim-bearing “role” wording through E.10.ROLE. When edition, source, descriptor, policy, or evidence currentness becomes the live question, use G.11; a change trigger in C.19 does not itself perform refresh or create a refreshed edition.
The practical handoff is therefore small: preserve the exact C.18 archive or front reference, the C.19 live-pool treatment and change trigger, and the evidence needed by the named next pattern. Do not duplicate selector-result declaration, publication availability, choice, work, or refresh semantics inside C.19.
System grounding
A product-search or architecture-search team often keeps several family regions alive even after one tempting line starts to look best locally. An admissible C.19 result might therefore keep the frontier live under frontier_sweeper_v3 until one retained line satisfies graduation_condition_v3, instead of collapsing the whole pool into one premature winner.
Episteme grounding
A SoTA pack often compares traditions that stay non-dominated for different reasons: one clears current evidence quality, one keeps broader transfer value, one preserves family coverage. The admissible C.19 result is then often keep_frontier or narrow_to_subset, not one fake scalar champion.
Collective and contextual grounding
A regional or stakeholder-diverse pool may have to sunset one line while keeping others alive to preserve coverage, fairness quotas, or contextual fit. Use C.19 to state and test that pool-treatment decision only while the question is still about the live set. Once the result must become one local choice, one enactment plan, or one declared selected set, apply the pattern that defines and tests that result.
Bias-Annotation
No global scalarisation of partial orders; ordinal scales excluded from arithmetic; all selections record lens id and policy id; notation and tool neutrality.
Conformance Checklist
-
C19-1 When a C.18 generation or archive record relies on a named C.19
EmitterPolicy, it SHALL cite that profile inemitterPolicyRef?. If the active insertion policy is not inherited, record it ininsertionPolicyRef?. If the deduplication threshold is not inherited, record scalardedupThreshold?together with itsdeduplicationBasisRef?anddeduplicationUnit?; never encode that scalar as a reference. A record with no such policy dependence need not fabricate these fields. -
C19-2 The characteristic set and indicators used for dominance MUST be declared and eligibility conditions applied first. If use-value participates in current
Q, the record cites the C.16.QQS.UseValueobjective head in that Q; otherwise it states that the criterion remains outside Q. (References to C.18 generator operators are descriptive only; LOG exports no Γ.) -
C19-3 If a lens is used, its id MUST be recorded; do not label scalarized top-1 as "frontier".
-
C19-4 Promotion of
SurpriseorIlluminationinto dominance MUST be explicit in policy. -
C19-5 A pool-policy record creates no
SystemRoleAssignmentStateRelation, system-role assignment, permission, plan, budget, or Work occurrence. When implementation follows, cite the independently obtaining context and scope, exact system-role-kind classification, assignment or assignment-state condition, and direct planning or Work pattern; none of those facts follows from the pool-policy record. -
C19-6 Each pool-treatment lens MUST document the pipeline
Eligibility (ConstraintFit=pass) → Dominance (declared set) → Tie-breakers (declared). For every tie-breaker actually used, cite a constituted result with the compatible basis required above; unused optional tie-breakers need no result. Any promotion of Surprise or Illumination into the dominance set MUST be named by lens or policy id and recorded in provenance. -
C19-7 (pattern-change boundary). A project-local choice or revision of an
EmitterPolicy,DescriptorMap,DistanceDef, sampler, quota, orδ_familythreshold stays under C.19 and the decision or result that consumes it; it does not invoke E.15 merely because a profile changed. When the definition is changed in an existing FPF pattern edition, use E.15 to compare the exact predecessor and candidate, classify the actual effect, and repair dependent consumers. Use C.18/C.19 candidate generation only when several materially plausible definitions remain. No default heterogeneity quota or sampler is defined here. Keep the policy and card ids in the existing decision, change, or SCR result that actually needs them; create no separate authoring trace. -
C19-8 When a heterogeneity-first profile is used, provenance MUST name each admitted heterogeneity constraint and its governing policy id. If a family or subfamily quota applies, record the exact quota vector and family-definition id; if sampling applies, record the sampler class, seed when relevant, and sampler-policy id. Do not fabricate a default triad, quota, or sampler.
-
C19-9 A
PoolPolicyResultMUST identifylivePool,governingLens,changeTrigger, and exactly onecurrentTreatmenttoken fromwiden | keep_frontier | narrow_to_subset | sunset_line;lensand space-separated treatment spellings are not alternate record fields or values. -
C19-10 If the question under repair is local option choice, an enactment-facing plan, selector-facing result declaration, or publication availability,
C.19MUST name the applicable pattern rather than restate it:C.11,C.24,G.5,E.17, orE.24.PUB. -
C19-11 If goal- or task-space expansion, autotelic pressure, or capability-discovery support is used, the record MUST cite
goalSpaceExpansionPolicyRefonly when one independently declared policy governs the treatment; retain each supporting result or claim under its native direct-owner reference, kind, identity, claim episteme when applicable, and subject-pattern locator; adda10RelianceRefonly for an evidence-bearing or source-bearing claim on which the pool treatment actually relies; and usecompetenceModelRefonly for one exact model episteme. None of these inputs becomes a generic signal or cue, default dominance coordinate, probe choice, or selector result merely by supporting the treatment; any actual dominance promotion still requires the explicit lens or policy rule and provenance required above. -
C19-12 If exploration collects data for a causal claim, learns or evaluates a causal policy, or treats counterfactual replay as support,
PoolPolicyResult.causalUseSpec?MUST carry the target rung, claim kind, available support-component refs, supported use, unsupported use, and the C.28 support-result ref when one is consumed. -
C19-13 A pool-policy record for still-live loop-engineering candidates—for example, loops, agent harnesses, workflows, or DPF seeds—names the pool, governing lens, current treatment, and change trigger. Fresh generation, archive work, or front recomputation uses
C.18as the pool-policy pass specifies. Any other next-result question uses the exact transfer inC.19:4.4; C.19 does not absorb improvement, declaration or publication, choice, Work, or refresh. -
C19-14 A pool-policy record, its evidence, and its treatment constitute neither an actual Problem nor
ProblematicForRelation, improvement result, work result, project Work or parthood,ChoiceResult, public selected set, work permission, nor refreshed edition. -
C19-15 Graduation, scaling, or widening MUST cite its direct
graduationConditionRef. If that judgement relies on assurance,assuranceResultRef?cites the exact B.3 result andchangeTriggernames the satisfied condition and bounded supported scope. A policy threshold or label does not create an assurance result.
Common Anti-Patterns and How to Avoid Them
- Treating one scalarized top-1 as the frontier. Avoid by naming the governing lens and keeping the live frontier distinct from any lens-ranked pick.
- Running exploration without one explicit next treatment. Avoid by ending each pass with one explicit
currentTreatmenttoken:widen,keep_frontier,narrow_to_subset, orsunset_line. If the current question is no longer pool policy, name the next subject pattern instead of inventing another pool treatment. - Letting
SurpriseorIlluminationquietly become dominance criteria. Avoid by promoting them only through one declared lens or policy id and recording that promotion in provenance. - Absorbing neighboring questions. Avoid by using the exact handoff values in
C.19:4.4instead of adding a neighboring result's fields or claims toPoolPolicyResult.
Consequences
- the result states whether the pool is being widened, kept live, narrowed, or sunset; if the question leaves pool policy, the record names the next subject pattern separately
- heterogeneity can remain admissible without pretending every frontier is one scalar winner
- the cost is stricter provenance and the need to name lenses, policies, and change triggers explicitly
Rationale
C.19 exists because pool governance is neither local choice nor execution. Once several candidate lines remain live, the key question is no longer which single option should survive now; it is how the pool should be governed next under one explicit lens or policy. That question needs its own explicit pool-policy result, otherwise frontier drift, silent scalarization, and policy amnesia return immediately.
- Post-2015 bandit and Bayesian-optimization practice treats explore and exploit policy as an explicit policy object, not as one hidden side effect of whichever candidate looked best first. The practical implication here is to emit one explicit pool treatment plus one change trigger, not one atmospheric frontier story.
- Contemporary frontier and quality-diversity practice also distinguishes the live frontier from any scalarized pick taken under one declared lens. The practical safeguard is to keep
keep_frontier,narrow_to_subset, andsunset_lineas visible alternatives rather than silently totalizing the pool. - When an applicable policy independently admits coverage or heterogeneity pressure, keep that pressure explicit until one declared reason justifies retirement or use of a different subject pattern. The practical implication is simple: sunset or name the next subject pattern only when the current pool-policy result can already say why the pool no longer belongs to
C.19.
SoTA-Echoing
Source-currentness boundary (reviewed through 2026-08-01). The mutable arXiv sources below are pinned to exact editions; the journal QD source is pinned by DOI and publication record. Reopen this source-use judgement when a pinned arXiv record receives a newer version, the journal source is corrected, retracted, or materially superseded, or a proposal would promote a particular heterogeneity quota or sampler into a C.19 norm. G.11 is the pattern for that refresh. These sources inform policy pressures and pattern boundaries; none installs its algorithm, quota, or sampler as the default FPF method.
Relations
C.27 temporal-claim relation.
- C.27 may flag: a temporal claim that changes exploration, exploitation, narrowing, widening, convergence speed, or search cadence in a way that changes admissible use.
- This pattern keeps: pool-policy result and explore and exploit governance, including
keep_frontier,narrow_to_subset, andsunset_line. - Non-admissible use: faster narrowing is not automatically a positive result; it may collapse exploration health, diversity, archive coverage, or frontier discovery.
- Exit: use C.19 for the pool-policy result; use C.27 only for the temporal-claim adequacy question when speed or change affects admissible use.
Builds on: C.18, C.16, A.19.CPM, A.19.SelectorMechanism, and B.3. Coordinates with: E.10.LRN only for unresolved learning-family wording; A.10 only for actual bounded reliance; C.22.PFR for actual Problem identity; C.18 for generation, Archive, Front, and possibility-space change; C.32.P2S, C.32, and C.35 for architecture-alternative carry-through and candidate admission; C.28 for causal-use support; C.17 and G.9 for evaluation and parity inputs; C.11.CRC only for a missing finite configuration-relative comparison; C.11 for local option or probe choice; and the other next-result patterns and transfer values named in C.19:4.4.
C.19:End
Bitter‑Lesson Preference (BLP)
One-screen purpose (manager-first).
State the empirical Bitter Lesson narrowly: in search, learning, planning, and related computational work, general methods able to use increasing compute or data have often displaced hand-engineered special cases. Treat that history as a comparison pressure, not as proof about every bearer. A project may declare an analogous preference for a module, platform, organization design, evidence arrangement, or other bearer only as a separate local policy, with a scale predicate, objective vector, comparison basis, and evidence form appropriate to that bearer. Safety, cost, admissibility, uncertainty, and non-dominance remain visible; the word general creates no preference by itself.
Builds on. C.19 (E and E‑LOG), C.24 (Agent‑Tools‑CAL; ATC‑2), B.3 (Assurance), E.3 (Precedence), E.5 (Guard‑Rails).
Coordinates with. G.5 (Selector), G.8 (SoS‑LOG Bundles), G.9 (Parity), G.11 (Refresh‑Telemetry), A.0 (On‑Ramp).
Keywords. general-solution preference; scale‑amenability; BLP‑waiver; iso‑scale parity; Scale‑Audit; slope vector; alpha and delta tolerances.
Use this when.
Use C.19.1 when a current choice or policy makes a real scale claim: a narrower special-purpose approach is preferred over a general alternative, or a general approach is preferred because its measured performance is expected to improve across a declared scale window. For search, learning, planning, and agent substrates, the empirical Bitter Lesson can supply the motivating line. For a module relation, platform, organization design, evidence-bearing episteme or work arrangement, or selected structure, state explicitly that the move is a local analogy or policy rather than an empirical Bitter-Lesson result.
The pattern governs only that scale-based comparison, preference, or waiver. It neither proves architecture adequacy nor turns a bearer label into a holon kind. If the project is merely using a bounded specialization and makes no scale advantage or durable generality claim, keep the use local under the bearer's direct pattern and stop here.
When E.23 compares a general adaptive loop with a specialized cycle or direct repair, use C.19.1 only if the decision relies on scale advantage or a declared generality policy. The E.23 loop still names the object under improvement, evaluation, cost and risk account, protected trade-offs, and stop or switch condition.
What Goes Wrong If Missed
A team treats "more agentic", "more automated", "more specialized", or "works on this benchmark" as proof that one bearer should displace a more general scale-amenable bearer. Another team repeats the opposite error: it invokes the Bitter Lesson as permission to ignore safety, cost, task-family fit, or a narrow heuristic that actually wins inside the declared scale window. In both cases, the selector loses parity, waiver, and scale-window discipline.
What This Buys
The practitioner gets a cheap first probe before an expensive audit. It distinguishes a supported scale comparison, a declared local analogy or policy, a bounded use with no scale claim yet, and a high-stakes claim that justifies a fuller Scale-Audit. When comparison proceeds, task family, scale window, parity, uncertainty, cost, safety, and waiver remain explicit.
Not This Pattern When
Do not use C.19.1 to prove that an architecture candidate is adequate, declare a selected-set result, make that result available to an audience, run the improvement loop, plan or perform work, or claim a gate decision. Apply the pattern that defines and tests the current question: C.30 or C.32 for architecture adequacy and synthesis, G.5 for selected-set result declaration, E.17 for a source-backed publication face and return to source, E.24.PUB for the publication occurrence and audience availability, E.23 for object-version improvement, the A.15 family for work, and A.21 for gate decisions.
First Output
Run one cheap scale-claim probe before selecting any Scale-Audit. In a short note, name the two bearer candidates and their direct patterns, the task family or receiving use, the proposed scale predicate, objective vector, comparison basis, feasible evidence form, safety boundary, and stakes. Return one of four results:
no scale claim yet: use the bounded candidate under its direct pattern; no BLP preference or waiver follows;local analogy or policy: identify the non-computational bearer family, policy edition, and bearer-appropriate evidence still needed;bounded scale comparison: state the smallest parity and uncertainty method adequate for this use;full Scale-Audit selected: state why the claim, stakes, feasible evidence, and receiving use justify the added work.
A BLP-waiver is needed only when an actual declared generality preference would otherwise decide the use.
Problem frame
Bespoke computational heuristics can win locally while failing to exploit larger compute, data, or search budgets. General methods can improve across a declared scale window, but the empirical record is strongest for computational search, learning, and planning. A module organization, institution, work arrangement, or episteme does not inherit that empirical result by analogy. A project may still adopt a broader policy, but it must state the bearer-specific scale relation and evidence rather than treating all growth, reuse, or generality as one phenomenon.
Without this separation, teams either repeat the Bitter Lesson as a slogan or impose a costly machine-learning experiment recipe on bearers for which seeds, FLOPs, compute slopes, or data sweeps have no meaning.
Policy clauses (normative; synchronized with Core)
BLP-1 — Probe first; select audit depth by claim and risk.
Every BLP use starts with the cheap scale-claim probe. A scale claim is current only when the exact bearer kind and direct pattern, a recoverable scale predicate, an objective vector, a comparison basis, an evidence form, and a named receiving use are present. If any of those is absent, return no scale claim yet; if a local analogy or policy remains useful, label it as such and do not present it as an empirical conclusion or manufacture a Scale-Audit.
When the scale claim is current, choose evidence proportional to the bearer, stakes, feasible observations, and receiving use. A selector-facing superiority claim, durable reusable-bearer policy, safety-material override, or expensive irreversible choice normally justifies a fuller audit. A reversible local probe may need only a small matched comparison. The method shall preserve:
(a) Parity and admissibility: comparable task family or use, safety boundary, budget basis, current editions, and set-returning Pareto comparison unless a declared policy lawfully selects another operation. (b) Bearer-appropriate scale dimensions: compute, data, model capacity, or freedom of action for computational methods when they actually vary; for another bearer, state its own capacity, resource, reuse, throughput, coordination, or other exact scale predicate and explain why it is comparable. (c) Uncertainty appropriate to the evidence: repeated seeds or bootstrap intervals for repeatable stochastic trials when useful; measurement error, interval estimates, case comparison, or another justified form for other bearers. Do not demand seeds from an organization design or FLOPs from an episteme. (d) Cost, resource, and safety visibility: report the accounts material to the decision through their direct patterns. Add B.3 only when an assurance claim or material-reliance threshold is current. (e) Objective honesty: keep quality, risk, cost, and any policy-promoted coverage or illumination coordinates separate unless their Scale permits the declared operation. (f) Risk-selected design: choose a design that can answer this claim. Fractional factorial, Latin-hypercube, three-level sweeps, heteroscedasticity treatment, and repeated-seed designs are options for suitable multi-knob experiments, not a universal minimum. Record why the selected design is adequate and what it cannot establish. (g) Claim-matched tests: use knee or budget-constrained regret tests only when the asserted advantage depends on a knee or dominance inside the audited window.
BLP-2 — Preference rule with alpha and delta tolerances.
Among admissible options with comparable assurance within delta and budget within alpha, a scale-based preference is warranted when the relevant response over the audited range Pareto-dominates with uncertainty accounted for. If no option dominates within the evidence bounds, C.19.1 returns no scale-based preference; it does not turn greater generality into an empirical winner. A separately declared project policy may break that tie in favor of a more general bearer, but the result shall be labeled as that local policy or analogy, not as the empirical Bitter Lesson, and its E/E-LOG tie-breaker and edition shall be cited. Agentic uses keep any alpha and delta values in their current ATC.Policy.
BLP‑2.1 — Valid waiver grounds (override transparency). Overrides of a declared local generality preference are allowed only when: • Admissibility override: guard rails, ethics, or precedence make the general bearer inadmissible (
E.5,E.3). • Scale‑probe overturn: under iso‑scale parity in the declared ScaleWindow, the heuristic sustainedly outperforms with uncertainty accounted for. • Complementary bias: the heuristic is an inductive bias that improves the general method without blocking scale (graceful degradation asSgrows). All overrides record a BLP-waiver with rationale, admitted review System, direct waiver-review responsibility relation or exact A.6.RCD missing governor, and expiry or review in the DRR. Any system-role kind or assignment needed by the review Work is cited separately.
BLP-2.2 — Task-family specialization compatibility.
A bounded specialization that makes no scale-advantage, selector-facing superiority, durable generality, or override claim may be used under its direct pattern with an explicit task family, work target, budget guard rails, and evidence locus. It needs neither a full Scale-Audit nor a BLP waiver merely because it is specialized.
If a scale claim becomes current, run the cheap probe first. Select a full audit only when the claim, stakes, feasible evidence, and receiving use justify it. A specialization produced by a general substrate or described as a complementary bias is not automatically compatible: state the exact non-blocking scale relation and evidence when that fact is relied on. Low-human-overlap or newly discovered approaches remain admissible under the same bounded-use, parity, safety, cost, and evidence rules; novelty neither proves nor defeats scale amenability.
BLP-3 — Prescription architecture is a separate question.
The Bitter Lesson establishes no universal preference for prohibitions over positive instructions and no general right to autonomous sequencing. For tool-call planning, use C.24 with its budget, stop, replan, and Guard-Rail rules. For another WorkPlan or normative constraint, use the A.15 planning family, E.3, E.5, and the direct policy or commitment pattern. A project may adopt a minimal-prescription policy only with its own trigger, safety boundary, evidence, and review condition; it is not a consequence of a BLP comparison.
BLP‑4 — Heuristic‑Debt register (mandatory).
Record Heuristic Debt only when an admitted heuristic functions as reusable solution-family policy, selector-facing preference, durable override of a general scale-amenable alternative, DRR-backed scale waiver, or project-side choice that claims scale advantage or BLP override. Ordinary local bounded tactics that make no reusable-bearer, scale-advantage, selector-facing, or override claim may remain local and bounded without Heuristic Debt publication. BLP.HeuristicDebtEntry is a C.19.1-local or G.11-linked policy and debt entry; it is not a universal U.* record kind unless separately admitted through F.18, C.3, and E.9. For a live debt entry, record scope, admitted review System, direct debt-review responsibility relation or exact A.6.RCD missing governor, expiry or review window, and a de-hardening plan; any exact system-role kind or assignment needed by review Work remains separate. Track the entry in CalibrationLedger or BCT and cite it in SCR.
BLP-5 — Adaptation policy is a separate question.
The Bitter Lesson does not by itself require feedback-driven adaptation or make disabling adaptation a waiver. When adaptation is current, use C.22.1 for the task-family adaptation claim, E.23 for object-version improvement, and C.24 for tool-call planning and replanning, together with the applicable privacy and Guard-Rail patterns. A product policy may require or prohibit adaptation, but that result needs its own objective, evidence, risk boundary, and review date.
BLP‑6 — Precedence & safeguards.
BLP is constitutional (instantiates P‑10, P‑11, P‑7, and P‑1), but does not supersede Guard‑Rails (E.5) or precedence rulings (E.3). Where NQD or C.19 E‑LOG promotes illumination into dominance, BLP adopts that lens for the audited window.
BLP‑7 — Publication discipline.
When a durable Scale-Audit is actually performed, its artifacts SHALL be exported to G.11 with the used edition pins, uncertainty method, alpha and delta tolerances when current, ComparatorSet, policy reference, and qualification window. A no scale claim yet or local bounded-use exit creates no audit package.
Conformance Checklist (CC-BLP)
- The cheap scale-claim probe names the bearer kind and direct pattern, task family or receiving use, scale predicate, objective vector, comparison basis, feasible evidence, safety boundary, and stakes.
- The result says
no scale claim yet,local analogy or policy,bounded scale comparison, orfull Scale-Audit selected; it does not hide the choice of audit depth. - A performed comparison uses parity, current editions, explicit uncertainty, material resource and safety accounts, and lawful Pareto or declared policy operations.
- The evidence method fits the bearer. Compute/data sweeps, seeds, bootstraps, and factorial or Latin-hypercube designs appear only when they answer the actual claim.
- Non-dominance returns no empirical scale preference. Any generality tie-break is identified as a separately declared local policy.
- A waiver identifies the policy it overrides, rationale, admitted review System, direct responsibility relation or exact missing governor, and expiry or review window.
- A live Heuristic Debt entry meets the bounded
BLP-4trigger; ordinary local tactics create no debt record. - Prescription architecture and adaptation policy are routed through their direct patterns rather than reported as consequences of BLP.
- An actual durable audit is exported to
G.11; a bounded-use or no-claim exit is not padded into an audit artifact. - A narrower specialist bearer names its task family, work target, and the exact scale, waiver, or bounded-use ground relied on.
Anti-patterns & remedies
- Slogan as evidence.
General,agentic, orBitter Lessonis treated as proof. Repair with the cheap probe and an actual comparison basis. - Analogy as empirical result. A module relation, organization, or episteme is assigned compute/data scaling semantics. State a local analogy or policy and use a bearer-appropriate predicate and evidence form.
- Universal experiment recipe. Every claim receives seeds, FLOPs, and a multi-factor design. Select the smallest method that can answer the actual risk-bearing claim.
- General wins by non-dominance. Error bars overlap, so the more general option is declared superior. Return no empirical scale preference or cite a separate tie-break policy.
- Single-winner leaderboard. Hidden budget mixing or scalarization replaces Pareto comparison. Restore comparable windows, objective coordinates, uncertainty, and policy identifiers.
- Debt without trigger. A local bounded tactic is entered into Heuristic Debt. Apply the
BLP-4trigger before creating the entry. - Elegant-math override. A specialized mathematical lens is selected because of elegance or prestige while scale advantage is live. Use the proportionate BLP comparison; otherwise keep the lens local under the
C.29stop condition.
Archetypal grounding (post-2015; informative)
Source-use relation and source-currentness: this section is informative grounding for computational scale comparison, not a current SoTA table and not evidence for non-computational bearer families. A concrete BLP claim still needs its task family or receiving use, comparator set, current alpha and delta tolerances when used, budget, material safety and admissibility boundary, any current assurance boundary, and source-currentness row named by the applying pattern or parity harness.
- LLMs: prompt programs, retrieval-augmented policies, and MoE policies compared with narrow task-specific pipelines; set-returning selection across editions and budgets.
- RL and planning: model-based optimization and general agents compared with hand-coded controllers, subject to alpha and delta tolerances and safety.
- Preference learning: RLHF <-> DPO families.
- QD and OEE: MAP-Elites, CMA-ME, DQD, and QDax; POET and Enhanced-POET; illumination remains report-only telemetry unless policy promotes it.
SoTA-Echoing
Payload - exports
BLP.Policy@Context is an editioned local policy row, not a universal kind. It records:
<scopeBranch={empirical-computational | declared-local-analogy}, PreferenceDefault={neutral | declared-prefer-general}, alpha?, delta?, scaleProbeResult?, proportionateComparisonMethod?, fullScaleAuditRef?, WaiverRegister?, E-LOG policyIds?, G.11 telemetryPins?>.
The row omits fields that are not current. PreferenceDefault=declared-prefer-general identifies a local tie-break policy, not an empirical conclusion. A full audit reference appears only after the risk-selected audit exists.
Relations
Depends on: G.5 and G.9 (selector and parity), G.11 (refresh telemetry), A.15.1, A.15.2, B.1.6, C.16, and A.10 for dated work, resource aggregation, measurement, cost, and provenance, C.18 (NQD‑CAL), C.19 (E and E‑LOG), F.7 and F.9 (bridges, CL, Φ, and Ψ). Planned C.5 (Resrc-CAL) may later consolidate resource-use and work-cost guidance but supplies no current governing semantics. Constrained by: E.5 Guard‑Rails and E.3 precedence.
C.32 architecture-synthesis use relation
When C.32 generates candidate architectures, C.19.1 applies only if a candidate makes an explicit scale-advantage claim or invokes a declared local generality policy. For a universal module relation, platform, organization design, evidence arrangement, or selected structure, that branch is a project analogy or policy: the empirical machine-learning literature is not proof. Name the exact bearer and its direct pattern, the holon under change when one is current, the bearer-specific scale predicate, objective vector, comparison basis, feasible evidence, admissibility boundary, and intended receiving use.
BLP neither selects the architecture nor turns method-family, practice, role-side, or culture wording into a holon kind. If the candidate merely removes parts, carries several functions, or is described as reusable without a recoverable scale claim, keep the question in C.32 and C.31; return no scale claim yet rather than manufacturing an audit. A TRIZ-style ideality move enters BLP only when the declared comparison actually relies on scale amenability inside a named window.
C.29 mathematical-lens use relation
When a mathematical lens is chosen over a general, scale-amenable bearer because it is elegant, specialized, or theoretically prestigious, C.19.1 governs the scale-advantage and preference claim. A C.29 application may state CandidateMathObject, LensMappingMode, PreservedStructure, LostStructure, LensUseAdmissibilityValue, admissibleUse, nonAdmissibleUse, and StopCondition; it does not supply BLP compatibility, scale dominance, or waiver evidence.
If scale advantage is live, start with the cheap probe and cite the resulting bounded comparison, risk-selected Scale-Audit, or applicable BLP-waiver. If scale advantage is not live, keep the mathematical lens local and bounded by its C.29 stop condition.
Memory hook. Test what scales; label policy when evidence does not decide.
When E.23 selects between a general adaptive loop, a specialized object-family cycle, or a mixed operation-family set, C.19.1 applies only when the decision relies on scale advantage or a declared generality policy. Start with the cheap probe. Compare material resources, tools and instruments, adaptation attempts, skilled attention, rework or delay, risk exposure, and avoided loss on their admitted scales; keep them separate, reject a dominated option, and use the declared project policy to choose or hold when no option dominates. Net-cost arithmetic is permitted only after every term has been converted to one declared unit through an admissible conversion whose basis, uncertainty, and scope remain visible. Repeated automation alone does not satisfy BLP; the record still names the object under improvement, evaluation, protected trade-offs, bounded cost and risk condition, and stop or switch condition. If no scale claim is current, E.23 proceeds without a BLP audit or waiver.
C.19.1:End
Use-Bounded Apparatus Application
Type: Architectural (A) Status: Stable Normativity: Normative
Use this when
Use this pattern when one practical result matters and a relevant method, model, formalism, assurance technique, ontology, or other direct-kind apparatus is available, but the work needed to configure and apply it may cost more than the result warrants. Start here whether one apparatus is already selected or a real choice among available alternatives has become current.
The first useful move is to name the practical use, result kind, claimed guarantee, constraints, and reuse horizon, then ask whether the next adaptation and application work can reach a useful result within the available budget. This keeps a small, adequate path small while letting repeated or high-consequence use justify richer configuration.
Not this pattern when. If candidate material does not yet exist, use C.18 to generate or reframe it. If the live question is a local choice over an existing option set, C.11 is the pattern for that choice. If the real blocker is an ontology conflation, use A.7.1; if it is a material conflict among FPF premises, use A.7.2.
The primary working reader is an engineer, method or model selector, or technical lead. That reader position is not a system-role kind or assignment. This pattern is a U.MethodDescription episteme whose claims describe one admitted U.Method. When an admitted U.System performs dated configuration or application U.Work using that Method, first recover the performer's A.13 core and independently admit the Work under A.15.1. Add F.6 afterward only when the present use needs precise assignment-bound attribution. Show an assignment identifier, species, participants, and attribution detail only when that use relies on them, attribution is ambiguous, or the source wording must be repaired. The problem-facing result remains with the pattern that defines or tests it.
Problem frame
A team can have a rich apparatus and still lack an economical way to use it. A maintenance group may need only one typed relation distinction for a one-off repair, an architecture team may need a carefully configured model across hundreds of handoffs, and an assurance team may need a formal technique only after the required guarantee becomes stronger. In each case, displaying more apparatus is easier than proving that its setup work changes the result.
The governed concern is one bounded apparatus application for one declared use and horizon. The apparatus retains its direct kind; this pattern does not introduce a generic U.Apparatus kind. The application question is distinct from candidate generation, local choice, planning, performed work, and the domain result.
Problem
Without a use-bounded application method, users make two symmetrical mistakes. They configure an entire rich basis because it is available, or they keep a lightweight path after recurrence, automation, transfer, or consequence would repay a more capable configuration. They may also call candidate generation “choice”, call a choice record a work plan, or treat an application note as the practical result.
The failure is not merely excess documentation. It obscures who performs the work, what result the work must produce, which guarantee is being claimed, and which neighboring pattern contains the defining content for the next question.
Forces
Solution
Keep the five positions separate
Use this minimal lens before taking a branch:
- Declared use: the practical question, direct result kind, claimed guarantee, non-negotiable constraints, and horizon.
- Selected or candidate direct-kind object: the method description, model, ontology module, formal technique, or other governed object being considered.
- Application MethodDescription: this pattern's
U.MethodDescriptionepisteme and the admittedU.Methodit describes. A practitioner uses its claims to guide the Work; neither the episteme nor the Method performs it. - Performer and work: when an admitted
U.Systemperforms dated configuration or applicationU.Workusing the described Method, recover its A.13 core and independently admit the Work under A.15.1. Add F.6 afterward only when the present use needs precise assignment-bound attribution. In a short account, expose assignment identity, species, participants, or attribution detail only when the use relies on them, attribution is ambiguous, or source wording must be repaired. - Problem-facing result: the domain, engineering, assurance, architecture, or other subject-pattern result inspected after the work.
The intended reader may also be the person-system that performs the Work, but reader position and performer relation remain different. A plan, checklist, U.MethodDescription episteme, described Method, option row, or publication cannot occupy the performer position.
Select the truthful application branch
One current apparatus. When one direct-kind apparatus is already selected and still has a credible path to the declared result and guarantee, create no OptionSet and no ChoiceResult. Compare the smallest next adaptation/configuration work with the useful-result threshold, plan when needed, perform the work, and inspect the result.
Candidate generation or reframing. When no adequate current object is available and the live question is to invent, expand, retain, or reframe candidates, use C.18. This pattern may supply the declared use and eligibility basis, but candidate-generation work is not a choice result.
Local choice. Only when two or more already-available eligible alternatives, or another genuine local-choice question over a live set, are current use C.11 for OptionSet, ChoiceRule, probing, and ChoiceResult.
Post-choice enactment. A singular selected direct-kind object enters A.15.2 planning when a plan is needed and A.15.1 dated work when applied. C.24 is the pattern for sequencing, budgeting, checkpointing, and replanning only when the selected object is enacted through tool-call work.
Admit candidates by one use-bounded predicate
UseBoundedApparatusCandidateEligibilityPredicate@Context is a local eligibility predicate, not a U-kind, relation kind, or candidate-generation method. A candidate is eligible only when it has a credible adaptation path to the same declared use, direct result kind, claimed guarantee, scope and horizon, and non-negotiable constraints. A candidate that cannot meet one of those values stays outside the current option set rather than becoming a “weaker” member of it.
When choice is current, preserve the exact C.11 contract:
choose nownames one selected option or an honestly retained tie-set;reject current setreturns to a named candidate-generation pattern or closes with no current application;probe againretains one probe and its epistemic budget because it can still change the choice;reroutenames the actual neighboring question and its subject pattern.
These four dispositions form the complete current C.11 result set. “Configure the rich basis”, “adapt again”, and “use a lighter method” are option or plan contents, not extra choice-result values. A tie is not a hidden winner.
Perform the bounded application
- State the practical use, direct result kind, claimed guarantee, constraints, horizon, and current apparatus state.
- If one apparatus is already selected, test its credible adaptation path without inventing choice. If candidates are missing, use
C.18first. - Name available alternatives by their direct kinds and apply the shared eligibility predicate.
- For each current path, state the smallest adaptation/configuration work and the useful-result threshold: what must be learned, evidenced, integrated, or reviewed before the path can improve the use.
- Compare available time and budget, prior exposure, post-threshold efficiency, transfer, retention, interoperability, downside, reversibility, and expected reuse using values supplied by their subject patterns. Do not compress them into an undeclared scalar.
- If choice is current, consume one lawful
C.11 ChoiceResult; otherwise continue on the one-apparatus path. - Prepare the needed
A.15.2plan or, for tool-call enactment,C.24call plan. Have the admitted system performA.15.1work. - Inspect the separately governed problem-facing result. Keep an application/configuration note only when reuse, dispute, automation, or consequence makes it useful.
Stop and reopen
Stop when the direct result is usable at the claimed guarantee and no additional distinction or setup burden has an expected practical return for the declared use and horizon. This is a positive result, not a claim that the unused apparatus is inferior.
Reopen when a consequential counterexample, failed result, changed use or guarantee, changed recurrence horizon, new candidate path, automation need, or changed adaptation cost alters the lawful path. Reopen only the affected application, candidate, choice, plan, or work question under its subject pattern.
Optional demonstration, not an admitted structure
A short branch presentation may show one-apparatus, candidate-generation, choose, probe/reject, application, result, and reopen continuations as a ProvisionalUnfoldingDemonstrationDescription@Context. It is an episteme for teaching. It is not an admitted U.Structure, CGUS, work plan, work occurrence, or result; admission requires every A.22.CGUS coordinate independently.
Archetypal Grounding
Repeated audited handoffs. A fleet has 400 maintenance handoffs each year. The required result is an audited maintenance-decision episteme with a fixed safety and interoperability guarantee. Candidate generation is complete: an ontology-backed method description and a lighter local decision method are eligible; a spreadsheet macro is excluded because it cannot preserve required relation-occurrence identity. C.11 returns choose now for the ontology-backed method because recurrence amortizes configuration.
An admitted maintenance-information System performs the dated configuration and application Work using the selected ontology-backed Method. The account recovers the System's A.13 core and independently admits the Work under A.15.1. Because the current question is whether setup cost is repaid across the handoffs and consumes no exact assignment-bound attribution, this short example does not open F.6 or expose assignment identity, species, participants, or attribution detail. A later attribution-bearing claim adds F.6 through the same obtaining A.13 assignment.
A separately admitted maintenance-decision System then performs decision Work using the selected Method. Its A.13 core and independent A.15.1 Work admission are recoverable; this setup-cost example consumes no exact assignment-bound attribution, so F.6 remains unopened. Under A.6.1, application MaintenanceDecisionApplication-1 of operation DecideMaintenance, declared by MaintenanceDecisionMechanism-E1, returns AuditedMaintenanceDecision-1 under result declaration DecisionResult; no Work-to-result or production claim is made. If repair or audit cost does not fall after the declared sample, reopen the apparatus application.
One-off naming repair. A team already has the direct typed-relation method for one local, reversible naming decision. No rival is live and the current method has a credible small path, so no option set or choice result is created. The team performs the minimal wording and typing work and returns a scoped terminology decision. Recurrence, integration, a failed result, or a stronger guarantee may later open candidate generation and choice.
Non-use. If the blocked result comes from missing telemetry while the method, state kinds, and action distinctions are already clear, return to measurement and evidence work. Apparatus selection cannot manufacture the missing observation.
Bias-Annotation
Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: cross-domain bounded application work.
The main bias is prestige-by-apparatus: richer form, newer tooling, or familiar terminology is treated as practical superiority. The mitigation is one declared result and guarantee, direct-kind candidates, actual adaptation/work cost, and a positive one-apparatus path. A second bias is automation optimism; cheaper computation does not erase evidence, human attention, integration, or consequence review.
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
The pattern makes cheap, truthful use a first-class result. Teams can apply one current method without ceremony, yet repeated or consequential uses can justify configuration or a real choice. The cost is naming the result, guarantee, applicable condition or predicate, and enough work economics to support the path. That bounded burden prevents apparatus display from replacing practical return.
Rationale
Application is the common job; selection is conditional. Starting from application preserves the frequent case in which a subject pattern is already selected and only the next useful adaptation matters. When alternatives are real, existing generation and choice patterns provide better result semantics than a fifth local decision vocabulary. Direct-kind discipline prevents an umbrella comparison word from becoming a new ontology.
The aphorism is: make the apparatus earn its setup work.
SoTA-Echoing
These sources change the positive method: the user starts from a result, may obtain value before total configuration, opens choice only for a live set, and reopens when use economics or guarantee changes. They do not license prestige ranking, tool mandates, or a universal apparatus kind.
Relations
- Coordinates with:
C.18for candidate generation and reframing;C.19for candidate/front stewardship;C.19.1for scale-amenable bearer preference;C.22.1for adaptation signatures;E.23for repeated improvement; andC.31.ASAPfor architecture-scale preference. - Uses conditionally:
C.11only when an actual local-choice question over a live eligible set exists. It consumes, but does not extend, the fourChoiceResultdispositions. - Hands off enactment to:
A.15.2for work plans,A.15.1for dated work, andC.24only for tool-call enactment planning. The direct domain pattern contains the defining content for the practical result. - Description-level specialization:
A.7.1narrows the method claims stated here for consequence-guided ontology analysis. It retains the declared use, problem-facing result, claimed guarantee, horizon, useful threshold, separation among plan, Work, and result, stop, and reopen. It retains the candidate and choice branch only when that branch is actually triggered. This wording adds no relation occurrence between the described Methods and asserts neitherU.SubkindOfnor a world relation. - Does not replace: durable U-kind admission in
E.24/E.24.UK, parsimony inA.11, evidence-use and assurance patterns, or any candidate's direct kind.
C.19.2:End
Composition of U.Discipline (Discipline-CAL)
Status: Stable Type: Pattern
E.24.UK settlement
U.Discipline is the admitted durable holon kind for one exact field-level practice-and-knowledge whole. C.20 supplies the kind-specific construction criterion; A.1 recognizes one exact candidate under that admitted kind only after the candidate, constituents, obtaining constructive relations, assembly, identity or reidentification rule, composition-grounded whole characteristic, and larger-assembly compatibility are recoverable.
The kind is not established by a field name, subject domain, curriculum, department, professional body, journal, bibliography, standards folder, method family, bridge set, comparison policy, publication set, selected relation structure, or count of local viewpoints. A discipline is not a U.System or U.Episteme by default. A system, episteme, method, work occurrence, publication occurrence, bridge, comparison, and selected U.Structure retain their own identities even when they are used in work concerning a discipline.
C.20 directly governs the narrow DisciplinePartOfRelation and the complete discipline-construction test. It does not introduce separate public U-kinds for applied discipline, transdiscipline, tradition, or lineage. Applied, multidisciplinary, transdisciplinary, tradition, lineage, school, and edition wording remains useful only as a separately governed classification, historical claim, or description whose exact criterion is stated.
Use This When
Use this pattern when a team needs to decide whether an apparent field is one durable practice-and-knowledge whole rather than a convenient label or collection. Typical moments include:
- comparing rival traditions within or across apparent disciplines without letting a shared label, Bridge, or comparison table merge them;
- moving one practice across semantic localities while preserving the exact local meanings, direction, tolerated loss, and discipline boundaries;
- judging whether an exact Method or method family actually belongs to a field assembly rather than being merely registered, used, cited, published, compared, or taught there;
- keeping discipline continuity inspectable while its canon, standards, or accepted practices change, and identifying another whole when the reidentification rule fails;
- deciding whether a research or engineering field has exact parts and a continuing identity;
- deciding whether a theory, school, standard, or subdiscipline is actually a part;
- using an applied, multidisciplinary, or transdisciplinary label without letting breadth wording create a kind or whole.
Primary EntityOfConcern. One exact U.Entity candidate being tested for recognition as U.Discipline. The candidate is recoverable before the classification result; calling it a candidate discipline does not make the result true.
First useful move. Name the exact candidate and two independently identified candidate parts: at least one making a knowledge-bearing contribution and at least one making a reusable-practice contribution. Then state why each direct part relation obtains and one whole-forming fact that couples the two contributions. Do this before letting the discipline name support a comparison, selector or dispatcher, health or maturity claim, transport, or edition decision. If those facts are unavailable, stop at the separately governed objects or collection.
What goes wrong if missed. A field name starts doing the work of a canon, method repertoire, institution, bridge, comparison policy, and maturity score at once. A card or graph can then manufacture parts, and changes to a journal, standard, method list, or dashboard can silently manufacture a new discipline. Cross-locality reuse can also look valid after local meanings, evidence lanes, or comparison rules have drifted.
What this buys. A practitioner can say what the discipline is made of, how the exact parts form one practice-and-knowledge whole, what remains the same through change, and which surrounding objects are merely used by discipline work. That makes comparison, transport, stewardship, and edition work inspectable without reducing the field to a document list or domain label.
Not this pattern when. Use domain or catalogue work for a subject-area label; the effective ReferenceScheme, ClaimScope, F.17 local-sense row, and F.9 only when applicable for one local meaning or crossing; C.2.1 and its publication or source-use patterns for one theory, standard, canon item, or their exact episteme edition; C.3, C.2.1, and direct historical or provenance relations for a school, variant, lineage, or classification; A.3.1 and B.1.5 for a Method or composite Method; A.15.1 for dated Work; A.22 for a selected relation organization; A.19.CPM for an actual comparison; C.21 for field-health characteristics; and E.24.PUB for publication. Use C.20 when determining, explaining, or relying on whether one exact field-level candidate has the required construction and continuity. The result may be true, false, or unknown; when the constructive facts are unavailable, stop at a collection.
Problem Frame
Disciplines can persist while theories, standards, methods, organizations, publications, and vocabulary change. In practice that persistence is carried and refreshed through knowledge canons, codified practices and standards, and institutional carriers such as journals, professional bodies, curricula, committees, and laboratories, while none of those carrier families is identical to the discipline. FPF therefore still needs a typed, provenance-preserving field-level composition account. That persistence cannot be explained by a stable name or by one fixed five-position card. It needs exact constituents, direct constructive part relations, whole-forming facts, a field assembly, a reidentification rule, and a whole characteristic that the composition produces or sustains.
The practice side and knowledge side must both be real. A bibliography without reusable ways of investigating or intervening is a knowledge collection. A method catalogue without field-level claim organization is a repertoire. An institution may sustain both through work, but the institution is still a separately identified system. C.20 asks when exact parts and their couplings warrant one further whole.
Problem
Without a direct construction test:
- labels, organizations, document sets, curricula, or registries are mistaken for disciplines;
- a canon item or method is called a part merely because a community cites or uses it;
- rival traditions are either flattened into false consensus or treated as separate disciplines without an identity test;
- a changed standard, publication, or health score is mistaken for a new discipline edition;
- bridge loss, comparison admissibility, evidence strength, and selector policy leak into discipline identity;
- an optional selected structure is treated as a context holon, subdiscipline, or breadth count.
Forces
Solution - recover the whole from direct construction
Run the complete recognition test
Recover six constructive components for the same exact candidate:
- Exact candidate. Identify one exact
U.Entityand its proposed field boundary. A public name or description is only a designator or episteme about that candidate. - Exact constituents. Identify every claimed part under its direct kind and identity pattern. The construction must contain at least one exact knowledge-bearing contribution and at least one exact reusable-practice contribution; these are assembly contributions, not fixed part kinds or heterogeneous card positions.
- Constructive part relations and assembly. Recover each obtaining
disciplinePartOf(part, candidate)occurrence and every other exact whole-forming claim needed by the assembly. A list, co-use, adjacency, or common publisher supplies none of them. - Identity and reidentification rule. State which constituent, relation, boundary, or coupling changes preserve this candidate and which identify another whole or end the current one.
- Composition-grounded whole characteristic. State at least one exact A.17-governed Characteristic whose value or state is produced or sustained by the practice-and-knowledge composition and is not attributable to one constituent alone. Use A.18 for Scale legality and C.16 only when an actual value is measured.
- Larger-assembly compatibility. State the candidate boundary, exposed practice-and-knowledge interfaces, relevant whole characteristics, and identity-preservation conditions that make it admissible as a possible constituent under at least one governed larger field assembly. This establishes possibility, not an actual larger-discipline part relation.
The candidate is recognized as U.Discipline only when all six components and the C.20-specific practice-and-knowledge condition hold. A materialized classification assertion is a separate C.2.1 episteme about the candidate. Evidence can support that assertion and receiving work can rely on it, but neither creates the discipline.
Direct DisciplinePartOfRelation
C.20 directly governs DisciplinePartOfRelation, expressed in Plain register as disciplinePartOf(partEntity, candidateDiscipline). The first participant is one exact U.Entity already identified under its subject pattern. The second is the exact candidate U.Entity under the C.20 test; this participant meaning does not presuppose that the candidate has already passed the test.
The predicate obtains throughout an interval exactly when all of the following are true:
- the candidate's actual field assembly includes the exact part as a required contributor or a currently realized admitted alternative for one required knowledge-bearing or reusable-practice contribution;
- at least one exact whole-forming claim connects that contribution to the candidate's field boundary, to another required contribution, and to the declared composition-grounded whole characteristic;
- the candidate's direct reidentification rule treats the current part, its contribution, and any allowed replacement as belonging to this continuing assembly.
Mere eligibility for future use is insufficient. A source citation, canon list, standards list, registry row, curriculum position, organizational affiliation, publication, common label, diagram containment, shared audience, bridge endpoint, comparison row, selected structure, work participation, evidence relation, or health reading does not make disciplinePartOf obtain.
One occurrence is identified by <exact part entity, exact candidate, maximal continuous obtaining interval>. If the same part leaves the assembly and later returns, the two episodes are distinct occurrences. A changed observation or evidence window does not split an ongoing occurrence; actual cessation and resumption under the direct predicate do. Reidentifying either participant also identifies another occurrence.
Multiple contribution claims for the same part do not create several part occurrences during the same continuous interval. If typed declaration reuse is needed, the direct relation has only the two participant meanings above. Canon, practice, organization, bridge, comparison, policy, evidence, publication, and structure fields are not additional SlotSpecs. Qualifiers and whole-forming claims keep their subject patterns.
State whole-forming claims before choosing notation
Part relations alone do not make one discipline. State the field assembly in ordinary domain language:
- which exact claim-bearing contributions supply the field's knowledge commitments, distinctions, explanatory resources, or admissible questions;
- which exact methods or other independently governed parts supply reusable ways of investigating, designing, intervening, evaluating, or learning;
- which claims make knowledge contributions constrain, explain, or qualify practice contributions;
- which claims make separately governed results of actual practice relevant to evaluation, revision, or replacement of knowledge contributions;
- how incompatible or rival contributions coexist without being silently equated;
- which boundary, stop conditions, exposed interfaces, and substitution conditions keep the assembly one field-level whole.
Each whole-forming statement stays at the lightest truthful disposition supplied by its direct relation pattern or A.6.RCD: an existing direct predicate, a local compound claim, or a reusable predicate-definition episteme. A readable arrow such as uses, supports, tests, belongs to, standardizes, or aligns does not admit a relation kind and does not make a part relation obtain.
The assembly rule names the exact current part relations, contribution meanings, whole-forming claims, permitted alternatives, incompatibilities, boundary conditions, failure conditions, and substitution conditions. A C.13 Gamma_m.sum construction trace may report those facts when a named use needs an inspectable account. The trace is a C.2.1 episteme and creates none of the parts, relations, assembly, identity, or characteristic.
The historical signature was Γ_disc : ⟨EpistemeCanon, StandardsSet, OrgCarriers, {Bridges}, Policy⟩ → U.Discipline. Retain it only as a migration map into the direct construction account. Its useful intent was to assemble a reviewable field-level whole account, preserve provenance, support separately governed publication of that account, and enable admissible comparison; none of those receiving functions creates the whole.
Every former argument remains available but loses automatic constructor and identity force: EpistemeCanon routes to exact canon epistemes and their claims; StandardsSet to exact standard epistemes, Methods, and practice claims; OrgCarriers to independently identified systems, system-role kinds and assignments, and Work; {Bridges} to exact F.9 occurrences and bounded-use propositions; and Policy to exact comparison, evidence, assurance, and acceptance declarations under their subject patterns. Section 4.6 preserves every named member of those intake families. Historical Gamma_disc expressions are therefore only incomplete shorthand for a C.13 construction account. A five-field argument list, Discipline Card, or filled schema does not complete the account and does not have constructor force.
Identity, continuity, and change
The discipline's identity is not the extensional part list. It is the exact candidate with its field boundary, practice-and-knowledge assembly principle, obtaining constructive relations, whole-forming architecture, and declared whole characteristic under one direct reidentification rule.
The same discipline may continue through a permitted canon revision, method replacement, institutional change, publication change, or temporary part-relation change when the rule admits that variation and the field boundary, required contribution meanings, essential couplings, and whole characteristic remain within their declared continuity conditions. The rule must say which substitutions are permitted and how the replacement contribution reconnects to the assembly.
A change outside those conditions identifies another candidate or leaves the stronger claim unresolved. When a receiving use asks whether the old whole can still explain the case, run B.2's existing-whole explanation check after the direct C.20 facts are recovered. Loss of evidence, another description edition, a renamed field, or a stale registry entry does not itself end or create a discipline.
"Discipline edition" is therefore not one automatic object. Recover the changed subject:
- revised canon, standard, method description, classification assertion, or discipline description is another C.2.1 episteme when its identity discriminator changes, with historical continuation tested separately;
- a newly available edition has its own E.24.PUB publication occurrence, form, carrier, audience, use, and availability interval;
- an unchanged discipline during a proper interval may be described through the direct temporal and A.14 phase route;
- a changed field assembly outside the reidentification rule requires another discipline candidate, not a renamed description.
Keep the change rationale as claim content of one exact C.2.1-identified revision or decision episteme. When historical continuation is asserted, the assertion about the exact EpistemeEditionRelation cites the exact source use, applicable continuity policy or rule, and the preserved and deliberately changed claim, EntityOfConcern, and scheme features that the rule consumes. Revision Work, Method, provenance, change facts, and evidence are case facts; no label establishes continuity. When availability changes, trace the publication transition through the ending and beginning E.24.PUB occurrences with their selected edition, audience, bounded use, form, carrier, and availability intervals. The rationale, edition-relation assertion, publication occurrences, and discipline reidentification result remain distinct; none decides another merely by being recorded.
Require a composition-grounded whole characteristic
Name at least one exact Characteristic under A.17, its Scale under A.18, and its direct measurement or evaluation route only when a current use needs a value. A useful local choice is the degree to which the assembly sustains a replayable practice-knowledge coupling: independently identified knowledge contributions constrain field practice, and separately governed practice results can be used to test, revise, or replace those knowledge contributions under declared rules. This is a local characteristic choice, not a new universal kind or scalar score; C.16 governs a measurement chain only when dated measurement Work actually attributes a value.
The value must depend on the composition. Citation count from one episteme, frequency of one method, size of one organization, bridge count, publication count, or a single maturity label is not a composition-grounded whole characteristic. Rival traditions can coexist when their boundaries, incompatibilities, permitted uses, and contribution relations are explicit; cohesion does not require false consensus.
C.21 is the pattern for discipline-health characteristics such as reproducibility, standardization, diversity, and disruption balance. A health reading can reveal pressure to inspect construction or reidentification, but it is not a part, assembly fact, identity rule, or classification result.
Keep neighboring objects with their subject patterns
Keep the three boundaries explicit. A domain is a subject-area or catalogue designation. A semantic locality is the bounded use of exact local meanings under its effective ReferenceScheme, ClaimScope, and direct F.17/F.9 patterns; it is not another holon or a discipline constituent by locality alone. A discipline is the exact field-level practice-and-knowledge whole recognized by the C.20 construction test. The same or similar word across domains or semantic localities establishes none of shared meaning, one discipline, parthood, or identity. State the exact local senses and any obtaining Bridge for a crossing, then test each discipline candidate independently; even a high-congruence Bridge does not merge its endpoints.
The historical five-position card remains a useful intake palette only if every member keeps its subject pattern and receives no automatic part or identity status. Its complete prompts were:
- canon candidates: theories, models, reference works, definitions, proof traditions, benchmark descriptions, and other epistemes treated as canonical;
- practice and standard candidates: accepted Methods, norms, standard procedures, measurement conventions, and admissible comparison rules;
- institutional and organizational candidates: journals, committees, curricula, professional bodies, laboratories, and other institutional arrangements that may carry or refresh field work;
- cross-locality candidates: exact F.9 Bridges, F.17 term or local-sense rows, Bridge descriptions, and loss observations used across semantic localities or source traditions;
- comparison candidates: exact Characteristics, Scales, Units, comparators, evidence policies, and CG-Spec declarations used to make a named comparison admissible.
The palette prevents those reader questions from disappearing; it is neither a required five-part decomposition nor a constructor. No category must be filled by ritual. Every exact item remains under the subject pattern below and becomes a C.20 part only when disciplinePartOf independently obtains.
Any entity in this table can become an actual part only when it is independently identified and the C.20 predicate separately obtains. Its ordinary association with the field is never enough.
Optional bounded-model-use structure
Discipline work can use an independently selected BoundedModelUseStructure when the selected organization of exact relations changes how a named model is interpreted or used in that work. State the exact model, direct relation occurrences, selection basis, receiving work or claim, and the organization that matters. A.22 is the pattern for the structure and A.15.1 is the pattern for the dated work.
The structure is optional. It is not the discipline, a constituent by selection, a subdiscipline, a context count, a description, a viewpoint, a whole characteristic, a breadth classification, or a second identity carrier. Several selected structures used in work about one discipline do not create several disciplines; one structure used across several disciplines does not merge them.
Breadth, tradition, lineage, and school claims
Applied, multidisciplinary, transdisciplinary, tradition, lineage, and school labels do not carry a universal C.20 classification rule.
- For a project-local kind, use C.3 to state exact intent, membership predicate, scope, and the candidate disciplines that satisfy it.
- A multidisciplinary claim normally needs several independently identified disciplines and exact contribution or use claims; co-listing fields or counting viewpoints is insufficient.
- A transdisciplinary claim must declare the integrative criterion that distinguishes it from side-by-side use. If the claim is that one new discipline exists, run the complete C.20 construction test for that new candidate.
- A tradition, lineage, school, variant, edition, or provenance claim identifies its exact subject and the exact historical-continuation, source-use, method, similarity, edition, derivation, or provenance relation under that relation's subject pattern. Tradition or lineage can organize variants or editions within or across disciplines as an ordinary auxiliary value or a C.3 project-local kind; none is a discipline part, subkind, or public U-kind by label. A public kind requires its own direct governor, identity and use rule, and E.24.UK admission.
- An applied classification states what application-facing criterion is satisfied. Method use, one project, one organization, or one selected structure does not establish it by itself.
The classification can remain a C.2.1 claim without admitting another public U-kind. A changed label or classification result does not reidentify the discipline unless the direct C.20 rule independently says the field assembly changed.
Crossing, comparison, evidence, health, and publication are conditional branches
Open these branches only when the named discipline use actually needs them.
Cross-field or cross-sense use. F.9 first resolves two exact local senses and identifies one obtaining Bridge occurrence under its direct two-participant predicate and identity rule. Keep a separate current C.2.1 bounded-use proposition whose EntityOfConcern is that Bridge and whose ClaimGraph names the proposed action u, exact direction d, use-specific correspondence rule r, tolerated semantic loss t, and affirmative or negative polarity. Observed loss and counterexamples remain evidence; the permitted-loss tolerance remains claim content. Neither one reidentifies the Bridge.
For ordinary evidence reliance, use the exact A.10 evidence-provenance relation for the same bounded use. Only RelianceDisposition=pass supports that affirmative use; degrade supports only the named narrower use, while abstain, reopen, evidence-needed, assurance-needed, or blocked-current-use does not pass the attempt. Use B.3 only when an actual named assurance claim is current, and require its result for that same bounded assurance use. Authorization and any actual comparison, substitution, translation, publication, or Work occurrence remain with their subject patterns.
Crossing visibility and presentation checks. Keep the exact Bridge and bounded-use proposition discoverable in any account that relies on the crossing. Materialize an E.18 CrossingBundle only when a named selector, acceptance, audit, replay, or other downstream use relies on durable crossing evidence; E.17 governs publication packaging and A.21 governs any actual GateCheck or GateDecision. For lane purity, inspect the current B.3 result by value: every characteristic keeps its bearer and scale, and any aggregation cites its domain model and assumptions; there is no universal F-G-R-CL fold. Apply E.10 lexical checks to the published labels, keep normative prose notation-neutral, and treat every discipline column as didactic only.
Comparison or aggregation. A.17 identifies every exact Characteristic; A.18 supplies its Scale, Unit and legal operations; C.16 supplies a measurement result only when an actual measurement chain exists. A mean over an ordinal Scale and an aggregation that mixes unconverted or incommensurable Units are inadmissible: stop that operation, establish a lawful transformation or comparison scheme, or retain the separate values rather than manufacturing an aggregate. One actual A.19.CPM comparison application binds the profile pair, comparator, claim scope and selected slices, optional predicate, reference scheme and plane, evaluation point or interval, dated comparison Work, operation application, set-valued result, and evidence policy; CPM does not fold or aggregate. Any numeric or profile aggregation is a separate explicit A.19.ULSAM or applicable B.1 Γ-fold operation with its own dated Work and result binding. Before either operation, the applicable G.0 CG-Spec route names the exact Characteristic ids, ScaleComplianceProfile with Scale, Unit, polarity and legal-operation conditions, MinimalEvidence, and either the admitted ComparatorSet member for comparison or the declared Γ-fold and contributors for aggregation. This pre-operation admissibility check fails closed on missing or unknown declarations or evidence and creates neither equality, an aggregate, nor a winner. A cross-scheme or cross-plane use adds the exact F.9 Bridge and bounded-use reliance branch, but the Bridge supplies none of the scope, predicate, comparator, plane, time, result, or selection.
Evidence, currentness, and assurance. Use A.10 for source use and the evidence-provenance path, and G.11 for selected-edition currentness. When an imported source claim supports a construction, classification, comparison, publication, or assurance use, keep the exact source and edition plus only the lane tags, freshness window, or validity conditions that the receiving use consumes. Claims that need no such reliance acquire none of this apparatus merely because they concern a discipline. Open B.3 only for an actual named assurance claim. Its AssuranceResult identifies the target claim, assurance use, basis, disposition, limits, and reopen condition. If the argument consumes a characteristic or calculation, name its bearer, property, scale, unit, interpretation, basis, dependency model, assumptions, rule, and rival as applicable. C.20 supplies no default F/G/R/CL lanes, weakest-link fold, SpanUnion, congruence penalty, plane penalty, or assurance arithmetic. State ReferencePlane only when it changes an exact input or interpretation; it identifies neither a discipline part nor a part relation. Insufficient or unknown support narrows, abstains, requests evidence, reopens, or blocks the attempted assurance use under B.3; it does not make a part relation or whole obtain or cease.
Health or state view. C.21 can evaluate typed discipline-health characteristics. Local values such as emerging, consolidating, codified, or fragmenting require their own criteria, Scale, evidence basis, qualification window, and currentness. Any decision threshold belongs to the relevant G.4 AcceptanceClause. A state label, health vector, score, or dashboard transition is descriptive and does not itself reidentify the discipline.
Description and publication. A discipline description, construction trace, comparison report, health series, card, or registry row is a separately identified C.2.1 episteme. E.24.PUB governs any actual publication occurrence and keeps selected episteme edition, audience, bounded-use declaration, form, carrier, and availability interval distinct. Updating or publishing the account changes neither the field assembly nor its past.
Archetypal Grounding
Keep the System/Episteme contrast without making the table a constructor
The former Tell-Show-Show contrast remains useful because it asks five different reader questions. Read every cell as an independently governed example, not as a slot or a recipe for manufacturing a discipline.
Safety engineering as a positive construction
Suppose SafetyEngineering-SE is one exact field candidate. C.2.1 independently identifies HazardCausalityCanon-v5 as a claim-bearing episteme. A.3.1 independently identifies HazardAnalysisMethod-v4 and IncidentLearningMethod-v2 as reusable Methods. None is a C.20 part yet.
The field assembly makes these exact contributions current:
HazardCausalityCanon-v5supplies the hazard, causal, and acceptable-argument meanings used by the two Methods;HazardAnalysisMethod-v4supplies the reusable analysis practice by which those meanings constrain identification and treatment of hazards;IncidentLearningMethod-v2supplies the reusable practice by which separately governed incident and evaluation results can challenge or refine the canon claims.
The three exact relation occurrences are disciplinePartOf(HazardCausalityCanon-v5, SafetyEngineering-SE)@I-SE-core-1, disciplinePartOf(HazardAnalysisMethod-v4, SafetyEngineering-SE)@I-SE-core-1, and disciplinePartOf(IncidentLearningMethod-v2, SafetyEngineering-SE)@I-SE-core-1. They share the explicitly identified maximal current continuous obtaining interval I-SE-core-1 = [2024-04-01T09:00Z, open): its left boundary is the dated field-assembly activation at which all three contributions first became jointly required. At the continuation check 2026-07-31T23:59Z, each contribution remains required, the exact whole-forming claims still connect the canon meanings to method preconditions and result meanings, the same candidate and reidentification rule continue, and no cessation boundary has occurred; therefore the right boundary remains open. If any contribution ceases and later resumes, that part's interval ends at cessation and a new disciplinePartOf occurrence begins at resumption. The actual field assembly requires those contributions, and the reidentification rule admits them as current parts. The local A.17 Characteristic PracticeKnowledgeCouplingReplayability has the exact subject SafetyEngineering-SE and the ordinal A.18 Scale broken < partial < replayable: its criterion asks whether the named canon-to-Method constraints and result-to-canon revision routes remain executable across the declared safety-work classes. No constituent can have that whole value alone. If a current use needs an attributed value, C.16 requires the exact measurement subject, method, model, Scale, dated measurement Work, uncertainty, and result episteme; the label alone supplies no reading.
The reidentification rule permits a compatible canon revision or replacement Method only when the field boundary, causal and argument meanings, practice-knowledge feedback, and whole characteristic remain within declared continuity conditions. Removing the feedback route, changing the governing safety concern and field boundary, or replacing the assembly by unrelated document and method lists falls outside the rule.
Safety Journal, a standards committee, a university curriculum, a laboratory, a bridge to resilience-engineering terminology, a comparison CG-Spec, and a published discipline card remain separately governed. They are not parts in this case because no separate C.20 predicate has been established for them. For any precise review or teaching Work, use A.13 to identify the actual performer and A.15.1 to admit the dated occurrence independently; add F.6 only if this case must also state exactly under which assignment that Work was performed. The Work may enact a part Method, but it neither becomes the discipline nor proves the three part relations.
For A.1's larger-assembly test, the separately identified rule episteme EngineeringFieldAssemblyRule-v3 describes a governed larger-field construction whose applicability requires one constituent field to expose stable hazard-constraint meanings, analysis-result meanings, and identity-preserving interfaces to design and verification practices. SafetyEngineering-SE has those actual interfaces and its reidentification rule preserves them, so it is compatible with that possible assembly while remaining the same candidate. The rule episteme does not create the compatibility facts, and this result asserts no actual disciplinePartOf(SafetyEngineering-SE, Engineering-E) occurrence.
A C.13 Gamma_m.sum trace may report the candidate, three parts, three part-relation occurrences, whole-forming claims, assembly, reidentification rule, and whole characteristic. Writing or publishing that trace does not construct SafetyEngineering-SE.
A department, corpus, and method registry are not yet a discipline
Safety Department A performs research and teaching Work. Its repository contains standards and papers, and its registry lists analysis Methods. Those facts establish a system, Work, epistemes, publications, and registry membership under their subject patterns.
They do not yet establish which exact entities are field constituents, any disciplinePartOf occurrence, a practice-knowledge assembly, one whole characteristic, or a reidentification rule. The useful result is the recovered collection and work organization. Stop before U.Discipline; do not fill missing canon, carrier, bridge, or comparison positions merely to complete a card.
Cross-field reuse does not create a transdiscipline
A safety-engineering team reuses one resilience-engineering term. F.9 identifies the two exact local senses and an obtaining directed Bridge. A separate bounded-use proposition states the direction, mapping rule, tolerated loss, and polarity for this hazard-review use. Exact review Work may rely on that proposition through A.10, and a comparison may apply A.19.CPM.
These facts establish no disciplinePartOf occurrence and no new discipline. Calling the work transdisciplinary requires a declared classification criterion. Claiming one new integrated discipline requires another exact candidate and all six C.20 construction components; one Bridge, two labels, or two selected structures cannot supply them.
Canon revision, same field, and another field
HazardCausalityCanon-v6 changes claim content and is another C.2.1 episteme. Historical continuation from v5 is tested separately. The same SafetyEngineering-SE can continue if its C.20 rule permits that replacement and the required contribution meanings, whole-forming couplings, boundary, and whole characteristic persist. The old part occurrence ends and the new one begins; a description or evidence window does not decide those intervals.
If the replacement rejects the field's former causal object, changes the practice-knowledge feedback rule, and changes the field boundary beyond permitted continuity, the same-discipline claim fails. The project then tests another candidate and uses B.2 only if a receiving use needs a whole-reidentification conclusion. A new canon edition, renamed department, or republished card alone decides neither branch.
Bias-Annotation
Apply five complementary lenses; the later risk table does not replace them.
Scope guard. Every use is bounded by exact field candidates, semantic localities, scopes, editions, and receiving work. There is no context-free or global discipline established by name, popularity, institutional reach, or a shared vocabulary.
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
Benefits. Discipline claims become auditable without freezing one universal canon, institution, bridge set, or method repertoire. Rival traditions can remain explicit and federate only through admissible directed uses rather than false consensus; constituent replacement and genuine reidentification can be distinguished. Field comparison and dispatch can consume the exact construction without becoming its cause. A selector can additionally consume exact discipline-relevant Characteristic and evidence or assurance claims, while an admitted publisher System can perform publication Work that yields a readable didactic presentation without making its title, card, column, or registry ontological. Any stewardship, responsibility, authority, ownership, or assignment is stated separately when it independently obtains.
Costs and trade-offs. A positive claim needs exact parts, direct relation intervals, whole-forming claims, an assembly, a reidentification rule, one whole characteristic, and a larger-assembly compatibility account. The cost is proportional: ordinary use can stop at readable sentences. A named comparison adds Scale, comparator, and CG-Spec literacy; a cross-locality use adds Bridge and reliance hygiene; trace, evidence, publication, health, selector, or assurance apparatus is added only for a named receiver. That extra explicitness pays back in safer reuse and clearer governance.
Risks avoided. The pattern blocks label-made fields, institution-made identity, publication-made parts, context-count breadth, bridge-made merger, health-score ontology, and registry-made method or discipline membership.
Rationale
A discipline is durable because a governed practice-and-knowledge assembly can continue through permitted replacement, not because all surrounding artifacts remain fixed. Direct part relations establish which exact entities are constitutive during which intervals. Whole-forming claims explain their contributions and coupling. The assembly and reidentification rule then distinguish continuity from a different field, while the composition-grounded characteristic shows why the candidate is a whole rather than a collection.
Keeping organizations, Work, methods, epistemes, structures, Bridges, comparisons, publications, evidence, and health readings separate does not make them unimportant. It lets each object affect the discipline claim through its actual relation without being promoted to an automatic part or identity discriminator.
This separation keeps every discipline-related claim local to an exact EntityOfConcern and effective ReferenceScheme, comparison admissible only under its current Scale and comparator declarations, and evidence-bearing reliance or assurance explicit under A.10/B.3. It also lets plural traditions, directed Bridges with visible loss, typed health readings, and TA/VA/LA evidence lanes remain inspectable together. Scale compliance, B.3's requirement for an applicable domain model and stated assumptions, and Bridge hygiene stay with their subject patterns: C.20 adopts their constraints for a named use but defines no universal field score or reliability fold. Charisma, prestige, institutional reach, or an attractive field name cannot create a discipline that fails to return to exact construction, Characteristics, and source evidence.
SoTA-Echoing
Currentness and reopen. Reopen only the affected construction, identity, crossing, or health decision when its direct source interface changes. A newer discipline study can change the local breadth criterion or worked case without weakening the exact-part, direct-relation, assembly, and reidentification boundary.
Relations
Builds on. A.1 for constructive holon recognition; A.6.REL for relation-occurrence discipline; A.14 and direct part patterns for mereological meaning; C.13 for an optional construction trace; A.17 and A.18 for the composition-grounded Characteristic and Scale, with C.16 only for an actual measurement chain; E.24.UK for public-kind admission.
Coordinates with. C.2.1 for canon, standard, classification, description, trace, and result epistemes; A.3.1 and B.1.5 for Methods and method composition; A.15.1 for dated discipline work; A.22 for optional selected structures; B.2 for a separately current whole-reidentification question; C.3 for project-local breadth and tradition classifications; C.22 for selector-facing problem typing and TaskSignature assignment; C.23 for MethodFamily evidence and maturity; E.10 for lexical precision; and F.17/F.18 for local-sense term publication and durable naming.
Conditional branches. F.9 for exact Bridges; A.10 and B.3 for evidence-bearing reliance and assurance; C.21 for discipline health; A.19.CPM for comparison and G.0 for its CG-Spec admissibility declaration; G.4 for acceptance thresholds; E.24.PUB for publication; G.5 for selector use of independently grounded discipline or method claims.
G.2 source-pack boundary. When one current G.2 harvest or synthesis informs a discipline account, preserve the anti-monoculture intent by keeping plausible rival lineages and the semantic localities relevant to that named synthesis visible, with an explicit coverage or omission rationale and explicit crossings where needed. C.20 sets no minimum number of Traditions, local frames, cards, contexts, or matrix rows; G.2 alone governs conformance of its pack. A plural or conforming pack, TraditionPalette, BridgeMatrix, or historical Gamma_disc expression still constructs no discipline and supplies no part relation.
Constrains. A C.13 discipline trace consumes C.20 facts and creates none. C.21 evaluates an already identified discipline. G.5 may consume an independently identified Method together with exact discipline-relevant construction or classification, Characteristic, and evidence or assurance claims only through its own declared predicate. An ungrounded discipline name supplies none of field belonging, comparison value, evidence strength, selection, or truth. A registry or family row, selector request, policy, result or shortlist, CG-Spec reference, and EvidenceGraph row can make an actual G.5 use auditable; none lets G.5 infer Method membership, discipline parthood, actual selector application or selection, or claim truth. A selected structure, Bridge, comparison, publication, evidence graph, health reading, or label never supplies a missing C.20 part occurrence.
C.20:End
Field Health & Structure (Discipline-CHR)
Status: Stable Type: Pattern
Purpose. Give FPF a typed, reviewable way to characterize the health, maturity, and structure of a scientific or engineering discipline without collapsing the result into taste, anecdotes, a dashboard view, an audit label, or one score. C.21 defines discipline-health Characteristics and the conditions under which their readings may be compared. It does not make a dashboard, publication, record, or Work occurrence part of the discipline.
Use This When
Use this pattern when a team must say something practical about the health, maturity, or structure of an already identified discipline. Typical questions concern reproducibility, formal standard status, actual adoption, cross-tradition alignment, disruption balance, evidence resolution, diversity, engineering-claim recoverability, or pressure to mistake representations for their subjects.
What goes wrong if missed. Field-health claims become attractive labels: incompatible readings are compared, ordinals are averaged, formal approval is treated as adoption, entropy and concentration are read in the same direction, stale evidence looks current, and a dashboard or standards list starts acting as the discipline or as proof of health.
What this buys. A cold reader can recover one health claim, its Characteristic and Scale, the discipline and claim scope, the comparison and time or population basis, the measurement definition when one is used, and the exact extra relation required only for an actual cross-local comparison.
First useful move. Name the discipline and practical question, choose one relevant Characteristic, state its scope and comparison basis, and say in ordinary language what the current material supports and what it does not. Stop there when the receiving use needs no measured comparison, aggregate, reusable series, or publication.
Not this pattern when. Use C.20 to decide whether the candidate is a discipline, C.16 to construct a measurement, A.19 for comparison or aggregation work, F.9 only when the use actually relates distinct local senses, E.24.PUB for audience availability, G.12 for a reusable dashboard view, and G.4 for an acceptance threshold. C.21 supplies none of those results merely by naming a health Characteristic.
Placement. Part C, Cluster C.I. Builds on: C.20, A.17, A.18, C.16, A.2.6, C.2.1. Coordinates with: F.9, G.0, G.4, G.9, G.11, G.12, E.24.PUB.
Problem Frame
Disciplines aggregate changing epistemes, practices, standards, institutions, and Work. Teams routinely say “replication is improving,” “the field is fragmented,” or “standards are converging.” Such a sentence can be useful before it becomes a dashboard row, but any relied-on comparison needs exact Characteristic, Scale, measurement, scope, and basis semantics.
C.21 therefore treats health as a vector of separately typed coordinate claims. It does not imply one scalar health value. A threshold or target band is an acceptance declaration under G.4, not part of the Characteristic. A dashboard is a representation over already constituted claims, not their ontology or authority.
Problem
Five recurrent failures make discipline-health claims unreliable:
- Object collapse. A definition set, Method, MethodDescription, measurement Work, result episteme, series episteme, publication occurrence, form, and carrier are called one “DHC artefact.”
- Scope slippage.
ClaimScopeand a selectedTargetSliceare treated as interchangeable, although the scope states where the claim holds and the slice is only an optional computation or publication input. - False crossing. Different sources or editions are assumed to require a Bridge even when C.16 direct-comparability conditions hold; conversely, distinct local senses are compared without their obtaining F.9 relation and loss account.
- Scale collapse. Formal recognition is ordered with adoption, alternative ratios are called one Characteristic, or entropy and HHI are placed in one field despite opposite directions.
- Assurance inflation. A cheap readable claim is forced through evidence graphs, registries, dashboard pins, and publication machinery that its receiving use does not consume.
Forces
Solution — Discipline Health Characterisation (DHC)
The objects used by DHC
“DHC” names this vocabulary and method of use. It does not admit U.DHCPack, U.DHCMethodSpec, or U.DHCSeries as public kinds.
Rendering, measuring, assembling a series, uploading, and maintaining availability may each be Work when actually performed. A work record or carrier does not make that Work occur.
One replay basis for every persisted coordinate
Every persisted, compared, aggregated, or published coordinate makes the following values recoverable. This is a field group, not another public kind:
DHCReplayBasis := <DisciplineRef, IntendedUse, ClaimScopeRef, ComparisonBasis, CharacteristicRef.edition, ScaleRef.edition, UnitRef.edition?, DHCMethodRef.edition, MethodRef, MethodDescriptionRef.edition?, MeasurementModelRef.edition?, CalibrationBasisRef?, TimeOrPopulationBasis, DHCDefinitionSetRef.edition?, TargetSliceRef?, DistanceDefRef.edition?>
DHCMethodRef.editionresolves the same Characteristic, Scale, Method, MethodDescription, model, calibration, and uncertainty semantics named by the active fields. A mismatch is not repaired by choosing one field as “primary.”DHCDefinitionSetRef.editionappears only when a named reusable definition selection exists.TargetSliceRefappears only when the named computation or publication actually consumes an A.2.6 selection. Every selected slice must be shown to belong to, or otherwise be covered by, the authoritativeClaimScope; the slice never substitutes for that scope.DistanceDefRef.editionappears only when the Scale comparison or target-distance rule uses a separately declared distance.- Evidence paths, lane tags, currentness, assurance, acceptance, public names, and publication refs are added only when the receiving use consumes those separate results.
Portable Characteristics
Each bullet below names one exact Characteristic and Scale family. A DHC use selects only the coordinates needed by its question.
-
ReproducibilityRate — ratio in
[0,1]; Unitreplicated_claims/tested_claims; polarity higher-is-more-reproducible, not “healthier in every respect.” Declare the tested claim or benchmark population, independent-team condition, protocol, corpus or cohort, and time window. -
FormalRecognitionStatus — nominal by default. Values such as
none,draft,approved,withdrawn, or another lifecycle vocabulary belong to one named standards body and exact status scheme. Use an ordinal only when that scheme itself supplies a lawful order. There is no generalde facto < de jureladder and no default health polarity. -
PracticeAdoptionRate — ratio in
[0,1]; Unitadopting_units/eligible_units. Declare the population, adoption criterion, observation window, and treatment of partial adoption. Higher means wider observed adoption, not automatically better health or SoTA. -
AlignmentDensity — ratio; Unit
obtaining_relations/100_compared_cells. Count only exact obtaining F.9 relations in the declared F.17 cell set. Each counted relation has direction, admitted use, and loss. A higher value means denser declared alignment for that set; any health band belongs to G.4. -
DisruptionBalance — interval reading over one exact disruption/consolidation method and corpus. Polarity is target-is-best, using an explicit target-band distance rule; the band belongs to G.4 Acceptance.
-
EvidenceUnitResolution — ordinal, compare-only, under one exact segmentation scheme whose levels are nested, for example
artifact < section < claim < subclaim. Higher means a finer addressable unit under that scheme. It does not say how many claims an artifact contains or how densely claims are supported. -
ClaimsPerArtifact — ratio; Unit
claims/artifact, with exact claim segmentation and artifact population. It measures claim breadth or packing, not support density. Declare a target band when the use needs one; no universal monotone health polarity applies. -
SupportAnchorsPerClaim — ratio; Unit
anchors/claim, with exact anchor admissibility and claim segmentation. It measures support-anchor density, not claim size. It has no universal monotone health polarity. -
TraditionShareEntropy — one exact entropy Characteristic and Scale, with log base, normalization, category set, and population fixed. Higher entropy means greater dispersion on that scale. Any desired band is separate.
-
TraditionShareConcentration — HHI or another exact concentration Characteristic, normally ratio in
[0,1]; higher HHI means greater concentration and therefore lower dispersion. Do not place it in the entropy field.1 - HHImay be introduced only as an explicit transformation to a separately declared receiving Scale. Comparing that result with normalized entropy still requires an explicit common comparison rule.
Engineering-grade extension Characteristics
A discipline-health use may add these coordinates when its question needs them. They do not become evidence, assurance, gate, release, Work, or project-authority results.
-
EngineeringClaimJustificationRecoverability — ordinal, polarity higher-is-more-recoverable. It asks whether the exact construction, source, model, lens, or relation carrying an engineering claim's force can be recovered for the intended use. The reading cites the direct pattern and rule that define or constrain that force.
-
SemioSubstitutionPressure — ordinal or ratio as separately declared, polarity lower-is-less-substitution-pressure. It asks how often a representation, fluent wording, record, dashboard, view, or source chain is mistaken for its engineering subject, relation, or claim.
When either extension is active, add a short explanation naming the current claim kind or use boundary, the direct pattern and rule, admissible use, prohibited overread, and stop or reopen condition. The explanation is claim content, not a new evidence or assurance object.
Comparison and legality rules
- Direct same-semantics comparison. Compare readings directly when C.16's conservative conditions hold: the same measurement definition, Characteristic, Scale and Unit semantics, compatible model and calibration regime, and compatible time or population basis. Record the admitted comparison basis. Different source labels or editions alone require no Bridge.
- Cross-local comparison. When the use actually relates distinct F.17 local senses, additionally cite the exact obtaining F.9 relation, direction, admitted use, and loss. Any justified consequence affects R only. The relation supplies none of ClaimScope, measurement, comparison, or acceptance semantics.
- Reference-plane crossing. When a reading is used across distinct world, concept, or episteme planes, cite the exact crossing basis. Any assurance consequence affects R only. A dashboard row or source label does not establish the crossing.
- Cross-scale transformation. A conversion, normalization, distance, or aggregate names its exact Method, Scale, legal operation, and loss or uncertainty. No common scale is inferred from similar labels.
- Freshness. A persisted or reused coordinate carries its observation window and applicable currentness rule. Staleness leads to the receiving pattern's degrade, abstain, or reopen result; it does not rewrite the historical measurement.
- Target bands. “Target-is-best” is not “higher-is-better.” A comparison to a band uses an explicit distance-to-band rule and leaves the G.4 threshold separate. | Scale family | Lawful ordinary operations | Prohibited shortcut | | --- | --- | --- | | nominal status | equality, membership, mode when justified | lifecycle ranking or arithmetic without an ordered scheme | | ordinal resolution | order, median or mode where meaningful | mean, ratio, or affine arithmetic | | ratio rate or density | operations allowed by its exact Scale and Unit | unit mixing or comparison across changed construction | | interval balance | differences and target distance under its exact rule | ratios or silent target-band polarity | | entropy and concentration | operations under their own definitions | treating entropy and HHI as interchangeable or equally directed |
Three progressive uses
Minimal readable health claim
State the discipline, intended use, one Characteristic, the ClaimScope, comparison or observation basis, time stance, and ordinary result. Name the support actually relied on. Stop when this answers the working question. Do not require an EvidenceGraph, UTS row, registry, dashboard, definition set, series, or publication occurrence.
Measurement, comparison, or aggregation
Open C.16 when an actual measurement is claimed. Make the DHC replay basis recoverable, identify measurement Work and result separately, and apply A.18 legality. For direct comparison use the same-semantics branch in section 4.2. For distinct local senses add the exact F.9 branch. Open G.0, A.19, normalization, distance, evidence-reliance, or assurance only when the operation or receiver actually consumes it.
Reusable series, dashboard, or publication
Create a DHCDefinitionSet only when a reusable selection of definitions is needed. Create a DHCSeries episteme only when the receiving use needs ordered coordinate-result refs across windows. Use G.12 for a dashboard representation and refresh wiring. When an audience must be able to obtain a selected edition, use E.24.PUB and keep the availability relation, form, carrier, and any publishing Work distinct. Public naming and registry behavior remain conditional on a named use.
Archetypal Grounding (five domains)
Computer vision: direct comparison without a Bridge
Two ReproducibilityRate results concern the same benchmark population and ClaimScope. Both cite the same Characteristic and ratio Scale editions, the same DHCMethodRef.edition, compatible model and calibration rules, and matching 24-month population windows. The team compares the two rates directly under that basis. The source reports have different publication editions, but no distinct F.17 local senses are being related, so no F.9 relation is invented.
Formal benchmark approval and actual benchmark adoption are reported separately as FormalRecognitionStatus and PracticeAdoptionRate.
Biomedicine: evidence resolution without ratio substitution
One claim reports EvidenceUnitResolution = claim under ClinicalClaimSegmentation-3. A separate result reports SupportAnchorsPerClaim = 2.4 anchors/claim for the declared corpus. Neither value is substituted for ClaimsPerArtifact. Replication is a separate ReproducibilityRate over independent cohorts and a 36-month window.
Software performance engineering: explicit cross-local use
The compared cells are OpenTelemetry:SLO/latency-objective@E4 and VendorB:SLO/service-level-target@E7. Relation F9-SPE-SLO-12 obtains from the OpenTelemetry cell to the VendorB cell for the admitted use “compare service-latency objective coverage in the 2026 survey.” Its loss note says the target cell permits a different rolling-window convention, so only rows with the aligned 30-day window enter the comparison. That directed relation is one counted member of the declared AlignmentDensity cell set; it does not make all tracing-ecosystem readings comparable.
Decision-making: entropy and concentration stay separate
TraditionShareEntropy uses normalized Shannon entropy with base and category set fixed. TraditionShareConcentration uses HHI over the same population and has the opposite dispersion direction. A view may show both. If a receiving comparison wants one orientation, it declares 1-HHI as a transformation and still does not equate that Scale with normalized entropy.
Evolutionary architecture: banded disruption
DisruptionBalance is computed over one declared corpus and method edition. The result is interpreted against an explicit target band and distance rule; a higher raw value is not automatically healthier. Architecture decision records and fitness tests remain inputs or neighboring objects, not evidence that the field itself is healthy.
Authoring Rhythm
- State the ordinary health question and smallest useful conclusion.
- Identify the discipline under C.20 and one exact Characteristic and Scale.
- State ClaimScope, comparison or observation basis, and time or population basis.
- Stop if an ordinary typed claim is enough.
- If measuring, comparing, or aggregating, recover the C.16 chain and DHC replay basis; add only the exact legal-operation and crossing branches used.
- If repeated windows matter, construct a series episteme from exact result refs.
- If a dashboard matters, represent those results under G.12.
- If audience availability matters, establish E.24.PUB publication separately.
Bias-Annotation
C.21 counters dashboard, standard-status, popularity, and pseudo-precision bias. A public standard can have little adoption; a widespread practice can lack formal recognition; a dense relation map can preserve important losses; and a polished dashboard can represent weak or stale claims. The progressive path keeps the remedy proportional.
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
- Treating discipline health as one scalar before separately typed coordinates exist.
- Treating
ClaimScopeandTargetSliceas two spellings for one object. - Requiring a Bridge merely because sources, schemes, or editions differ.
- Comparing distinct local senses without the exact obtaining F.9 relation and loss.
- Ordering formal status and adoption on one universal maturity ladder.
- Calling
claims/artifactandanchors/claimalternative Units of one Characteristic. - Writing
<entropy/HHI>as if either formula produced the same reading. - Treating a definition set, method description, Work record, series, dashboard row, or publication carrier as the measurement result.
- Requiring publication and assurance machinery before one useful health claim exists.
Consequences
Benefits. Field-health claims remain readable, scale-admissible, comparable when justified, and reusable without turning a dashboard or standard into authority.
Costs. A numerical or reused claim must expose its definition and comparison basis. A cross-local comparison must additionally expose the exact relation and loss.
Risks avoided. False maturity ladders, hidden polarity reversal, scope substitution, Bridge inflation, stale trends, publication-as-result, and assurance-by-record are blocked.
Rationale
Discipline health is not one thing. Reproducibility, formal recognition, adoption, alignment, disruption, evidence resolution, and diversity answer different questions and can move independently. Their definitions, measurement results, series, representations, and publications also change for different reasons. Keeping those distinctions explicit makes the result both more precise and easier to use.
SoTA-Echoing
Relations
- Builds on: C.20 for the discipline, A.17-A.18 for Characteristic and Scale, C.16 for measurement and direct comparability, A.2.6 for ClaimScope and optional selected slices, and C.2.1 for result and series epistemes.
- Coordinates with: F.9 for actual cross-local sense relations; G.0 and A.19 for numerical operation, comparison, or aggregation; G.4 for target bands and acceptance; G.9 for parity; G.11 for currentness and refresh; G.12 for dashboard representations; A.10/G.6 and B.3 only for named evidence-reliance or assurance uses; E.24.PUB for publication availability.
- Constrains: G.5 and G.10 when they consume a DHC coordinate: they carry the same active DHC replay basis rather than a generic method-spec or metric-edition pin.
Practitioner Quick Template
C.21:End
Task Typing and TaskSignature Assignment (Problem-CHR)
Status: Stable Type: Calculus (C)
Purpose. Give FPF an admissible, minimal, and portable TaskSignature declaration for selector-facing use after the problem-side episteme is stable enough for Principles-to-Work, eligibility, acceptance, or policy-governed choice. C.22.2 carries the first problem-framing episteme for a messy signal. C.22 constitutes one CHR-grounded U.Signature and, when a receiving use is current, relates the exact problem-side episteme to that signature through TaskSignatureAssignmentRelation. Typed characteristics and unknowns stay visible. The declaration includes scope and only those basis, currentness, evidence-use, or crossing relations on which the receiving use relies; none adds a generic setting, carrier, or organization as a participant.
Body-level kind boundary. TaskSignature is a C.2.1 episteme and a species of existing U.Signature, conformant to A.6.0 direct declaration fields, Vocabulary, Laws, and Applicability. It is not a record format and introduces no new root U-kind. TaskSignatureAssignmentRelation is a separate obtaining relation among one exact problem-side episteme, one exact TaskSignature episteme, and one exact use episteme. ProblemCard is the C.22.2 problem-side episteme used before that assignment. KindSet contains C.3 U.Kind values for selected entities. Descriptor maps, telemetry hooks, policy ids, and selector fields remain signature vocabulary or projections unless an exact admission predicate and current subject assertion establish another kind.
Primary EntityOfConcern. This pattern defines or constrains one TaskSignature episteme. Inside it, EntityOfConcernRef identifies the exact task or work target declared for the receiving use; it does not identify the signature, TaskKind, carrier, organization, or publication. TaskKind, optional TaskFamilyRef, KindSet, characteristic bindings, and scope relations are declaration content. A later SelectorOutcome remains a downstream result.
Placement. Part C (Kernel Extensions Specifications) -> Cluster C.I (Core CHRs and CALs). Depends on: C.16 MM-CHR (measurement admissibility), G.5 (selector S2 and S3), G.0 (CG-Spec invariants). Coordinates with: G.4 (Acceptance and Evidence profiles), C.23 (MethodFamily admissibility and maturity), C.18 NQD-CAL (QD and illumination), C.19 E/E-LOG (emitters and policies), E.10 (LEX).
Use This When
Use this pattern when one stabilized problem-side episteme must be related to a selector-facing TaskSignature for eligibility, acceptance, or policy-governed selection. Typical cases include solver choice, method-family eligibility, QD archive selection, open-ended generator selection, or specialization claims that need a declared task family or work target.
The working moment often sounds like this: "We are about to compare possible ways of doing, but which facts about this problem make a method family eligible, comparable, or unacceptable for this use?" Construct the smallest A.6.0 TaskSignature that a later selector can consume without selecting a method in advance, then assign it to the exact problem-side episteme and receiving use. If problem framing remains contested or stale, use C.22.2. If a sufficient signature and assignment already exist and the current question is selection, use G.5. If a method is selected and dated enactment is being prepared, use A.15.2.
What goes wrong if missed. A problem remains a paragraph: selector inputs drift, ordinals and units get mixed, unknowns are coerced, acceptance thresholds leak into CHR fields, and reuse proceeds from a shared name, scheme, plane, or package instead of two exact local senses, a tested F.9 relation, and a separate claim about the proposed use.
What this buys. The downstream selection question gets one separately constituted TaskSignature with typed vocabulary, laws, applicability, unknown handling, and ClaimScope. Evidence, freshness, and cross-semantic relations are added only when that receiving use actually needs them. Its assignment is replayable while publication and serialization can vary without changing the signature.
Intent
Operationalise No-Free-Lunch discipline in selection by making each selector decision use a typed TaskSignature, not a paragraph. A problem reaches C.22 when its problem-side episteme is stable enough to constitute and assign that declaration without selecting a method in advance. The signature is the smallest CHR-typed A.6.0 declaration sufficient for eligibility, acceptance, and policy-governed selection without inadmissible arithmetic or silent coercions.
Term split used in this pattern
TaskSignatureassignment means one obtainingTaskSignatureAssignmentRelationamong an exact problem-side episteme, exact TaskSignature, and exact receiving-use episteme; it does not pre-bind a method.ScopeSlice(G)means the exact A.2.6U.ClaimScopevalue used by this declaration; it is not an evidence-path slice, baseline-set slice, container, or assignment participant.thresholdis not one undifferentiated family here:- articulation and closure thresholds stay with cue or prompt subject patterns such as
B.4.1andB.5.2.0; - acceptance-gate thresholds stay with
G.4; - a work-measure threshold target used in a specialization claim is only the declared success mark for that task family or work target.
- articulation and closure thresholds stay with cue or prompt subject patterns such as
Name and kind map for code-shaped heads. The names below identify different structural positions; capitalization does not make them peer kinds.
ProblemCard relation
ProblemCard is the C.22.2 C.2.1 episteme used to stabilize one problem-side representation before downstream Principles-to-Work.
A ProblemCard can prepare TaskKind, scope, and characteristic bindings for a candidate TaskSignature. Assignment obtains only when one signature is adequate for the named receiving use. If several signatures remain plausible, keep them as candidates under the selection or problem-framing pattern rather than asserting one assignment occurrence.
TaskSignatureAssignmentRelation moves no card claim into the TaskSignature. The signature keeps only its A.6.0 declaration content; the card remains the reviewable problem-side episteme that explains why this problem can proceed to characterization, comparison, search, refresh, retirement, or another subject pattern.
The corresponding claims remain with their named subject patterns.
Problem Frame
Selector-facing problem case
For selector-facing C.22 use, a problem case applies when the problem-side episteme is stable enough to construct a minimal TaskSignature and assert its TaskSignatureAssignmentRelation for eligibility, acceptance, or policy-governed selection. Method absence or contestability is a common downstream reason, but not the ontology of problemhood. When the live question remains a symptom, contested framing, stale ReferenceScheme or ClaimScope, set-derived candidate, opportunity cue, or preselected work item, use C.22.2 before asserting one assignment. When selection becomes current, cite the A.19.SelectorMechanism relation and exact G.5 policy refs rather than moving selection policy into the signature.
Unknown-first discipline. Author S2 with unknown traits rather than coercions. Name the exact downstream policy that interprets a live unknown for the receiving use. C.22 introduces no universal outcome enum; C.23, G.4, G.5, or another direct pattern defines or constrains the resulting eligibility, acceptance, or selection disposition.
Untyped "problems" collapse into informal prose; selectors cannot filter or abstain admissibly; acceptance-gate thresholds leak into scoring; and cross-scheme reuse proceeds by name rather than by an exact relation. The ordinary needed value is a use-bounded TaskSignature that (i) establishes MM-CHR admissibility for Scale, Unit, and Polarity before aggregation, (ii) carries tri-state unknowns explicitly, and (iii) states the exact scheme, scope, and only the basis and currentness relations needed by the current use. Open A.10 only when the use relies on a bounded evidence or provenance question. Open B.3 only when an assurance claim or material-reliance threshold is current; its assurance result is not a TaskSignature field.
Problem
Without typed descriptors, Eligibility and Acceptance degenerate into prose and inadmissible operations creep in, such as ordinal means or mixed units. Without the F.9 split, a cross-scheme comparison can also equate unlike local meanings or import an assurance penalty even though no current assurance policy selected it.
Forces
Solution — Problem CHR, TaskSignature, and assignment relation
Local TaskSignature mantra. Stabilize the problem; name the receiving selection question and task kind; keep only traits that can change eligibility, acceptance, or selection; type each live trait; preserve unknowns, scope, and any basis or currentness relation the use relies on; declare the TaskSignature, assign it to the problem-side episteme for that use, and stop before selecting a method. This is a short repeatable rendering of the C.22 Solution. It is not a selector algorithm, method recommendation, work plan, dated selection occurrence, or DemonstrativeUnfoldingSlice@Context.
Apply that formula as follows:
- Confirm that the problem-side representation is stable enough for selector-facing use; otherwise use
C.22.2. - Name the receiving eligibility, acceptance, or selection question and the
TaskKind, optional task family, or work target that the signature will declare. - Include only the problem traits whose values can change that receiving use. Leave a non-current optional extension absent.
- Type each live characteristic by scale, unit, polarity, reference plane, and admitted comparison relation before aggregation or comparison.
- Preserve a live but unknown value as
unknown; include or reference the exact scope, evidence relation, freshness or edition condition on which later use relies. When cross-semantic reuse is current, resolve the two local senses and test the F.9 Bridge separately; a shared label, scheme, or plane does not establish it. - Close with one minimal
TaskSignature. Pass later eligibility and acceptance claims toC.23andG.4, and actual method-family selection toG.5; do not put their outcomes back into the signature as if they were problem traits.
Positive closure, bounded non-use, and local return
Close the C.22 use positively when the direct TaskSignature fields, Vocabulary, Laws, and Applicability are complete and TaskSignatureAssignmentRelation recovers the exact problem-side episteme, TaskSignature, receiving-use episteme, effective ReferenceScheme, ClaimScope, and current qualification conditions. Each live characteristic has its scale, unit, polarity, reference plane, admitted comparison relation, and value or explicit unknown; every relied-on evidence, freshness, or edition relation is named. When cross-semantic reuse is current, its exact local senses, obtaining F.9 Bridge, and separate bounded-use claim are recoverable. A downstream selector can now consume the assigned signature without guessing, but no eligibility verdict, acceptance result, method recommendation, selector outcome, WorkPlan, or dated Work is claimed.
Close by bounded non-use when problem framing is not stable enough for a TaskSignature declaration, when no selector-facing receiving use is current, or when the current question has already become eligibility, acceptance, selection, planning, or performed work. A non-current optional extension remains absent. If several signatures or assignment relations remain plausible, preserve them as candidates under the governing problem or selection pattern rather than asserting one assignment.
Return to the smallest affected TaskSignature position when its receiving question, exact target, effective ReferenceScheme, ClaimScope, TaskKind, task-family reference, characteristic meaning, scale, unit, polarity, reference plane, unknown status, evidence-use relation, freshness condition, or edition changes. Recheck the F.9 endpoint senses, Bridge predicate, bounded-use claim, or reliance result only when that exact dependency changed. Keep the upstream ProblemCard and downstream selection history unchanged unless that exact change invalidates them under their own subject patterns.
Worked local repair. A machining TaskSignature originally records surface finish as an ordinal visual grade. The named use later adopts measured roughness Ra on a ratio scale in micrometres with a named measurement and evidence relation. Repair the affected characteristic head, scale, unit, admitted comparisons, and evidence relation. Keep the machining TaskKind, unaffected constraints, scope, and prior Work history. Reopen eligibility, acceptance, or Method-family selection only when its earlier result relied on the replaced finish head; state the new result under the exact downstream predicate with its subject-pattern locator.
Apparatus proportionality
Use the lightest signature declaration and assignment relation that the named receiving use can consume:
- Minimal selector-facing use. Materialize one TaskSignature with only the live fields needed by the current eligibility, acceptance, or selection question. This is the ordinary positive result of C.22.
- Reliance-bearing use. Add an addressable
ProblemProfileepisteme only when delayed feedback, audit, transfer, automation, expensive reversal, or another named use relies on replay beyond the local assignment relation. Pin the exact problem-side episteme and edition, TaskSignature edition, receiving use, every relied-on field-basis relation with its subject pattern, qualification window, review trigger, and any current evidence or currentness relation. When this use crosses local meanings, test F.9. Add an actual Bridge and separate bounded-use claim only if its predicate is true; otherwise keep the local values separate and stop that reuse. - Extension-bearing use. Add QD, OEE, archive, generator, parity, or specialization positions only when that exact downstream relation is current and its direct pattern requires those values.
More fields, publication packaging, name cards, or telemetry do not make the problem better formulated, the TaskSignature more true, or a method more suitable. If no selector-facing receiving use needs a TaskSignature, close by bounded non-use rather than publishing a thin declaration for its own sake.
Minimal CHR fields (tri‑state aware).
Selector-side field boundary. The fields below are live only after problem framing has been stabilized enough to ask eligibility, acceptance, selection, Method-family, or policy-constrained choice questions. They are not a universal problem-framing checklist and do not replace the C.22.2 Thin ProblemCard pass for a messy signal. Each live characteristic field is CHR-typed by Characteristic, Scale, Unit, and Polarity under MM-CHR discipline. A live predicate may preserve unknown only when its exact value rule permits it; the cited downstream policy states what follows. This aligns G.4 and G.6 without making their results C.22 values.
Optional extension absence rule. If QD, OEE, archive, generator, parity, specialization, or another optional relation is not live for the current case, the corresponding optional fields are absent, not unknown. Use unknown only for a live field whose value is currently unknown. An absent non-live extension triggers no downstream disposition.
DataShape— data regime and admissible transforms (e.g., tabular, sequence, graph; density; stationarity claims).NoiseModel— uncertainty class and robustness envelope (e.g., iid Gaussian; heavy‑tailed; adversarial budget).ObjectiveProfile— objective heads (Scale, Unit, Polarity and ReferencePlane declared), polarity, and admissible order relations (lexicographic, Pareto, medoid or median where admissible). Weighted sums across mixed scale types are inadmissible; ordinal heads use order-only guards. For QD tasks, explicitly enumerate quality heads, diversity or descriptor-space heads, and any policy-authorized QD contribution heads; see DominanceRegime below. Do not introduce a default QD score. If a scalar or set-scalarization policy is live, cite the governing CAL policy and keep the uses of dominance and telemetry explicit.RegularityTraits— method-relevant structure (convexity, differentiability, separability, monotonicity) as CHR-typed predicates with guard macros (for example,ORD_COMPARE_ONLY,UNIT_CHECK,POLARITY_CHECK). IncludeConditionClasssuch as stiffness or kappa proxies where applicable.Constraints— explicit hard and soft constraint classes (feasibility predicates; ResourceEnvelope and RiskEnvelope). Acceptance-gate thresholds live inG.4only; never inside CHR or code paths.ShiftClassand stationarity — CHR‑typed claims about regime stability (iid | covariate‑shift | concept‑drift | adversarial). Default=unknown. The cited acceptance or selector policy governs the consequence of that unknown for its receiving use.- Evidence and assurance (conditional). Include an exact A.10 evidence-use or provenance relation only when the receiving use relies on it. State source edition, currentness, or freshness only to the degree that reliance requires. Open B.3 only for a named assurance claim or material-reliance threshold, and use only the assurance lanes and fold that its declared policy requires. A TaskSignature by itself requires neither all TA/VA/LA lanes nor a Gamma-fold.
ScopeSlice(G)— the A.2.6U.ClaimScopevalue that bounds this declaration's claims aboutEntityOfConcernRef(discipline governance in CG‑Spec; Domain is a catalog mark only).SizeAndConditionProfile— size and condition proxies (n, m, kappa, sparsity) with declared units; a unit mismatch makes the current comparison unsupported until the direct acceptance or selector policy supplies its governed result.Freshness(conditional) — the validity window for a descriptor only when the receiving use relies on its currentness.Missingness— MCAR, MAR, or MNAR (or mapped equivalents) per CHR.Missingness; Acceptance and flow use preserve the declared missingness semantics.KindSet— selected C.3U.Kindvalues for the entities addressed by the TaskKind; separates EntityOfConcern kind from Scope (USM).
QD and Illumination extensions (normative; ties to C.18 and C.19).
Use this extension block only when QD, illumination archive, set-return, or OEE generator relation is live for the current case. It is not part of every TaskSignature.
CharacteristicSpaceRef— reference toU.CharacteristicSpace, with declared d≥2; characteristics are CHR‑typed; ReferencePlane per characteristic; pin edition viaCharacteristicSpaceRef.edition.ArchiveConfig— archive topology (grid, CVT, or graph), resolution (bins or centroids), K‑capacity,InsertionPolicyRef(elite replacement, dedup, or novelty), andDistanceDefRef.edition(declare metric or pseudometric status and invariances; normalisation is admissible only when the applied scale transform is admitted by CG-Spec); admissibility follows CG‑Spec.EmitterPolicyRef— reference to the emitter policy governed by C.19 and applicable to this TaskSignature; edition id recorded.DominanceRegime—{ParetoOnly | ParetoPlusIllumination}. Default =ParetoOnly(illumination remains report‑only telemetry unless CAL explicitly authorisesParetoPlusIllumination, policy‑id cited).IlluminationSummary— a telemetry summary overDiversity_P; reported by default; excluded from dominance unless a CAL enablesParetoPlusIllumination(policy‑id cited).IlluminationMap(parity-run) — parity-run publication is complete when an IlluminationMap publication (grid, CVT, or graph perArchiveConfig) records coverage per niche or cell withDescriptorMapRefandDistanceDefRef.edition. A single-score leaderboard does not satisfy this comparison use; compare under the declared CG-frame.PortfolioMode—{Pareto | Archive}. Default =Archive: selectors preserve archive evidence (QD archives) rather than a single “best” set; ε‑fronts remain admissible for local decisions under CG‑Spec.Budgeting— evaluation, time, and batch budgets, including E/E‑LOG exploration budget id; units declared (CG‑Spec).TelemetryHooks—PathSliceIdonly when an E.18 path-slice reference is current, plus decay and refresh policy ids, edition counters, descriptor-map updates, and policy-id updates upon illumination gains.GeneratorIntent(OEE) — optional intent to use a registeredGeneratorFamily(G.5), with pointers toEnvironmentValidityRegion,TransferRulesRef, and coverage and regret reporting expectations.
Admissibility. Before any numeric comparison or aggregation, establish CSLC admissibility for Scale, Unit, and Polarity and cite CG-Spec.Characteristics; record ReferencePlane. Preserve unknown for the downstream policy; do not coerce it to 0 or false, and do not invent a C.22-local disposition.
TaskSignature declaration and assignment
TaskSignature is a C.2.1 episteme and a species of A.6.0 U.Signature. It uses A.6.0 identity and declaration content directly rather than a flat record schema. Add an optional SignatureManifest only when dependency replay requires actual imports and provided names; SignatureId and edition are designators and currentness handles, not substitutes for identity.
The field families in C.22:5.1 are projections of Vocabulary and Applicability. They are not extra conceptual rows and do not redefine A.6.0.
The assignment is a separate relation with exactly three direct participants:
The relation obtains while the exact receiving use actually adopts that exact TaskSignature as the task-typing declaration for the exact problem-side episteme under the stated scheme, scope, and qualification conditions. Co-publication, a card field, a shared label, or one record row does not make it obtain. One occurrence is identified by the three participants plus its maximal continuous actual assignment extent. A participant change yields another occurrence; actual withdrawal and later readoption yield distinct occurrences even when the same three participants return.
TaskSignature identity and publication. The tuple <declaration content, EntityOfConcernRef, effectiveReferenceScheme> determines TaskSignature episteme identity under A.6.0 and C.2.1. SignatureId and edition designate and track that episteme. A semantic change to direct declaration fields, Vocabulary, Laws, Applicability, the exact target, or the effective scheme creates a revised signature edition. Two E.17 publications, database rows, cards, or files may present the same edition when they resolve to the same tuple and add no new claim. ProblemProfile may reference the signature and assignment relation but contains or becomes neither.
Minimality rule. Include only declaration positions needed to determine eligibility, acceptance, or admissible selection for the named use. Additional traits remain outside Vocabulary until a later use makes them current.
Values are CHR-typed and tied to the exact measurement, evidence-use, source-use, representation, or scope relation that justifies their use when such a relation is current. Each reliance-bearing field basis names that relation and its subject pattern; generic provenance or support wording is not a replay basis. Unknowns preserve their direct missingness semantics.
TaskSignature invariants. A positive assignment satisfies all six conditions:
- The TaskSignature exposes its exact
EntityOfConcernRef, effectiveU.ReferenceScheme, direct declaration fields, Vocabulary, Laws, and Applicability. - The assignment relation recovers its exact problem-side episteme, exact TaskSignature, exact receiving-use episteme, obtaining conditions, and occurrence extent.
- Every live field has an admitted filler kind or scale discipline and, under reliance, an exact basis relation with a subject pattern.
- A live but unrecovered value is
unknownonly where the field's exact value rule permits it and a downstream policy states how the named use handles it. - A non-current optional extension is absent; absence and unknown are not interchangeable.
- Eligibility verdicts, acceptance results, selected methods, selector outcomes, WorkPlans, and Work occurrences are absent from the TaskSignature and remain with their direct patterns.
Lowering and withdrawal conditions
Withdraw the assignment for the current receiving use when its problem-side episteme, TaskSignature, receiving-use episteme, scheme, scope, or qualification conditions cannot be recovered. The TaskSignature may remain a valid declaration for another assignment. Use C.22.2 only when the problem-side representation itself is no longer stable enough.
Revise the TaskSignature edition when a direct declaration field, Vocabulary, Law, Applicability claim, EntityOfConcernRef, or effective U.ReferenceScheme changes. Lower or remove one vocabulary position when its filler kind, scale, unit, polarity, reference plane, direct basis relation, or subject pattern cannot support the claimed use. Preserve unknown only when the position remains live and admitted. Split any selected method, selector outcome, acceptance result, plan, or Work occurrence into its subject pattern.
A changed or invalid signature position reopens an earlier downstream result only when that result relied on the changed position. The downstream pattern repairs or supersedes its own result. A revised signature does not imply that the actual Problem disappeared or that prior Work did not occur.
Evolution and currentness boundaries
C.22 revises the smallest affected identity or declaration-content component and issues a new TaskSignature edition when semantic content changes. A changed problem formulation requires C.22.2 before a replacement assignment is made. G.11 governs relied-on source edition, freshness, decay, telemetry, and currentness relations; its result may trigger signature review but does not rewrite the signature by itself. C.18 and C.19 govern archive, front, lineage, and live-pool evolution. G.5 governs selected-set and method-family selector results. E.23 governs repeated object-version improvement. C.22 introduces no local refresh object and does not rewrite earlier selector results or dated Work without an explicit dependency.
TaskKind fills SubjectKind. TaskFamilyRef? names one comparison-relevant family in Vocabulary when specialization, transfer, or parity is live. KindSet and A.2.6 scope slices determine the ranged extent. None is a record-format field, selected method, or selector result.
DesignRunTag hygiene. Do not mix DesignRunTag positions in one signature edition. If design-side information is reused in run-time Work, identify the actual receiving Work and its relations independently. Cite an E.18 structural GateCrossing only when a selected transformation-flow use contains that occurrence; it does not require a package and does not establish an F.9 Bridge.
Specialization-claim reference discipline (normative)
A claim that one holder, dyad, team, or explicitly scoped specialist portfolio acquired usable specialization is complete only when it states one declared TaskFamilyRef or TaskSignature, one named work-measure threshold target, an adaptation budget, and the freshness or provenance basis for reuse. A method may be selected, refined, or retired as part of that story, but it is not the subject of the specialization claim. The TaskSignature declaration and assignment remain rich enough for the same task family and work target to stay admissible in C.22.1 adaptation signatures, G.5 specialization profiles, and G.9 adaptation parity without reconstructing the claim from narrative prose.
Low-human-overlap or newly discovered task families remain admissible when those task-family or signature references are explicit by value.
Provenance, schemes, and planes
Record the effective U.ReferenceScheme, U.ClaimScope, and any ReferencePlane needed to interpret a relied-on value. A difference in scheme or plane opens a comparison question; it does not by itself establish a Bridge, forbid use, or impose a penalty.
For cross-semantic reuse, recover the two exact F.17 local senses and test the direct F.9 predicate. Cite a Bridge only when that predicate is true. Then state the proposed use separately: the action, direction, correspondence rule, tolerated loss, and polarity. If no Bridge obtains, keep the local values separate and return the missing comparison or translation question instead of manufacturing correspondence.
Open A.10 only when evidence or provenance for that bounded use is current. Open B.3 only for a named assurance use or material-reliance threshold; only that B.3 result may use edge-scoped CL and the policy it actually declares. An optional local F.9 CL note is evidence shorthand, not a use threshold or automatic penalty. A card, gate check, reusable package, or other publication is required only when its own receiving pattern independently needs it. The assignment receives no generic setting participant, and a domain, organization, location label, or shared carrier supplies none of these relations.
Attachment & use.
The bullets below state which TaskSignature fields and relations each downstream use reads. C.22 does not execute eligibility, acceptance, selection, archive treatment, or generator-family choice. Their verdicts and returned sets remain results of the named direct patterns.
- Eligibility gates read TaskSignature against each MethodFamily.Eligibility (C.23) and CG‑Spec.MinimalEvidence for referenced characteristics.
- Acceptance clauses (G.4) use these fields for acceptance-gate threshold predicates (acceptance-gate thresholds live in Acceptance only).
- Selection kernel (G.5.S3) applies an admissible order (often partial); weighted sums across mixed scale types are inadmissible. If only a partial order remains, return a Pareto (non‑dominated) set with tie notes. If
PortfolioMode=Archive, the selector may return a QD archive (perArchiveConfig) in addition to or instead of a Pareto set. Illumination enters dominance only ifDominanceRegime=ParetoPlusIlluminationis enabled by CAL (policy id cited); otherwise, QD telemetry values are reported but excluded from dominance. - When
GeneratorIntentis present, G.5-governed selection may use a registeredGeneratorFamily(POET‑class); the selection domain becomes pairs{environment, method}, with Environment guarded byEnvironmentValidityRegionandTransferRulesRef(C.23 wiring). ReportIlluminationSummaryas a telemetry summary overDiversity_P(report‑only by default) in telemetry; dominance remains unaffected unless policy changes as above.
Unknowns.
An identity position needed for positive closure cannot be replaced by unknown. A live characteristic or predicate may preserve unknown only when its exact value rule permits it. The TaskSignature cites the downstream policy that defines or constrains the consequence; C.22 performs no implicit coercion and declares no universal outcome set.
Publication.
When a named receiving use needs an addressable publication episteme, output a C.2.1-conformant ProblemProfile that carries the bound TaskSignature and only the evidence, currentness, F.9 bounded-use, and representation relations on which that use relies. Apply F.18 and F.17 Name Cards when a durable new name is actually being admitted; do not create a card merely because a local field or Bridge is present. Keep vendor or tool examples in Plain explanatory use rather than letting them become normative selector inputs. When no publication reliance is current, the TaskSignature closes without a separate ProblemProfile.
Open‑Ended tasks (GeneratorFamily) (normative).
When open-ended generation of tasks or environments is current, S2 is complete only when it includes GeneratorIntent with pointers to EnvironmentValidityRegion (admissible region for generated environments), TransferRulesRef (cross‑environment transfer constraints), and coverage and regret telemetry expectations. Selector outputs are then declared sets over {environment, method}; coverage and regret are reported telemetry values and IlluminationSummary is a telemetry summary (reported), excluded from dominance unless a CAL policy promotes them (policy‑id recorded in SCR; see DominanceRegime). Edition increments of CharacteristicSpaceRef.edition, DescriptorMapRef.edition, DistanceDefRef.edition, and (OEE) TransferRulesRef.edition, and the policy id associated with an illumination increase form part of the SCR change record.
Archetypal Grounding (Tell–Show–Show)
Tell–Show–Show hook (per E.8): label examples as Show‑1 (continuous ODE) and Show‑2 (MIP) and cite CHR guard‑macros in‑line so engineers can see which field supplied which Eligibility or Acceptance input. Explicitly annotate which S2 fields triggered each Eligibility and Acceptance decision (e.g., service_level@ordinal → ORD_COMPARE_ONLY, budget@ratio → unit alignment check).
A. Differential equations (continuous systems, solver choice).
ProblemProfile. DataShape=ODE, stiff?=unknown, SizeAndConditionProfile={n≈10^3}, ObjectiveProfile={↓error@ratio, ↑throughput@ratio}, ConstraintRefs={budget-envelope relation, safety-predicate relation}, RegularityTraits={Lipschitz known?=unknown, Jacobian sparsity=high}, Missingness=MAR.
Attachment. Selector consumes TaskSignature; eligibility filters MethodFamilies whose acceptance conditions include known stiffness or differentiability, with unknown yielding degrade or abstain per family. Acceptance treats safety_gate as an ordinal predicate, not an average (ORD_COMPARE_ONLY), and treats budgets with unit-aligned sums on ratio scales. The selector returns a Pareto set; no cross-ordinal weighting.
B. Mixed‑integer optimisation (planning and scheduling).
ProblemProfile. DataShape=MIP, NoiseModel=deterministic, ObjectiveProfile={↓cost@ratio, ↑service_level@ordinal}, Constraints={SLA hard, workforce soft}, RegularityTraits={convex_relaxation=available}, SizeAndConditionProfile={vars~10^5}, Missingness=MCAR.
Attachment. CG‑Spec forbids means over service_level (ordinal); Acceptance holds acceptance-gate thresholds; Eligibility checks convex-relaxation availability; Selection applies the lexicographic guard (assumption-fit before evidence-fit before resource). If a named assurance use or material-reliance threshold is current, B.3 computes its separate assurance result from the relied-on evidence relations and the declared policy; otherwise this example adds no assurance fold. If the admissible comparison remains partial, return a Pareto set.
Current practice anchor: the 2026 SciML Problem Interface constructs an immutable problem value before solver use and supports explicit
remakewhen problem fields change. C.22 adapts only that problem-before-selector separation; it does not import Julia types as FPF ontology.
C. Quality-Diversity archive and declared set (illumination).
ProblemProfile. DataShape=policy‑search; ObjectiveProfile={↑reward@ratio, ↑coverage@ratio (report‑only)}, DominanceRegime=ParetoOnly, PortfolioMode=Archive, CharacteristicSpaceRef(d=3, characteristics=CHR‑typed), ArchiveConfig(grid, res=32×32×16, K=1, InsertionPolicyRef=elite‑replace, DistanceDefRef.edition=v1), EmitterPolicyRef=v2, Budgeting{eval=1e6}, TelemetryHooks{PathSliceId=…}.
Selection result. Selector may return an archive; coverage and illumination are reported but excluded from dominance (default). Any change of DistanceDefRef.edition or Emitter policy is editioned and logged in SCR.
D. Open‑ended environment generation (POET‑class).
ProblemProfile. GeneratorIntent{GeneratorFamilyRef=…, EnvironmentValidityRegion=… (CHR‑typed), TransferRulesRef=…, CoverageMetric=…}, PortfolioMode=Archive.
Selection result. Selector outputs {environment, method} pairs that pass Eligibility; TransferRules govern cross‑environment policy reuse; telemetry reports coverage and regret and IlluminationSummary with edition and policy‑id when improved.
E. Physical manufacturing method-family eligibility.
Problem-side episteme. PartFamilyFinishingProblemCard-E2 : U.Episteme is the exact C.22.2 ProblemCard for a shop that must finish AlloyPartFamily-17 on one machine under ShopInspectionScheme-E4 and a production-window ClaimScope. The receiving question is which available finishing-method families can be compared without presuming one of them.
TaskSignature. SurfaceFinishingEligibilitySignature-E1 declares EntityOfConcernRef=AlloyPartFamilyFinishingTarget-17, effectiveReferenceScheme=ShopFinishing-Scheme-A, TaskKind=surface-finishing work, ScopeSlice(G)=AlloyPartFamily-17 during [2026-09-01T00:00Z, 2026-10-01T00:00Z), ObjectiveProfile={surface roughness Ra@ratio in micrometres with downward polarity, throughput@ratio}, ConstraintRefs={geometric-tolerance relation, heat-distortion relation, resource-envelope relation}, and material-hardness condition as a live unknown with an explicit measurement relation and unknown-handling policy. The TaskSignature makes eligibility reviewable; it does not select grinding, honing, polishing, or another method and does not establish that any part was finished.
Assignment. FinishingMethodEligibilityUse-E1 : U.Episteme states the exact receiving eligibility-comparison use. TaskSignatureAssignmentRelation(PartFamilyFinishingProblemCard-E2, SurfaceFinishingEligibilitySignature-E1, FinishingMethodEligibilityUse-E1) has exactly the problem-side episteme, signature, and receiving-use episteme as participants. It obtains only while that receiving use actually adopts that exact signature as the task-typing declaration for that exact card under ShopFinishing-Scheme-A, the declared part-family scope, ShopInspectionScheme-E4, and the production window above. Withdrawal of that adoption or change of a participant or qualification ends this assignment occurrence; a shared row, carrier, or publication does not make it obtain.
F. Clinical rehabilitation method-family eligibility.
Problem-side episteme. CohortRehabilitationProblemCard-E3 : U.Episteme is the exact C.22.2 ProblemCard for a rehabilitation service with Cohort-2026-Q3 and a stated capability-change question under clinical safety constraints.
TaskSignature. RehabilitationFamilyComparisonSignature-E1 declares EntityOfConcernRef=RehabilitationCapabilityChangeTarget-4, effectiveReferenceScheme=ClinicalRehabilitation-Scheme-C, TaskKind=rehabilitation-method-family comparison, and ScopeSlice(G)=Cohort-2026-Q3 in the declared care setting during [2026-08-01T00:00Z, 2026-11-01T00:00Z). It also declares outcome characteristics with their scale kinds, contraindication and resource constraints, and unknown tolerance or comorbidity values preserved as unknown. Include the evidence relations and follow-up windows only because this comparison use relies on them.
C.22 makes the comparison inputs explicit. It does not diagnose a person or recommend treatment; those claims use their clinical patterns. It does not establish evidence or benefit, pass a gate, grant permission to provide care, or establish decision authority. Use the evidence and evaluation patterns, the gate patterns, an obtaining GrantedPermissionRelation@Context, or an authority predicate, or return missing-governor.
If clinical Work occurs, recover each exact actual performer System through A.13 and let A.15.1 independently admit the dated Work and its enacted Method. Add an assignment occurrence, its declared species, and F.6 only when this clinical account or its receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; F.6 identifies neither assignment nor performer, and missing or failed F.6 leaves the Work intact. A local system-role kind, classification, or assignment can remain a neighboring fact, but it establishes none of the permission or authority relations above.
Assignment. RehabilitationInterventionFamilyComparisonUse-E1 : U.Episteme states the exact receiving comparison use. TaskSignatureAssignmentRelation(CohortRehabilitationProblemCard-E3, RehabilitationFamilyComparisonSignature-E1, RehabilitationInterventionFamilyComparisonUse-E1) has exactly the problem-side episteme, signature, and receiving-use episteme as participants. It obtains only while that receiving use actually adopts that exact signature for that exact card under ClinicalRehabilitation-Scheme-C, the declared cohort and care ClaimScope, the qualification window above, and the stated evidence-use conditions. Withdrawal of that adoption or loss of a participant or qualification ends this assignment occurrence; cohort labels, records, carriers, and organizations add no signature field or fourth participant.
Bias-Annotation (lexical and discipline guards)
- Selector and policy relation precision. When a source calls selection behavior a strategy, keep the Plain wording only for recognition. The governed claim cites the A.19.SelectorMechanism relation and the exact G.5 criteria, policy ref, or
SelectorOutcome; no durableStrategyU-kind is introduced. - Transdiscipline vs domain. Comparability uses the exact ReferenceScheme, ClaimScope, characteristic meanings, and
U.Disciplinerelation when current. A Domain label is only a catalog mark; it supplies no norm, Bridge, scope, or comparison rule. - Plain twins and head selection. Use Description and Spec morphology correctly (I, D, S; E.10.D2).
Conformance Checklist (normative)
-
Minimal A.6.0 declaration.
TaskSignatureexposes exactEntityOfConcernRef, effectiveU.ReferenceScheme,SubjectKind,RangedValueKind, optionalResultKind,SliceSet, andExtentRule, plus Vocabulary, Laws, and Applicability. AddSignatureManifestonly when dependency replay needs actual imports and provided names; it does not supply signature identity. -
Signature and assignment present. Every exported selector-facing case names one TaskSignature identity and edition plus one
TaskSignatureAssignmentRelationwhose exact problem-side episteme, TaskSignature, receiving-use episteme, obtaining conditions, and occurrence extent are recoverable. No setting, carrier, or organization is added as a fourth participant. Current characteristic bindings are CHR-typed; a live unknown preservesunknown, while a non-current optional vocabulary item remains absent. 1a. Publication and designators do not define identity. Two E.17 publications or serialized records that resolve to the same<declaration content, EntityOfConcernRef, effectiveReferenceScheme>identify the same TaskSignature episteme. Carrier, layout, serialization,SignatureId, or edition label alone does not create a new identity component. -
CHR admissibility proven. Any numeric comparison or aggregation cites CG-Spec by Characteristic id and proves CSLC admissibility; no mean on ordinals; no unit mixing.
-
Unknowns remain typed. A live unknown remains
unknown, cites the direct downstream policy, and is not coerced. The acceptance, eligibility, or selector pattern records its own governed result. -
Evidence and assurance are conditional. When the receiving use relies on evidence or provenance, cite the exact A.10 relation and only the source edition, currentness, and freshness conditions that reliance needs. When an assurance claim or material-reliance threshold is current, cite its separate B.3 result, applicable assurance lanes, and declared fold. Otherwise the TaskSignature needs neither an evidence dossier nor an assurance fold.
-
Cross-semantic use is separated. Declare
ReferencePlanefor a value or objective head when its interpretation or comparison needs it. A scheme or plane difference alone creates neither a Bridge nor a penalty. Resolve two exact F.17 local senses, test the F.9 predicate, and state any proposed use separately. -
Acceptance thresholds live in CAL. No acceptance-gate thresholds in CHR or code paths; only in G.4 AcceptanceClauses.
-
Selector-use support. The TaskSignature exposes the scales, units, polarities, and admitted order relations needed by
G.5; it carries no mixed-scale scalarization or local selector verdict.G.5governs any Pareto-set result when its admissible relation remains partial. -
Bridge and use claims remain distinct. For current cross-semantic reuse, cite the two exact local senses and an actual F.9 Bridge only when its predicate is true. State the action, direction, correspondence rule, tolerated loss, and polarity in a separate bounded-use claim; if the predicate is false, keep the local values separate.
-
Packaging is conditional. Create an F.9 card, terminology row, Name Card, or reusable package only when a named receiving pattern independently needs that artifact. Packaging describes an already tested relation and separate use claim; it establishes neither.
-
Structure and gates are conditional. Apply E.18 crossing checks only when a selected transformation-flow structure and exact
GateCrossingare current. Apply A.21 only when a named gate decision is current. Each pattern supplies its own result; neither a structure nor a gate makes F.9 obtain, and C.22 requires no crossing or gate package otherwise. -
QD fields (when QD is in scope). A
TaskSignaturewithPortfolioMode=Archiveor QD heads is complete only when it carries CHR-typed CharacteristicSpaceRef (d>=2), ArchiveConfig (topology, resolution, K,InsertionPolicyRef,DistanceDefRef.edition), and EmitterPolicyRef fields; every characteristic declares its ReferencePlane. -
DominanceRegime default.
DominanceRegimedefaults toParetoOnly. Illumination enters dominance only through a cited CAL.Acceptance policy enabling that relation; the SCR records the policy id. -
Telemetry. The telemetry record carries PathSliceId when an E.18 path slice is current, the applicable decay and refresh policy ids, and edition counters for CharacteristicSpaceRef, DistanceDefRef, and EmitterPolicyRef. An illumination increase is traceable to the policy id that admitted it.
-
GeneratorIntent (when OEE is in scope). A TaskSignature supports the claimed OEE generator-family use only when
GeneratorIntentcitesEnvironmentValidityRegionandTransferRulesRefwith ids resolvable in G.5 and C.23. Any downstream abstention is their result, not a C.22 output. -
Budgets. When
Budgetingis live, its evaluation, time, and batch values carry declared units and the applicable E/E-LOG exploration-budget id. -
Archive-comparison support. A TaskSignature supports the claimed archive comparison only when
DistanceDefRef.editionand the applied novelty measures are CSLC-admissible and editioned. The archive or selector pattern defines or constrains any downstream abstention or returned-set result. -
Planes. QD heads and characteristics declare a
ReferencePlanewhen their meaning or comparison depends on it. A plane difference alone creates neither correspondence nor an assurance adjustment. Use item 8 for a current cross-semantic claim and item 4 for any separately current B.3 assurance result. -
Unknown QD values. A live unknown QD field remains
unknown, cites the policy governing its downstream use, and is not coerced or mapped by C.22 itself. -
Specialization claims referenced. A declared specialization on this TaskSignature is complete when it names the task family and work target, work-measure threshold target, adaptation budget, freshness or provenance basis for reuse, and the exact TaskSignature edition and assignment relation needed for the same claim to remain admissible in
C.22.1,G.5, andG.9use.
Common Anti-Patterns and How to Avoid Them
Selector Fields And Evidence Relations
Inputs. ProblemProfile (...Description) and CG-Spec ids; an A.10 evidence-use or provenance relation only when the receiving use relies on it; D.CTX only when that separate context relation is current; CharacteristicSpaceRef, ArchiveConfig, and EmitterPolicyRef configurations only when QD is live; GeneratorIntent only when OEE is live.
Produces. One TaskSignature episteme, declared as the U.Signature species specified in C.22:5.2. When a receiving use is current, C.22 also produces one separate TaskSignatureAssignmentRelation among that signature, the exact problem-side episteme, and exact receiving-use episteme. TaskSignature is neither a new root U-kind nor a record kind: its A.6.0/C.2.1 identity tuple and declaration content determine its semantic edition, while publication, carrier, and serialization remain outside identity. Optional QD, archive, generator, PortfolioMode, and telemetry vocabulary appears only when current.
Used by. G.5 (Eligibility and Selection kernel), G.4 (Acceptance and Evidence), C.23 (admit, degrade, and abstain rules and method-family maturity checks).
Consequences (informative)
- Admissible selection. Selection is explainable and inspectable: every admission or rejection reason cites the TaskSignature positions and CHR rules on which it relied. When a separate B.3 assurance result is current, that result cites its own evidence relations, applicable assurance lanes, and declared fold.
- Use-bounded first, cross-semantic use explicit. The exact EntityOfConcern, effective ReferenceScheme, ClaimScope, and receiving use are primary. When local meanings differ, an obtaining F.9 Bridge and a separate bounded-use claim make the proposed reuse inspectable; evidence reliance, assurance, gates, and packaging remain optional neighboring questions.
- Frictionless downstream. G.1-G.5 use one single, typed TaskSignature; thresholds are cleanly separated into Acceptance; unknowns are not guessed.
- QD and OEE-ready. Typed QD and GeneratorIntent fields make declared returned-set structure and open-ended generation contexts explicit, with admissible dominance, editioned distances, and policy-aware illumination.
Rationale
Selecting a method before the relevant eligibility, acceptance, unknown-handling, and admissible-comparison relations are explicit invalidates the selector-facing problem record. When the selection use relies on evidence, provenance, currentness, or assurance, those separate relations and results must also be explicit; C.22 does not require them otherwise.
SoTA-Echoing
Wolpert and Macready's "No Free Lunch Theorems for Optimization", 1997, remains historical lineage for the warning that method superiority is distribution-dependent. It does not by itself supply the current C.22 field set, a selector policy, or evidence that one TaskSignature is adequate. The current sources below change the pattern by value.
Relations
Builds on: C.16 MM-CHR, G.0 CG-Spec. Coordinates with: G.4 Acceptance, G.5 Selector, C.18 NQD-CAL, C.19 E/E-LOG, C.23 Method-SoS-LOG, and C.32.P2S when typed problem pressure continues into architecture selected structures and synthesis. Constrained by: E.10 for selected EntityOfConcern, Description-episteme, specification-use, and publication-lane wording. Coordinate with E.18 only when a named receiving use depends on a selected transformation-flow crossing or gate position; E.18 supplies neither the F.9 Bridge nor a mandatory publication package.
Practical Use Checks
- If two candidate approaches are answering different
TaskKinds or differentScopeSlice(G)cuts, a direct comparison is not admissible yet. - If specialization is the live specialization question, the task-family reference, threshold target, adaptation budget, and provenance basis should already be recoverable from the assigned
TaskSignatureedition. - If crossing, normalization, or missingness changes what comparison means, state that in the signature and its cited refs rather than hiding it in code, local memory, or explanatory prose.
- If
QDorOEEheads are in scope, archive and generator fields belong in the same typed signature rather than in a detached explanatory appendix.
Goldilocks Hook (design-time)
When generating candidate solutions for a TaskKind, aim for “goldilocks” slots (feasible‑but‑hard) so that the TaskSignature is informative (neither trivial nor impossible); this aligns with G.1 (goldilocks target, abductive provenance) and ensures the TaskSignature is informative (neither trivial nor impossible) for G.5 selection.
C.22:End
Task-family adaptation signature
Status: Stable
One-screen purpose (manager-first).
Make a specialization claim publishable as one typed adaptation record over a declared TaskFamilyRef or TaskSignature, so later selector and parity work compares the same threshold target, budget burn, prior exposure, transfer, durability, downside, and corridor-entry field rather than reconstructing that story from narrative prose.
Builds on. C.22 (TaskSignature attachment and task-family anchoring), C.19.1 (BLP compatibility), A.15 (system-role kind and assignment, Method, WorkPlan, and Work-occurrence split for scout or probe Work), C.24 (CheckpointReturn planning semantics), E.16 (budget enforcement).
Coordinates with. G.5 (selector specialization profiles), G.9 (adaptation parity), G.11 (later telemetry and refresh reuse).
Keywords. adaptation signature; task-family specialization; time-to-threshold; budget-to-threshold; prior exposure; corridor entry; stepping stone; transfer; retention; downside field.
Problem frame
Final task score alone does not tell whether a holder, dyad, or bounded specialist portfolio acquired usable specialization quickly, under what budget, with what prior exposure, whether the resulting competence transferred, or whether it entered a genuinely new solution corridor. If those elements are not published together, the adaptation claim splinters across task typing, probe notes, selector prose, and parity notes, and later readers can no longer tell what exactly was being compared.
Problem
FPF needs one compact way to publish a bounded specialization claim on the same declared task family and work target without retyping the task anchor from C.22 or silently pushing the adaptation-signature question into selector/parity prose.
Use this when
- the live task-family adaptation claim is not only that a holder or dyad solved a task, but how fast it acquired usable specialization on a declared task family
- comparison must stay honest about the work-measure threshold target, prior exposure, adaptation budget, transfer field, and reuse window
- movement into a new solution corridor or stepping-stone family is part of the real novelty claim
What goes wrong if missed
- adaptation claims collapse into vague
got betterlanguage with no declared work-measure threshold target or budget-to-threshold account - parity later compares outcomes that were reached under different prior exposure, different work-measure threshold targets, or different reuse windows
- nonhuman or unfamiliar solution corridors are either romanticized as novelty or dismissed as noise because the corridor entry was never typed
What this buys
- adaptation speed becomes reviewable by value on the same declared
TaskFamilyand work target - later
G.5 / G.9portfolio and parity work can compare the same specialization object instead of reconstructing it from narrative prose - stepping-stone or solution-corridor movement becomes visible as one typed part of the adaptation claim rather than one afterthought
Forces
Solution — one adaptation signature over the C.22 anchor
- Use one shared adaptation-signature field set for this question.
G.5,G.9, and later notes may cite or consume it, but they should not silently rename threshold, prior-exposure, transfer, downside, or corridor-entry terms. - When specialization is the live adaptation question, publish one adaptation signature bound to the declared
TaskFamilyReforTaskSignature, not one generic improvement claim. - The signature should expose at least:
thresholdTargettimeToThresholdbudgetToThresholdpostThresholdEfficiency?priorExposureDeclarationtransferTarget?transferGain?retentionWindow?downsideEffect?corridorEntryBaseline?corridorEntryEvidence?steppingStoneEvidence?
- These fields stay anchored to the same work target and work-measure threshold semantics already declared by
C.22, so adaptation is typed as movement toward usable specialization rather than as an ungrounded growth story. C.22continues to carry the declared task-family anchor, task typing, and baselineTaskSignature.C.22.1narrows the adaptation-signature question to threshold timing, reuse, downside, and corridor-entry disclosure over that existing anchor.
Corridor, transfer, and durability discipline
- If the adaptation claim depends on entering a new solution corridor, publish the
corridorEntryBaselinefirst: the prior repertoire, baseline set, or comparison family relative to which corridor entry is being claimed. - Then publish the
corridorEntryEvidencethat marks real entry into that corridor rather than exotic accident, for example a reproducible solution class, a stable descriptor shift, or one explicit stepping-stone sequence. - If a stepping stone mattered, publish the stepping-stone evidence as part of the adaptation signature rather than treating it as retrospective color.
- Corridor or stepping-stone notes do not replace the work-measure threshold account; they explain why the adaptation path matters, not whether the threshold was actually reached.
- A fast threshold result is not yet enough to claim durable specialization.
- If transfer to a neighboring task family is claimed, name the transfer target and the observed gain explicitly.
- If retention is claimed, name the reuse or retention window rather than letting durability hide inside one isolated run.
- If specialization harms neighboring task families, narrows reusable competence, or creates de-specialization cost, publish that in
downsideEffect?rather than telling only the upside story. - If post-threshold performance matters to later exploitation, publish
postThresholdEfficiency?so the claim is not trapped at the threshold-crossing moment only.
Worked moment
- Two agentic research setups both eventually reach an acceptable threshold on a new catalyst-search task family.
- One of them reaches threshold after a small probe budget, shows a declared transfer gain on one adjacent task family, and records that the winning path entered a previously unused solution corridor.
- The other reaches threshold only after much larger budget and without any reusable transfer.
- The adaptation signature makes that difference publishable without pretending that both runs express the same specialization story.
Consequences
- Threshold speed, budget burn, prior exposure, and post-threshold efficiency become part of the same reviewable object instead of one after-the-fact prose explanation.
- Selector and parity pattern applications can consume a stable upstream specialization object without minting shadow vocabularies.
- Corridor-entry and downside fields stay visible in the same claim that celebrates the specialization gain, reducing romanticized novelty talk.
Rationale
The reader needs one place where the adaptation claim stays whole. C.22 keeps the task family and work target explicit. A.15, C.24, and E.16 may generate the probe, checkpoint, and budget evidence. G.5 and G.9 later compare several candidates or parity runs. C.22.1 keeps the specialization story readable across those neighbouring pattern applications by making threshold timing, reuse, downside, and corridor-entry field recoverable in one short read instead of forcing the reader to reconstruct it from scattered notes.
SoTA-Echoing
Claim 1. Current frontier adaptation work judges usable specialization by threshold-crossing under bounded resources, not by terminal score alone.
Practice source, local alignment, and adoption decision. Current QD and agentic-adaptation sources such as A survey on Quality-Diversity optimization: Approaches, applications, and challenges, Swarm and Evolutionary Computation 100:102240 (2026), FactorMiner arXiv:2602.14670v1 (2026-02-16), and SkillOpt arXiv:2605.23904v2 (2026-05-25) repeatedly separate threshold target, budget burn, transfer evidence, reuse evidence, and changed object/version from one final benchmark score. This pattern adopts that practical field set, adapts it through one TaskFamilyRef or TaskSignature-bound adaptation signature, and rejects generic got better narratives that leave threshold and budget semantics implicit.
Claim 2. Current open-ended exploration work treats corridor entry and stepping stones as evidence-bearing novelty signals rather than decorative commentary.
Practice source, local alignment, and adoption decision. Current QD/OEE source-use relation/currentness plus current FPF C.17, C.18, C.19, G.5, G.9, and G.11 neighbours distinguish real corridor entry from one exotic sample by asking for explicit baseline, stable descriptor shift, reproducible solution class, or an explicit stepping-stone trace. This pattern adopts explicit corridor baseline/evidence discipline, adapts it as declared adaptation-signature fields, and rejects novelty talk that names no baseline, evidence source, or evidence locus.
Claim 3. Current selector and parity practice needs one stable shared field set for specialization claims.
Practice source, local alignment, and adoption decision. Current FPF selector and parity neighbours keep compared candidates reviewable only when candidates reuse the same published field set for threshold, prior exposure, transfer, retention, downside, and corridor-entry field. This pattern adopts that reuse discipline, adapts it by publishing one stable adaptation-signature field set here, and rejects silent downstream field redefinition in G.5 or G.9.
Evidence-source note. Peer-reviewed or archived frontier anchors carry the most direct evidence for threshold, budget, and parity claims. Fast-moving frontier lines remain explicit evidence for corridor-entry and open-ended exploration pressure only when the row names their local contribution; they are not a flattened single evidence status.
Relations
C.27 temporal-claim relation.
-
C.27 may flag: a claim that a holder, dyad, team, specialist portfolio, method, or agent acquires usable specialization faster on one declared
TaskFamilyReforTaskSignature. -
This pattern keeps: threshold target, time-to-threshold, budget-to-threshold, prior exposure, transfer, retention, downside, corridor-entry evidence, and adaptation-signature fields.
-
Non-admissible use: generic "learns faster" wording without task-family anchors does not create a C.27 profile or a complete adaptation signature; faster threshold crossing is not durable specialization unless transfer, retention, downside, and corridor-entry evidence are stated when claimed.
-
Next-question boundary: downgrade to Dyn1 trend when only a trend is live; use the C.24 MethodDescription when the question is only tool-use planning; continue under the C.22.1 predicate when specialization is the live adaptation question.
Builds on: C.22 TaskSignature anchoring, C.19.1 BLP compatibility, A.15 system-role-kind and assignment, Method, WorkPlan, and Work-occurrence separation, C.24 scout or probe and CheckpointReturn semantics, E.16 budget enforcement.
Coordinates with: G.5 selector specialization profiles, G.9 adaptation parity, G.11 later telemetry/refresh reuse.
Coordinates with: E.23 when a quality-improvement loop claims durable task-family specialization. C.22.1 carries the adaptation-signature fields for threshold target, time-to-threshold, budget-to-threshold, prior exposure, transfer, retention, downside, and corridor entry; it does not restate the E.23 loop method, E.22 review framing, or pattern-quality or DRR-adequacy object-under-improvement evaluations.
Constrained by: E.10 lexical discipline and E.19 pattern-quality review when this child section is newly landed or materially revised.
Not this pattern when
- the claim only needs to name the task family and work-measure threshold target, with no adaptation-speed or transfer claim at all; ordinary
C.22anchoring is enough - the question under repair is already selector or parity law across candidate selected sets; that belongs to
G.5 / G.9 - the text cannot yet declare one work-measure threshold target, one prior-exposure stance, or one evidence source or evidence locus for corridor entry
Conformance checklist
CC-C22.1-1An adaptation signature SHALL bind to one declaredTaskFamilyorTaskSignature, one work target, and one work-measure threshold target rather than one generic improvement story.CC-C22.1-2An adaptation signature SHALL publishtimeToThreshold,budgetToThreshold, andpriorExposureDeclaration; if threshold was not reached, the signature SHALL say so explicitly instead of implying success.CC-C22.1-3Any declared transfer, retention, post-threshold-efficiency, downside, corridor-entry, or stepping-stone claim SHALL be explicit by value with the target, baseline, evidence source, or evidence locus named, not left as narrative garnish.CC-C22.1-4This pattern may refine specialization timing and reuse claims over the declaredC.22anchor, but it SHALL NOT redefine acceptance-gate thresholds, task-family attachment, or selector/parity law governed by another FPF pattern.CC-C22.1-5Downstream selector/parity pattern applications SHALL cite or consume the same published adaptation-signature field set rather than silently redefining threshold, prior-exposure, transfer, retention, downside, or corridor-entry terms.
C.22.1:End
Problematic-For Relation
Type: Conceptual (C) Status: Stable Normativity: Normative unless marked informative
Plain name. Actual problem.
Problem frame
Use this when. Use this pattern when an actual condition may be adverse for one exact entity and use, and a receiving claim needs to distinguish the actual Problem from a signal, criterion description, evaluation, assessment claim, ProblemCard, or claim that no suitable method is currently known.
First useful move. Name the actual-condition relation. Then name the exact predicate, entity, scope, and interval for which that predicate applies. If the condition falls on the adverse side of that applicable predicate, say plainly: "This condition is a problem for this entity in this scope." Expose a PFR occurrence only when another claim needs that Problem identity.
What goes wrong if missed. A card or evaluation result is allowed to create a Problem; the same criterion is applied to the wrong entity or scope; a new description edition creates a false new Problem; or one continuously adverse episode is split every time evidence is sampled. Conversely, two adverse episodes separated by actual non-adverse behavior collapse into one occurrence.
What this buys. Actual Problems can exist before discovery, can be referenced while still ongoing, and can be distinguished across repeated adverse episodes. One exact applicability relation supplies the predicate, problem-for entity, claim scope, and declared criterion-applicability window used by PFR; its actual occurrence extent is separately derived from uninterrupted obtaining. Measurements, evaluations, evidence, claims, cards, and method search remain available without becoming Problem identity.
Early battery stop. A low terminal-voltage reading can be a useful signal and can justify a ProblemCard, but it is not itself the actual-condition participant. Until a direct voltage-state pattern supplies the exact relation kind, participant meanings, obtaining rule, temporal extent, recurrence, and occurrence identity, the battery case remains explicitly non-conforming: the reading, alarm, report, assertion, and card establish none of that world-side relation. Once such a governor exists, the applicability relation can connect its selected voltage predicate to the exact vehicle, intended-start U.ClaimScope, and declared criterion-applicability window; discovering a method still changes solvability rather than PFR actuality.
Not this pattern when. Use C.22.2 when the current object is a problem-side card, signal, hypothesis, forecast, scenario, anticipated-condition claim, or reviewable formulation rather than an actual PFR. Use C.27, C.28, or the exact direct forecast, scenario, counterfactual, or anticipated-condition governor when that claim is current. Use the selected A.19 comparison, G.4 acceptance, state, gate, or measurement pattern when the current question is how to evaluate or support the adverse predicate. Use E.18.1, E.23, and the direct NQD or OEE patterns for repeated problematization, search, work, evaluation, and continuation.
Problem
An actual Problem is neither a record nor a free-standing quality label. It depends on an actual condition and on a criterion that applies to one exact entity, scope, and interval. The relation obtains when the condition is on the adverse side of that applicable predicate.
FPF needs one identity for this dependent evaluative relation without copying values defined by ProblemCriterionApplicabilityRelation into additional writable PFR slots. It also needs to distinguish continuous adverse episodes from repeated episodes while refusing to infer a recovery from missing observations or evidence.
Forces
Solution
Model an actual Problem as one obtaining ProblematicForRelation, a dependent evaluative U.Relation between exactly two relation occurrences: the actual condition and the applicability of a characteristic-space predicate.
Use one exact criterion-applicability relation
CharacteristicSpacePredicate is a by-value predicate used by an A.19 comparison, acceptance, state, gate, or other direct consumer. It is not a new U-kind, publication record, description edition, or comparison result. Its meaning is recoverable from the declared characteristic-space coordinates, scales, normalization or bridge values, operator, cut or band, polarity, and the selected direct consumer's governed comparator, admissibility, and predicate-use semantics. A separately performed evaluation remains U.Work; its result episteme and evidential-support relations remain separately governed, and none of these constitutes predicate meaning.
Before testing adversity, answer three plain questions: what exact point or value does this condition supply, how is that point obtained, and why is it the input for this problem-for entity and use? The by-value predicate therefore carries one ConditionToPredicateInputRule as part of its own semantics, not as another PFR participant:
- Direct input: the actual-condition participant is already a governed characteristic-assignment or state relation whose subject pattern exposes the exact characteristic-space coordinate, scale, and value used by the predicate.
- Projected input: when that relation does not itself expose the needed point, the rule cites one exact governed projection or bridge, its source relation kind and participant positions, target characteristic space, coordinate and scale, and the direct relation or predicate connecting that input to the problem-for entity and receiving use.
A relation reference alone is not a coordinate. If neither path yields the exact point and the problem-for link, adverse truth and PFR remain unestablished. When two projections are plausible, the rule names the selected one and the nearest inadmissible projection. ConditionToPredicateInputRule is a pattern-local by-value rule inside CharacteristicSpacePredicate; it is not a U-kind, relation occurrence, evaluation result, or copied PFR field.
Public name settlement. The following F.18 NameCard names the applicability relation kind. It does not make one applicability occurrence obtain and does not replace the relation signature below.
Use one individuable dependent U.Relation for applicability:
This relation states that one exact predicate currently governs one exact entity and claim scope under one declared criterion-applicability window. Its direct applicability predicate is satisfied while that criterion remains selected and governing for that entity, scope, and window; it does not ask whether any actual condition is presently on the adverse side. The applicability occurrence can therefore continue across adverse, non-adverse, and later adverse condition intervals. It ceases when the criterion is withdrawn or replaced for that use, the entity or claim scope changes, the declared window no longer covers the use, or another direct applicability condition fails. One occurrence is identified by the four fixed participants plus the maximal continuous period of actual applicability. Changing a participant yields another occurrence; actual loss and later restoration of applicability yields distinct occurrences even when all four participants stay fixed. A coextensional description edition or carrier change does not change either the predicate participant or the occurrence. Assessment windows, evidence-relevance intervals, description editions, claim-currentness windows, and adverse-truth intervals remain with their own claims and relations.
A semantic predicate change selects a different predicate participant; it is not an edition-only repair. If the new predicate replaces the old predicate for the same use and the old applicability therefore ceases, the old applicability occurrence ends and a new occurrence begins only if the new predicate actually applies. The PFR dependent on the old occurrence can then end, and another PFR can begin under the new occurrence when adverse truth obtains. If both predicates remain applicable, two applicability occurrences may coexist; a new criterion description alone does not prove replacement or cessation.
Keep the PFR signature reduced to two participants
Public name settlement. The following F.18 NameCard names the actual dependent evaluative relation. It does not create the Problem, add a third participant, or replace the occurrence-identity rule.
No-mint disposition for root U.Problem. Do not introduce a second problem entity beside the obtaining ProblematicForRelation occurrence. That occurrence is the actual Problem; a ProblemCard, criterion description, assessment claim, or local Plain label may describe or designate it but does not supply another world-side identity.
The complete non-derived participant set is:
The first reference resolves to the exact obtaining relation that constitutes the actual condition under its direct pattern. The second resolves to the exact obtaining applicability relation from C.22.PFR:4.1.
PFR has no separately writable condition-bearer, predicate, problem-for-entity, claim-scope, applicability-window, assessment-window, or description-edition slot. Those values are already fixed by the two participant relations and their defining declarations. A readable claim projects them from the two participants:
This is a derivation from one participant, not a consistency check between copies.
Use predicate truth as the obtaining condition
ProblematicForRelation obtains exactly when all three conditions hold:
- The exact
ActualConditionRelationobtains under its direct pattern. - The exact
ProblemCriterionApplicabilityRelationobtains because its criterion remains governing for the exact entity and claim scope under the declared criterion-applicability window, independently of whether the actual condition is adverse. - Apply the predicate's exact
ConditionToPredicateInputRuleto the actual-condition participant. It must yield the declared characteristic-space point or value and the direct link to the problem-for entity and use; that point then falls on the adverse side under the selected scale, comparator, cut or band, polarity, and admissibility semantics.
The selected direct consumer supplies the governed input projection or consumes the direct characteristic assignment, then governs the comparator and admissibility semantics. An evaluation may calculate or support a claim that the resulting point is adverse. Comparison outcomes, acceptance outcomes, state or gate results, measurements, evidence, and assessment claims are not automatically PFR participants, and producing them does not make PFR obtain.
A Problem can therefore obtain unnoticed. Later detection produces work, evidence, and claims about the already obtaining relation; it does not create retroactive actuality.
When evaluation is actually performed, recover every exact actual performer U.System through A.13, let A.15.1 independently admit the dated evaluation U.Work, and name the selected U.Method or declared A.6.1 operation application. Add F.6 only when the evaluation account or a receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; F.6 identifies neither assignment nor performer, neither a local system-role kind nor an assignment acts, and missing or failed F.6 leaves the evaluation Work intact. A short PFR explanation may omit an assignment identifier that no later claim uses. That Work may return the separate evaluation result true, false, or unknown defined by the selected evaluation pattern; a C.2.1 assertion may state the result, A.10 and B.3 may warrant reliance on that assertion, G.11 may qualify its current edition, and the receiving Work may rely, decline, defer, or reopen. These are distinct objects and relations. unknown is an evaluation result, never a world-side PFR value; no evaluation Work, result, assertion, warrant, currentness judgment, or reliance disposition constitutes a PFR participant or makes the relation obtain.
Identify repeated adverse episodes from world-side continuity
The direct occurrence rule is ontic. With the two participant occurrences fixed, one PFR occurrence is the maximal continuous episode during which both participants obtain and the selected condition point is actually on the adverse side. Actual cessation of either participant or actual movement to the non-adverse side ends that occurrence. Later renewed adverse truth starts a later PFR occurrence. Measurement, evaluation, demonstration, assessment, and evidence availability neither start nor end either occurrence.
Use this world-side identity basis:
adverseEpisodeStart is the episode's actual inception under the declared temporal reference, not the first observation or report time. When admitted time grain cannot distinguish co-inceptions, or when a receiving history must keep one reference while a claim about inception remains revisable, explicitly individuate the occurrence under A.6.REL and assign a stable pfrOccurrenceId that designates it. The resolution record may carry the current boundary claim, but neither its asserted start nor its asserted end becomes a mutable identifier field. The PFR's actualAdverseExtent is derived from the world-side episode: its end becomes fixed when the episode actually ceases, and a later claim may recover or correct that boundary. The recovered end and completed extent describe the occurrence; they do not replace it or change its assigned reference. This applies A.6.REL's participant-plus-episode rule without making a currently known boundary constitutive.
Participant references alone remain insufficient because the same participants can enter adverse, non-adverse, and later adverse episodes. A universal evaluation reference is also insufficient because an unnoticed PFR can obtain and several assessments can support one occurrence.
Keep world-side occurrence and current boundary claim separate
Use [adverseEpisodeStart, open] only in a current claim whose evidence supports that this same PFR occurrence still obtains at the claim's stated reference time. open is a claim-side endpoint sentinel, not the clock time, an identity field, or a substitute for missing evidence. The stable occurrence reference remains unchanged when a later claim records the recovered actual end.
A current assertion or description distinguishes three cases in ordinary words:
- supported current: the evidence supports continuous adverse obtaining from the episode's actual inception through the stated reference time; publish
[adverseEpisodeStart, open]; - supported closed: the evidence supports actual cessation at an exact boundary; publish
[adverseEpisodeStart, adverseEpisodeEnd]for the same occurrence reference; - continuity unresolved: the available evidence does not decide whether an unobserved cessation or restart occurred; retain the recoverable earlier occurrence reference and the supported segments, but assert neither one continuous occurrence nor two occurrences across the gap.
Later evidence may revise the assertion, including its claimed start, end, or continuity, without creating or changing the world-side episode. If it supports an earlier actual cessation, complete the extent of the earlier occurrence at that boundary. If it also supports later renewed adverse truth, identify the later occurrence from its own actual inception. Until that distinction is supported, do not attach the later adverse segment to either the old or a new occurrence by default.
Use the A-B-C regression while holding one continuously obtaining applicability occurrence fixed. The criterion remains governing for the same entity, scope, and declared window through A, B, and C; only world-side adverse truth changes:
- During A, the condition is actually adverse, so the first PFR obtains from
A.startuntil its actual cessation atA.end. - During B, the condition is actually non-adverse, so the first PFR does not obtain.
- During C, the condition is actually adverse again, so a later PFR begins at
C.startwith the same two participant references and a different stable occurrence reference.
Evidence that supports A, B, and C warrants the corresponding two-occurrence assertion. A missing assessment, unavailable measurement, stale evidence item, or support gap warrants continuity unresolved; it neither proves recovery nor licenses continuity. Adjacent or overlapping assessment windows likewise do not split or join world-side episodes by themselves.
Keep assertions, reliance, anticipated conditions, solvability, and cards separate
An assertion about the exact PFR obtaining predicate has affirmative or negative claim polarity. An affirmative assertion may designate an independently established occurrence; a negative assertion denies predicate satisfaction for the named participants and qualification but does not erase or reidentify an earlier occurrence. A.10/B.3 separately governs whether one receiving use treats that assertion as supported, refuted, or unresolved. Assertion polarity, support, and reliance therefore answer different questions.
A possible or anticipated problem remains an exact forecast, scenario, counterfactual, or anticipated-condition claim in ProblemCard or another episteme until an actual-condition relation, an applicability relation, and adverse predicate truth all obtain. C.2.1 governs its assertion identity and polarity; C.27, C.28, or the exact direct claim pattern defines or constrains assumptions, horizon, and non-actual semantics. None of those claim-side facts establishes a current PFR.
A ProblemCard is one C.2.1 episteme with one exact ClaimGraph, one independently identified EntityOfConcern, and one effective U.ReferenceScheme. It may carry claims designating several PFR occurrences only when those claims are jointly about that one EntityOfConcern under the direct pattern that identifies it. When two PFR references lack such a joint concern, split the ClaimGraph and card. Conversely, several cards may designate the same PFR through different ClaimGraphs, schemes, viewpoints, or receiving uses. Card count, merge or split, currentness, assessment window, publication, carrier, and edition change neither PFR actuality nor identity. C.22.2:20.1b replays all three branches with exact objects: two Robot-7 PFR episodes share one A.1-identified Robot-7 and one card; Robot-7 and Robot-8 PFRs have no direct joint EntityOfConcern and force two ClaimGraphs and cards; and two differently qualified cards retain the unchanged PFR-InspectionAssignment-17 reference.
A claim that no supported method is currently available concerns the admitted method set, evidence, constraints, and intended use. Selecting or discovering a method changes current solvability; it does not end PFR while the actual condition remains adverse. Performed repair work can end PFR only when an independently recovered actual change makes a participant cease or moves the selected condition point to the non-adverse side.
Repeated problematization, method search, work, evaluation, and continuation occur in work and transformation flows governed by E.18.1 and E.23. A claim or plan may carry a reference to the same PFR while work and transformation occurrences participate in a selected transformation-flow structure. Neither that reference use nor any flow-structure relation enters PFR identity. A later PFR is a later occurrence because a participant changes or because actual adverse truth begins again after actual cessation, not because another card, assessment, or flow visit exists.
Preserve the lightweight path
For a first use, name only what decides the case:
- the exact obtaining condition and the value or point it supplies;
- the criterion that makes that point adverse, including the selected input path and cut or band;
- the entity for which it is a Problem, the use or claim scope, and the applicability window.
Then write one ordinary sentence:
<condition and value>misses<criterion>for<entity and use>during<applicability window>; therefore it is an actual Problem for that entity and use.
Stop there when the next work only needs to recognize the Problem. Cite the direct condition and criterion patterns, but do not fill a PFR record, repeat either relation signature, or assign a PFR identifier. The NameCards and signatures above define reusable semantics; they are not a mandatory user form.
Add explicit identity only when another claim must compare, qualify, change, nest, plan from, or refer back to this particular Problem occurrence. That receiving claim then names the exact actual-condition occurrence, exact applicability occurrence, actual adverse inception or stable PFR identifier when needed, claimed extent, and any evidence or assessment claim on which its reliance depends. The evidence remains separate from the world-side Problem.
Archetypal Grounding
Executable first use — an assignment that violates a release criterion. InspectionReleaseAssignment is a declared U.SystemRoleAssignment species defined under A.2.1. It defines the holder and assigned-kind participant meanings, assignment predicate, applicability, and occurrence identity. Occurrence InspectionAssignment-17 has admitted System Robot-7 as holder and local kind InspectorSystemRole as assigned-kind value. It obtains without interruption during [2026-07-13T09:00, 2026-07-13T17:00]. MaintenanceRoles-2026, Maintenance-Scheme-A, and the interval description may interpret or describe the assertion; they are not extra world-side participants. A roster row and InspectionAssignmentAssertion-17 may describe the assignment and interval; neither makes the relation obtain.
A.2.1 identifies InspectionAssignment-17 through the complete real participant set and the maximal uninterrupted period in which the direct species predicate obtains. Demonstrated non-assignment after the stated 17:00 boundary ends it. If the same participant set again satisfies the predicate on the next day after that actual gap, InspectionAssignment-18 is a later occurrence; an evidence gap by itself neither ends nor splits the first occurrence. The subject pattern therefore supplies the participant meanings, obtaining rule, temporal extent, recurrence, and same-versus-new-occurrence rule required of ActualConditionRelationSlot.
The by-value predicate NoInspectorSystemRoleBeforeValidation-v2 uses one direct ConditionToPredicateInputRule: from InspectionAssignment-17 it reads the assigned-kind participant as coordinate assignedSystemRoleKind = InspectorSystemRole on a nominal system-role-kind scale and the holder participant as the direct link to problem-for entity Robot-7. Its adverse region is the declared set of system-role kinds prohibited for that System's autonomous-inspection release before validation, which contains InspectorSystemRole. The same kind assigned to another System is the nearest inadmissible input because its holder participant does not link the condition to Robot-7; a roster row is inadmissible because it is not the obtaining assignment occurrence.
Robot7ReleaseCriterionApplicability-4 is the separate applicability occurrence. Its four participants are that predicate, Robot-7, autonomous inspection release before validation as the exact U.ClaimScope, and declared window [2026-07-13T08:30, 2026-07-15T18:00]. Because both participant relations obtain and the selected point is adverse, PFR-InspectionAssignment-17 obtains on [2026-07-13T09:00, 2026-07-13T17:00]. The ordinary first-use sentence is:
Robot-7 is assigned as inspector through
InspectionAssignment-17, whileInspectorSystemRoleis prohibited for this System's autonomous-inspection release before validation during the declared 13–15 July window. This assignment is an actual Problem for Robot-7's release during its 13 July 09:00–17:00 assignment episode.
Evaluation and reliance remain separate. Admitted SafetyReviewSystem-2 : U.System performs dated InspectionReleaseCheckWork-21 under independently obtaining SafetyReviewAssignment-9 : SafetyReviewWorkAssignment <: U.SystemRoleAssignment; F.6 uses the assignment's holder projection, and the Work enacts InspectionReleaseCheckMethod-3. The operation application returns true for the adverse predicate. InspectionReleaseCheckAssertion-21 states that result; its evidence path and assurance tuple can warrant one release decision, G.11 can qualify the assertion edition, and the release Work can rely or decline. None is a third PFR participant. A ProblemCard may later designate PFR-InspectionAssignment-17; creating, revising, splitting, or publishing that card changes neither PFR participant nor actuality. If evaluation never occurs, the PFR still obtains. If the assertion is stale, the decision's reliance may become unknown, but the world-side relation is not thereby created, ended, or split.
Actuality and recurrence. Selecting another staffing Method and writing a Work order do not end the PFR. Only actual cessation of the A.2.1 assignment predicate at the stated 17:00 boundary ends it. When the same direct species predicate resumes on the next day as InspectionAssignment-18 while the applicability occurrence still obtains, A.2.1 identifies that later system-role-assignment occurrence and its later adverse inception grounds PFR-InspectionAssignment-18. An evidence gap alone establishes neither continuous assignment nor withdrawal and reassignment.
Blocked stress fixture — installed component. Fuse-R17 : U.System and Panel-7 : U.System may be named in a parts claim, but current A.14 supplies no installed-part relation kind, installed-part participant meanings, obtaining predicate, temporal extent, recurrence, or same-versus-new-occurrence rule. Under A.6.REL:5.2, ComponentOf-FuseR17-Panel7 is therefore not minted as an individuated installed-part occurrence here. A parts list, inspection note, removal report, or reinstallation wording cannot fill ActualConditionRelationSlot; the fuse case remains non-conforming until an accepted direct installed-part pattern supplies the complete settlement.
Blocked stress fixture — battery voltage. Current A.18 and C.16 can govern the voltage characteristic, scale, measurement work, result, uncertainty, and assertion. They do not supply a direct voltage-state relation with participant meanings, obtaining, temporal extent, recurrence, and occurrence identity. Therefore TerminalVoltageState-12 is not minted here, and the low-voltage case remains non-conforming until an A.6.RCD decision selects or assigns that direct governor. MeterReport-88, an alarm, or a maintenance card may support a claim but cannot fill ActualConditionRelationSlot or backdate PFR.
Blocked stress fixture — proof gap. Current proof and assurance patterns define or constrain proof epistemes, obligations, evidence, and relying decisions, but no inspected direct pattern supplies both (a) an individuable unresolved-consequence relation with its obtaining and episode law and (b) the exact proof-use or acceptance object and applicability relation needed by the case. Keep the condition gate and problem-for/applicability gate separate. UnresolvedConsequence-17, ProofUseEntity, and an omnibus proof-gap object are not admitted by this wording; the case remains non-conforming until both direct governors close.
Blocked stress fixture — clinical condition. A diagnosis, assessment, measurement report, and patient label are epistemes or context-dependent cues, not the clinical-condition occurrence or patient identity. No clinical-condition pattern selected in this package supplies the needed participants, obtaining, recurrence, identity, and temporal extent. Until one does, keep the case non-conforming. If patient also names a work-facing classification or assignment, recover the holder System, local system-role kind, assignment occurrence, and declared U.SystemRoleAssignment species separately; none supplies the missing clinical-condition relation.
Blocked stress fixture — missed transfer. First distinguish transfer Work, a world-side transfer or delivery relation, a commitment or acceptance relation, and a package or record episteme. E.18's structural U.Transfer cannot be reused merely by the phrase hand-off failure. No inspected direct pattern supplies the exact missed-transfer condition relation, and the phrase receiving work does not decide whether the problem-for entity is intended U.WorkPlan, dated U.Work, or another governed entity. The case therefore remains non-conforming until separate direct governors settle both questions.
Blocked stress fixture — one hot surface, two uses. No inspected direct pattern supplies an individuated hot-surface condition relation; a temperature reading cannot substitute for it. If such a governor later exists, hold its one occurrence fixed and use two distinct applicability occurrences when an exact receiving U.Work and an exact U.System have different problem-for fillers, scopes, declared windows, or applicability continuity. Adverse truth would then yield two PFR occurrences sharing only the condition reference. Until the condition gate closes, this remains a multiplicity test, not an asserted example.
Repair branch replay. Keep four outcomes distinct: a repair method is selected; repair work is planned; dated repair work occurs without a demonstrated condition change; or dated repair work is connected through its direct change/result governors to actual cessation or non-adversity of the condition. Only the fourth outcome can end PFR while applicability continues. A work record, result claim, acceptance verdict, or method label is insufficient.
Bias-Annotation
This pattern has an actuality bias: Plain problem names an obtaining dependent relation. The anticipated-condition guard preserves forecasts, scenarios, counterfactuals, hazards, and problem formulations as useful epistemes under their exact claim governors without backdating actuality.
It has a predicate-centered bias because adverse truth is load-bearing. The applicability relation prevents a criterion from becoming globally adverse by label; exact entity, scope, and interval stay explicit.
It also has a continuous-time bias for occurrence identity. Discrete-state and event-based domains can supply equivalent actual episode boundaries under their temporal reference. Evidence gaps leave the continuity assertion unresolved in either representation; they do not decide the world-side boundary.
Conformance Checklist
- The actual condition is an explicitly individuated obtaining
U.Relationunder its direct pattern. CharacteristicSpacePredicateis given by value and includes one exactConditionToPredicateInputRule: either a direct governed characteristic assignment/state relation or a named governed projection/bridge to the exact coordinate, scale, and problem-for link. A criterion-description identifier, arbitrary relation reference, or plausible alternative projection is insufficient.ProblemCriterionApplicabilityRelationhas the predicate, exact problem-for entity, claim scope, and declared criterion-applicability window as its four participants. It obtains while that criterion governs those participants, independently of adverse-condition satisfaction; its occurrence extent is the maximal continuous period of actual applicability.- PFR has exactly two non-derived participant slots: actual condition and criterion applicability.
- Predicate, entity, scope, declared criterion-applicability window, and actual applicability-occurrence extent are projected from applicability rather than copied into PFR.
- The selected direct consumer obtains the exact point through the declared direct assignment or projection and governs comparator, cuts or bands, polarity, admissibility, evaluation, and support; the condition relation is never treated as a coordinate by itself.
- Evaluation work, outcomes, measurements, evidence, assessment claims, descriptions, and cards do not create or identify PFR by default.
- Repeated PFR occurrences use the two participant references plus actual adverse inception. Add a stable occurrence identifier only for co-inceptions or a receiving history that must survive revision of the claimed inception boundary; the currently asserted start, derived end, and completed extent are not mutable key fields.
[adverseEpisodeStart, open]is used only by a claim that supports current continuous obtaining; a later supported end completes the claimed extent on the same stable occurrence reference.- Actual non-adverse B between actual adverse A and C yields two world-side PFR occurrences. Evidence can support, refute, or leave that boundary unresolved; a gap alone proves neither one occurrence nor two.
- Method availability and solvability claims remain separate from PFR actuality and identity.
- Possible conditions remain exact forecast, scenario, counterfactual, or anticipated-condition claims under their direct governors until both participant relations and adverse predicate truth obtain; assertion polarity and reliance posture do not substitute for those obtaining conditions.
- Ordinary readable use can stop before explicit PFR materialization when no receiving claim needs Problem identity.
- Battery-voltage, proof-gap, clinical-condition, missed-transfer, and hot-surface cases remain explicitly non-conforming until their named direct condition and, where applicable, problem-for/applicability governors exist; a phrase, measurement, diagnosis, record, card, or structural transfer does not mint them.
Common Anti-Patterns and How to Avoid Them
Consequences
Benefits. PFR gives actual Problems stable identity without turning cards or evaluations into world-side constituents. Two entities or scopes can use one predicate without collision, repeated adverse episodes remain distinguishable, and ongoing episodes can be referenced before closure. Unknown evidence remains epistemically honest.
Costs. A load-bearing use must recover a by-value predicate, its exact condition-to-input rule and problem-for link, and one exact applicability relation. Direct consumer patterns must state how the selected point is obtained and how adverse truth is evaluated, including comparator and polarity semantics. Temporal identity requires a real recovery boundary rather than assessment timestamps.
Limits. C.22.PFR does not define domain criteria, measurement methods, comparator semantics, acceptance policy, evidence sufficiency, method search, repair work, or problem-card publication. It governs only actual Problem obtaining, dependence, projection, and occurrence identity.
Rationale
Applicability is independently useful: it states which predicate applies to which entity and use under which declared criterion-applicability window even when no adverse condition currently exists. Keeping those four participants canonical there prevents disagreements between duplicated fields, while maximal continuous actual obtaining distinguishes repeated applicability occurrences without adding a fifth participant. PFR adds the exact missing fact: the named actual condition is adverse for that applicability occurrence.
The maximal continuous adverse episode resolves a genuine identity collision, but its completed interval value is not a stable reference key. Participant references plus actual adverse inception retain one occurrence reference before and after closure; the derived end completes its extent. Actual non-adverse behavior ends the occurrence and later renewed adverse truth starts another. Assessments can support, refute, or leave those boundary claims unresolved, but they neither supply the world-side boundary nor create the occurrence.
SoTA-Echoing
External-source qualification and reopen. The three non-FPF rows are qualified to the cited 2026 material and the current FPF direct relation and temporal interfaces used here. The selected seminar material is only a practice-pressure comparator for separating problematization, criteria, method search, performed work, and results; it supplies no ontology or occurrence law. The cited 2026 gUFO preprint is only a current research comparator for dependent relations, reification, and occurrence identity; its category hierarchy is not imported. The TypeDB Core Concepts documentation is only implementation evidence that relation instances can participate in relations; database semantics do not establish FPF truth or identity. Reopen only the affected row if later seminar material changes the separation being tested, a later gUFO edition changes the relevant relation or occurrence treatment, TypeDB changes the cited relation-participation semantics, or a current FPF subject pattern changes so that the comparison no longer tests this Solution. A carrier, hyperlink, or layout change with unchanged source content does not reopen the decision.
These lines change the Solution by keeping evaluation outside PFR, admitting relation occurrences as participants, identifying repeated episodes from actual adverse inception and cessation, and separating a stable world-side occurrence reference from revisable boundary claims.
Relations
A.6.RELgoverns explicit individuation of both PFR participants and PFR itself when a receiving use needs identity.A.6.RCDgoverns each missing direct-condition or applicability relation decision; C.22.PFR keeps the affected case non-conforming until an existing direct predicate closes it or a separately admitted direct subject pattern supplies obtaining, recurrence, and occurrence identity.A.6.5governs the two PFR participant SlotSpecs and the four applicability SlotSpecs.A.19governs the characteristic space used byCharacteristicSpacePredicate; the selected direct consumer governs its condition-to-input rule and comparator semantics,A.19.CPMgoverns comparison when that is the consumer, andG.4governs typed acceptance clauses when acceptance is the consumer.C.16,A.18, and direct condition or measurement patterns define or constrain characteristics, scales, actual characteristic assignments or state relations, and measurements. F.9 governs any cross-reference-scheme bridge named by the input rule; none of these adds a PFR participant.C.22governs selector-facing task typing and TaskSignature assignment after a problem-side episteme is usable.C.22.2governs ProblemCard claims, signals, forecasts, scenarios, anticipated-condition cues, descriptions, next use, and publication without creating PFR; the exact direct claim pattern defines or constrains each claim carried there.A.15.1andA.3.4govern repair work and changes to the actual-condition relation.E.18.1,E.23, and direct NQD and OEE patterns define or constrain repeated problematization, method search, work, evaluation, and continuation; relations locating or ordering those occurrences in a transformation-flow structure do not enter PFR identity.C.27.TAgoverns temporal aspect statements when interval publication or temporal adequacy is current.A.10,B.3, andG.11govern evidence use, assurance, and source or claim currentness.
C.22.PFR:End
ProblemCard
Type: Calculus (C) Status: Stable Normativity: Normative
Plain name. Problem-side card.
Intent. Give a practitioner one compact C.2.1 episteme that turns a messy signal into reviewable problem-side claim content before Principles-to-Work or selector use. The card preserves practical formulation functions while every world-side relation, evidence use, decision, method, plan, and Work occurrence remains with its direct governor.
Use this when. Use this pattern when work starts from a signal, anomaly, drift, risk, hypothesis, stakeholder demand or concern, set-derived candidate, underused capability, new constraint, new environment, opportunity-like cue, or solution-shaped request, and a downstream task-typing, method-family, planning, evidence, gate, autonomy, or P2W use needs one reviewable problem-side episteme.
Do not use this when. Use another pattern directly when the current question is already actual PFR obtaining, task typing, method selection, Work planning, evidence, provenance, assurance, gate decision, autonomy, archive or selected-set governance, mathematical-lens use, or ordinary discussion with no receiving use. C.22.PFR governs the actual Problem; C.22 governs TaskSignature constitution and assignment.
Builds on. C.2.1, E.2, E.9, E.10, C.2.P, A.6.P, C.16.Q, C.16, A.19, C.22, C.25, C.29, G.5, G.9, A.6.3.RT, and A.6.4.
Coordinates with. C.11, C.18, C.19, C.22.1, C.22.PFR, C.24, C.27, C.28, A.15, A.15.5, A.21, E.16, G.6, G.11, A.10, B.3, E.17, E.17.ID.CR, A.6.3, F.9, E.18, E.18.1, C.32.P2S, and E.10.MOVE.
Boundary summary. C.22.2 yields one reviewable ProblemCard, a P2W-ready problem-side input for downstream C.22, or an honest stop naming the direct pattern for the claim, relation, or boundary now current. It yields no world-side Problem, task assignment, selected method, WorkPlan, Work occurrence, gate result, or evidence verdict.
C.2.1 constitution. One ProblemCard is one U.Episteme constituted by one exact ClaimGraph, one independently identified joint EntityOfConcern, and one effective U.ReferenceScheme. U.ClaimScope, assumptions, horizons, qualification windows, viewpoints, and receiving uses qualify only the exact claims and direct relations that need them. No setting, carrier, organization, card id, or publication is a fourth constitution component or identifies an actual Problem. An exact composite or component U.Work under A.15.6 may be referenced by a claim or receiving use; it neither constitutes the card nor identifies the Problem.
Claim-family, actuality, and solvability boundary. A card may carry several claims only while their ClaimGraph has that one joint EntityOfConcern. An actual-problem assertion states affirmative or negative polarity for the exact ProblematicForRelation obtaining predicate. An affirmative assertion may designate an independently established occurrence only when C.22.PFR supplies both participants and its adverse episode; negative polarity creates, ends, erases, or reidentifies no occurrence. A.10/B.3 separately states supported, refuted, or unresolved reliance for one receiving use; G.11 separately governs assertion-edition currentness. Forecast, scenario, counterfactual, and anticipated-condition claims retain their exact assumptions, horizon, and direct governor and do not assert a current PFR. A method-availability or solvability claim concerns the admitted method set, evidence, constraints, and intended use; selecting a method changes that claim, not an independently obtaining PFR. Card creation, acceptance, publication, merge, split, label, Work reference, viewpoint, or setting word makes or ends no PFR. Only non-adversity or cessation of the actual-condition or criterion-applicability participant can end its maximal continuous adverse episode; missing, stale, refuted, or absent evidence cannot.
Problem Frame
A working team can begin with symptoms, anomalies, stakeholder signals, constraints, risks, old solution evidence, comparison ideas, solution temptations, underused capabilities, new environments, opportunity-like cues, or members of a retained set. Opportunity-like signals still need an exact EntityOfConcern, effective ReferenceScheme, ClaimScope, claim family, not-wish reason, improvement or acceptance probe, and honest next use; they do not turn this pattern into an ideation pattern.
Problematization becomes useful here when it produces claim content a practitioner can inspect. The card distinguishes the observed signal from the claim family being considered; the one joint EntityOfConcern from nearby affected entities; the effective scheme and scope from generic setting words; actual-PFR assertions from forecasts and solvability claims; and problem-side readiness from method, Work, gate, or evidence conclusions.
Current FPF already governs archive, pool, front, selected set, parity, refresh, method selection, evidence, autonomy, gate, representation transition, Bridge, mathematical-lens use, TaskSignature, and actual PFR obtaining. ProblemCard carries only the signal, problem-side claims, exact references, and next-use cues needed to reach those patterns without duplicating their objects.
The first-minute question is:
Can I state one exact concern, claim family, scheme, scope, improvement or acceptance probe, and honest next use without turning a signal, card field, setting label, evidence result, or proposed method into the actual Problem?
Thin First Use and Output Kind
Thin First-Use Form
The first substantive use is the Thin form. It is a practitioner-facing prompt for the smallest reviewable card, not a demand to complete a schema.
A ProblemCard is complete for its current use when it states:
- what signal or cue made the practitioner stop;
- the one exact joint
EntityOfConcern, effectiveU.ReferenceScheme, andU.ClaimScopefor the claims being carried; - which claim family is current: actual-PFR assertion, anticipated-condition claim, method-availability or solvability claim, or another directly governed problem-side claim;
- why this is not merely a wish, ticket, slogan, label, or preselected Work request;
- what would count as improvement or as an acceptance probe; and
- one honest next use.
The next use may be P2W-ready, characterize, compare, search, refresh, retire, archive, abstainOrNoChange, or apply the direct pattern governing the named claim, relation, or boundary. If an improvement check or acceptance probe is absent, the card may preserve the signal and choose one of the other uses but cannot claim P2W-ready.
C.22.2 - ProblemCard is the pattern heading. A ProblemCard instance is the C.2.1 episteme described above. ProblemCardRef is only a reference value designating one such episteme; it is not another durable kind. Plain-register glosses and local labels do not replace the Tech name.
Local labels include problem-formulation follow-up reason, validation boundary, risk condition, solvability band, P2W-ready, reviewable, stale, refreshed, retired, archived, abstainOrNoChange, and firstPrinciplesCue. They describe claim content or a local disposition; they create no FPF kind, state-machine kind, gate result, relation occurrence, or mathematical-lens object.
Use E.10.MOVE only when move-like wording no longer denotes one of these local dispositions and instead hides a pattern-use recommendation, Work-entry readiness, performed Work, gate, transformation, source relation, architecture move, call-planning move, or another directly governed value.
Reference labels ending in Ref are reference positions, not kind names. This includes ProblemCardRef, sourceSetRef, rivalProblemFormulationRef, and representationOrWordingUseRelationRef.
Semantic locality comes from the exact EntityOfConcern, effective ReferenceScheme, ClaimScope, declared assumptions or window, and receiving use carried by the relevant claims. A broad domain, organization, practice, or location label is only recognition material until those exact values are recoverable. None becomes a container participant or establishes global Problem identity.
Plain gloss for P2W-ready: problem-side input ready. It means ready as input to downstream P2W or selector reasoning, not ready for Work execution, gate passage, method selection, evidence reliance, or autonomy.
When a downstream reader asks whether intended Work can enter a work boundary, the card may supply problem-side cues, acceptance probes, constraints, and freshness conditions, but A.15.5 governs the readiness relation. C.22.2 decides no full-kit preparation, commitment, launch gate, or performed Work.
Required Solution Use
The Solution turns observed signal material into one C.2.1 episteme and one governed next use, not a completed form.
- Capture the symptom, anomaly, risk, stakeholder cue, drift, hypothesis, or other observed signal before naming an actual Problem.
- Recover the one joint EntityOfConcern, effective ReferenceScheme, ClaimScope, and claim family. If the claims concern unrelated entities, split the ClaimGraph and card.
- Separate the signal detector, actual-PFR assertion if independently grounded, anticipated-condition claim, improvement check, candidate acceptance criterion, method-availability claim, monitored risk signal, and proxy-distortion risk. These are not one card status or one PFR participant set.
- Pay only for current complexity. Add conditional content only when it changes the current next use; otherwise stop at the lighter card or name the direct pattern for the claim now current.
- If the formulation changes EntityOfConcern, effective scheme, ClaimScope, diagram, functional description, or transformation-flow interpretation, name the representation-transition, retargeting, Bridge, structural-reinterpretation, or wording-use relation before inheriting an earlier card disposition.
- Close by the honest next use. A filled card without a truthful next use is not a successful result.
Cheap stop. The smallest card that gives a truthful next use is sufficient. A conforming use does not require heavier fields merely because the full inventory exists.
First practitioner use. State the signal, joint EntityOfConcern, scheme, scope, claim family, not-wish reason, improvement check or acceptance probe, and honest next use. Open the relation-boundary aid only when another claim or relation changes that move.
Relation Boundary Aid
Use this aid only after the Thin ProblemCard is legible: signal, joint EntityOfConcern, effective ReferenceScheme, ClaimScope, claim family, not-wish reason, improvement check or acceptance probe, and honest next use. It is not a second writing order and not a catalogue of other patterns. It answers one question:
Which claim being made, relation, or boundary changes the problem-card use, and which FPF pattern defines or constrains that claim, relation, or boundary?
If the claim, relation, or boundary does not change the current problem-card use, leave it out of the card. If it does change the move, keep only the local cue or reference that makes the card reviewable, then apply the subject pattern for that claim, relation, or boundary.
Over-capture symptom: the practitioner spends the pattern use classifying FPF patterns while one or more core Thin items in C.22.2:2.1 remain unstable.
Repair: return to the exact Thin form in C.22.2:2.1 and complete only its core items. Reopen this aid only for the claim, relation, or boundary that changes the honest next use.
Use Boundaries and Record Budgets
Use C.22.2 when a signal is not yet a problem-side record and downstream task typing, P2W, method-family selection, work planning, evidence use, gate passage, autonomy control, or selected-set use depends on such a record. A known method does not close this pattern when the problem signal, scope, acceptance probe, or EntityOfConcern remains unstable.
Use another pattern directly when the question under repair is already that pattern's EntityOfConcern or governed relation: A.15 for work planning or performed work; A.10, G.6, or B.3 for evidence, provenance, or assurance; A.21 for gate decision; E.16 for autonomy; C.11 for a local choice among explicit options; and C.18, C.19, or G.5 for archive, pool, front, or selected-set governance. C.22.2 may still preserve the problem-side cue or reference that explains why that pattern is now current.
Use record budgets:
- Thin record budget: signal, joint EntityOfConcern, effective ReferenceScheme, ClaimScope, exact claim family, not-wish, not-slogan, not-ticket, or not-preselected-work reason, provisional improvement check or acceptance probe, and one honest next use.
- Standard record budget: Thin fields plus the current comparison, acceptance, risk, validation, freshness, unknown-handling, or P2W-readiness fields needed for downstream use.
- High-relation record budget: Standard fields plus only the relation references needed when public, disputed, high-risk, set-derived, cross-scheme, cross-use-boundary, evidence-adjacent, autonomy-adjacent, gate-adjacent, agentic, temporal, causal, representation, or Part-G relations are current.
Stop at Thin when it gives a truthful next use. Stop at Standard when it is enough to emit or bind a minimal TaskSignature, TaskKind, or ProblemProfile. Apply the governing FPF pattern for the claim being made, relation, or boundary instead of enlarging the card when the issue under repair is no longer the problem-side record itself.
Field Labels and Current-Use Conditions
Use these readable labels only when current for the case:
-
problem signal and exact signal reference;
-
one exact ClaimGraph, joint EntityOfConcern, effective ReferenceScheme, and ClaimScope;
-
actual-PFR assertion with exact polarity and PFR reference only when C.22.PFR independently establishes the occurrence;
-
anticipated-condition, forecast, scenario, or counterfactual claim with assumptions and horizon;
-
method-availability or solvability claim with admitted method set, evidence qualification, constraints, and intended use;
-
primary viewpoint or an explicitly recovered system-role-kind, assignment, relation-participation, responsibility, or other direct concern as claim qualification, never as card or PFR identity;
-
symptom detector, problem hypothesis or cause-theory cue, and rival formulation when current;
-
improvement check, acceptance probe, characterization relation, characteristic or Q-bundle relation, indicator selection, and parity or comparison relation when current;
-
mandatory constraints, risk condition, validation boundary, freshness or expiry condition, and unknown handling;
-
problem-formulation follow-up reason when it changes review, discrimination, or receiving use;
-
representation-transition, retargeting, Bridge, structural-reinterpretation, or wording-use reference when an earlier disposition may no longer transfer;
-
sourceSetRef, source-set kind, selection or retention criterion, budget or window, and non-scalar next use when the signal comes from a set, pool, front, archive, shortlist, or selected set; -
firstPrinciplesCuewhen a mathematical structure changes the formulation; and -
subject-pattern cue naming the direct pattern, claim kind, exact receiving-use reference, and stop condition when an outside claim changes the card use.
If a conditional value is not current, omit it rather than writing unknown. Use unknown only where the exact current value rule permits that result. If a required current value is unavailable, state whether the next use is blocked, degraded, sandboxed, or must be reconsidered under a named condition. A stale value gets the exact G.11/currentness assertion; an intentionally omitted value states the record-budget reason without implying it was checked.
When the card compares options, retained candidates, or rival formulations, it states the exact comparison or parity relation or why comparison is not current. Absence is a disposition, not an automatic defect; any positive parity or selected-set result remains outside C.22.2.
problemCardWitnessRefs may be used as a local recoverability group, not as a new kind or evidence graph:
Generated variants, evaluator feedback, and open-ended mutation remain signal or source-set cues. They do not constitute the card, supply evidence sufficiency, make PFR obtain, or authorize action.
Anti-Pattern Checks and Worked Slices
Anti-pattern checks start from the local card use:
- card-as-executable-work request: the card is treated as executable work while method, plan, and work occurrence remain undecided;
- form-completion: every field is filled because the template exists, even though the Thin next use would be truthful;
- readiness shortcut:
P2W-readyis declared from signal and scope alone, without improvement check or acceptance probe; - source-claim shortcut: a preselected solution, work request, proof-looking reference, gate-looking cue, or authority-looking cue replaces one or more core Thin items in
C.22.2:2.1; - scalar shortcut: archive, set-return, Goldilocks, NQD, OEE, partial-order, stepping-stone, or indicator material collapses into one readiness score;
- prestige shortcut: first-principles or mathematical wording is kept without practical payoff, preserved and lost structure when current, problem-formulation follow-up reason, and stop condition.
Local stop rule: if the encountered material tries to carry a claim outside C.22.2, the card keeps only the cue or reference that changes problem formulation or the next use, then names the governing FPF pattern and claim kind named by value to use before that claim is relied on.
A conforming C.22.2 use is testable against at least one Thin worked slice, such as repeated task rework or another compact problem signal, showing signal, EntityOfConcern, ReferenceScheme, ClaimScope, exact claim family, not-preselected-work reason, improvement check, and honest next use. It is also testable against at least one High-relation worked slice from a set, archive, pool, front, shortlist, selected set, or portfolio source, showing sourceSetRef, candidate acceptance criterion, risk condition, and the claim, relation, or boundary without creating a local portfolio or archive kind.
Conformance Checklist Requirements
The checklist protects a completed or reviewed card from overread; the writing order remains the Thin form and honest next use.
Problem-Kind Recovery
Problem remains an ordinary word when no FPF-governed claim is being made. Recover it only when wording changes a governed kind, relation, selector use, evidence claim, causal-use claim, assurance claim, decision, or use boundary.
The card may reference candidate ProblemProfile, TaskSignature, source set, PFR, forecast, solvability claim, or first-principles cue only when that reference changes its use. No reference is promoted into a local kind or card constitution component.
Problem, Task, Method, Work, and Result Split
ProblemCard remains usable while a method is unknown, contested, or not yet selected. A known method does not make the card ready while any core Thin item in C.22.2:2.1 remains unstable. If the problem-side episteme and method are accepted and only planned execution remains, apply A.15.
Transition to C.22 only when the card can prepare or designate the exact problem-side episteme or ProblemProfile needed by one receiving use and one TaskSignature is adequate for that use. If several profiles or signatures remain plausible, preserve candidates rather than asserting one assignment. When the question becomes selection, planning, performed Work, result, gate, evidence, or reliance, apply its governor instead of expanding the card.
Relation to C.22
C.22 governs TaskSignature constitution and TaskSignatureAssignmentRelation. ProblemCard is earlier and explicit: it states which problem-side claims are ready for P2W, search, comparison, characterization, refresh, retirement, or another direct pattern.
A card may prepare TaskKind, characteristic bindings, scope, and candidate TaskSignatures. C.22 assigns one only when the exact problem-side episteme, TaskSignature, and receiving-use episteme satisfy its obtaining rule. Several plausible signatures remain candidates.
No card detail is copied wholesale into TaskSignature. Downstream method, Work, result, evidence, gate, autonomy, archive, portfolio, and selected-set claims remain with their direct patterns.
Characterization, Indicators, and Comparability
ProblemCard states either a recoverable characterization relation and comparability or parity relation, or an explicit current reason why the problem can proceed without one.
The heavy content stays with existing FPF patterns:
C.16carries measurement characterization, backing, and comparability discipline;A.19carries characteristic, scale, unit, polarity, and indicator-use discipline;C.25carries Q-bundles and quality-like multi-characteristic bundles;G.9carries parity, comparison-window, comparator, budget, unit, repeatability, and reproducibility pins;G.0carries comparison-frame and CG-Spec governance;G.4carries acceptance clauses and threshold predicates;- use
G.5for selector-facing selected-set result declaration when the problem enters a selected set; when actual audience availability is separately current, useE.17for a source-backed publication face and return to source andE.24.PUBfor the publication occurrence, form, carrier, audience, bounded use, and availability.
Missing characterization or parity relation is a current disposition. The record applies the characterization, parity, search, or pool pattern when that relation is current instead of pretending the problem is ready for P2W.
The C.22.2 candidate acceptance criterion separates functional check, constraint compliance, risk or safety boundary, parity or comparison relation, and freshness window when those relations are current. Comparison frame, CG-Spec, or comparability governance is governed by G.0. Acceptance clauses and acceptance threshold predicates apply G.4; C.22.2 may name only the needed relation, cue, or reference. Passing a test, improving one observed indicator value, or naming an acceptance phrase is not by itself sufficient for P2W use.
Source Record-Form Recovery
Source record names are recovered by use, not by label shape. This section prevents source prose from becoming local C.22.2 subobjects.
The repair rule is short: if the source material supplies problem-side material, copy the material into the card's current fields. If it supplies another FPF-governed claim, keep only the local cue and apply the pattern that defines or constrains that claim.
Portfolio, Archive, and Set-Return Treatment
Archive, portfolio, pool, front, shortlist, selected-set, and set-return material remain source and set cues for the current problem-side record. ProblemCard preserves sourceSetRef, source-set kind, selection or retention criterion, and the non-scalar next use when current; portfolio and archive governance stays with the named subject patterns and does not become a local problem-card kind.
Archive, portfolio, palette, front, shortlist, ranked shortlist, selected set, LivePool, and set-return material remain current source distinctions, but their current FPF subject patterns are already available:
A singleton problem card is the degenerate case. If it came from a portfolio, front, archive, or pool, the selected problem remains traceable through sourceSetRef: the lightweight reference to the source-set kind, source reference, selection or retention criterion, budget or window, review cadence, and direct pattern when current. sourceSetRef is a reference field, not a new kind and not a downstream claim carrier.
sourceSetRef preserves the recoverable set-source relation when current: Palette, Front, Archive, ExplorationArchive, Shortlist, RankedShortlist, SelectedSet, LivePool, or another accepted source-set form. If the set-source relation is not recoverable, the card may keep a set-finding cue, but it does not claim selected-set readiness or archive-derived readiness.
When multiple plausible problem formulations remain current, C.22.2 does not bind one TaskSignature prematurely. Each optional rivalProblemFormulationRef states the rival formulation, EntityOfConcern, effective ReferenceScheme, ClaimScope, preserved concern, lost concern, reason not selected yet, and next discrimination action. It is not a CG-Frame, not the E.8 Problem Frame, and not a representation-frame kind.
The next discrimination action may be to characterize, compare, retarget, reopen the source material or source relation, choose a local problem formulation, or apply the relation-bearing pattern. Reframing is triggered when EntityOfConcern, effective ReferenceScheme, ClaimScope, viewpoint qualification, or cause-theory cue changes the problem representation enough that readiness or use-boundary cannot be inherited by wording continuity.
Goldilocks and Set-Return Docking
Goldilocks problem selection is the problem-side adaptation of the current NQD, OEE, and set-return family. It is not direct QD or OEE vocabulary import, not a new scalar readiness doctrine, not a local QD or OEE vocabulary, and not a single score. C.22.2 does not mint GoldilocksProblem, GoldilocksScore, GoldilocksReadiness, or any equivalent local kind; Goldilocks remains a readiness and selection interpretation carried by current subject patterns.
A Goldilocks, stepping-stone, or archive-derived problem is represented by its source-set reference, selection or retention criterion, and current next use, not by one difficulty, priority, or readiness score.
ProblemCard carries only the problem-side readiness fields and relation references:
- source set kind when archive, pool, front, shortlist, selected set, or portfolio language is current;
- solvability band;
- characteristic-space, declared problem-side characteristic descriptor, or Q-bundle relation;
- declared difference criterion when novelty or diversity is claimed, or apply the governing characterization or comparison pattern;
- non-scalar trade-off, dominance, partial-order, or set-return relation when that relation is being made;
- measurability or explicit unknown handling;
- reversibility or containment for safe probing when current;
- stepping-stone option value when retention matters;
- expiry or refresh condition;
- selected-set, archive, pool, front, or parity relation when that relation is being made.
The local solvability band label means a scheme-and-scope-qualified, non-scalar interpretation of feasible-but-not-trivial fit under current capability, constraints, validation boundary, and optional set-return relation. It is not a universal difficulty claim, hidden readiness scale, or single-score ranking.
If the band cannot be tied to a characteristic, Q-bundle, comparison, retention, or capability relation and its qualification, treat Goldilocks wording as informal recognition only and bind any selection, set-return, or parity claim to its direct governor.
The current governing family is C.18, C.19, G.5, G.9, G.11, A.6.P:7a, and C.16.Q. Its relation to C.22:14 concerns entry and timing inside the same family: C.22.2 uses it before P2W, while C.22:14 uses it downstream when candidate solutions for a TaskKind make TaskSignature informative.
Structure Cue That Improves Formulation
C.29 carries mathematical-lens use for first-principles or mathematical structure cues used by ProblemCard.
firstPrinciplesCue is a local cue label for a formulation-changing structure and a cue to apply C.29; it is not a local mathematical-lens kind or a substitute for a C.29 lens-use result.
The problem card may ask whether a first-principles or mathematical structure helps find or improve the problem formulation, not only whether an already-mentioned mathematical expression helps the problem formulation. Useful cues include state space, graph, boundary, topology, symmetry, invariant, variational or constrained-optimization structure, probability or information structure, resource bound, obstruction, scale window, composition, or coarse-graining choice.
The practitioner-facing use is:
State the structure that improves the problem formulation, the preserved structure, the lost structure, the practical payoff, the problem-formulation follow-up reason, and the stop condition.
Distribution by principles:
When no useful mathematical structure survives, record that absence and proceed without forcing mathematical prose into the problem card.
Validation, Reliance, AI-Agent Cues, and Safe Probing
ProblemCard exposes three local fields for downstream use:
- problem-formulation follow-up reason: why this formulation is worth keeping, reviewing, discriminating, or moving onward now;
- validation boundary: what has been checked for the current next use, what may be used now, and which use is governed by another pattern;
- risk condition: the monitored risk, cost-of-error concern, or containment concern that may change the safe next action.
Use these fields to state a local reliance disposition, not to authorize downstream action.
Cause-theory cues may focus problem formulation inside ProblemCard. Association, intervention, counterfactual, responsibility, expected-effect, or causal-evidence claims are governed by C.28 plus evidence, provenance, or assurance patterns when those claims are being made.
Environment design and safe probing may appear as problem signal reference, validation boundary, risk condition, or subject-pattern cue. If the next action can affect a controlled EntityOfConcern, the card names the probe need plus the claim kind named by value that blocks local action; any deontic permission, work authorization, release authorization, or gate passage stays with the subject pattern for that claim.
Freshness, Expiry, and Unknown Handling
C.22.2 includes a section-local state and disposition vocabulary for ProblemCard; this vocabulary is not a new FPF kind. These labels describe the card's current governed use; they are not required states in a transition sequence, event kinds, or gate records. The local labels are:
Freshness names the exact affected locus: problem signal, effective ReferenceScheme, ClaimScope, characterization or parity relation, problem-formulation reason, source material, source relation, source-set reference, representation relation, or wording-use relation. For the problem signal, ask whether it is still present, recurring, solved, absorbed, duplicate, unnecessary, or no longer worth downstream work. For ReferenceScheme or ClaimScope, ask whether the applicable meaning, cut, assumptions, window, or receiving use changed enough to alter the formulation. For characterization or parity, ask whether measurement, comparison, and parity relations are current enough for the intended use. For the formulation reason, source material, or source relation, ask whether cited sources, provenance, reason references, and source references remain current. For a source set, ask whether archive, front, pool, shortlist, or selected-set membership and its selection or retention criterion remain current. For a representation or wording-use relation, ask whether wording, diagram, functional description, transformation-flow path, Bridge, retargeting, or other representation change alters the EntityOfConcern, effective ReferenceScheme, ClaimScope, viewpoint qualification, comparison relation, governed next use, or relation needed for inheritance.
A stale source material, source relation, or evidence reference does not always retire the problem; it may require refresh while the problem remains reviewable. A stale problem signal may lead to refresh, retire, archive, abstain or no-change, or a subject-pattern cue for the claim, relation, or boundary that is checked.
Freshness or expiry failure is a current disposition. A stale or unknown-bearing problem card may remain reviewable as a problem-side record, but it does not become P2W-ready unless freshness and unknown handling permit the intended downstream use. A stale problem card does not silently remain usable as P2W input.
When freshness, expiry, or unknown handling fails, choose one of these current dispositions:
- refresh the problem card or its characterization or comparison relation under
G.11,C.16,A.19,C.25, orG.9; - retire or deprecate the problem-side record under the relevant archive, pool, selected-set, or refresh pattern;
- continue only as explicitly governed bounded-risk use under the subject pattern for the claim being made, relation, or boundary.
Unknown-handling fields state whether they permit use, require degraded use, abstention, or sandbox treatment, or make the current problem formulation blocked. No P2W, no change, or abstain-for-now may be a successful next use when the signal is stale, duplicate, already solved, already absorbed, unnecessary, or not currently worth downstream work. Before ProblemCard emits or binds TaskSignature, it checks whether the problem signal is still present and whether prior work has already solved or removed the problem.
Representation and Wording-Use Relation Continuity
C.22.2 names A.6.3.RT, A.6.4, E.17, F.9, E.18, and E.10 only when changed problem formulations, diagrams, functional descriptions, transformation-flow paths, wording, or PathSlice examples carry a current representation, bridge, retargeting, structural-reinterpretation, or wording-use claim. The card may preserve the local cue, reference, or problem-formulation follow-up reason, but it does not prove continuity or use-boundary inheritance by wording similarity.
Framing is not wording repair. A framing change applies when EntityOfConcern, effective ReferenceScheme, ClaimScope, viewpoint qualification, comparison relation, use-boundary inheritance, or honest next use changes. Wording-use repair is current only when wording, diagram, functional description, transformation-flow path, Bridge, retargeting, or another representation change alters the carried problem-side representation, EntityOfConcern, effective ReferenceScheme, ClaimScope, viewpoint qualification, comparison relation, governed next use, or subject-pattern cue. Ordinary wording cleanup triggers no representation-continuity relation and does not block a Thin ProblemCard.
C.22.2 may not treat changed-problem examples as governed relations unless the appropriate accepted FPF relation is named.
Source and P2W Carry-Forward
The source presentation is not compressed into a generic problem-card summary. The following source details become carry-forward constraints for C.22.2 use and for the P2W-facing relation from C.22.2.
This carry-forward preserves detail, not broader scope. C.22.2 remains the problem-side output; P2W uses it with enough problem-side cues and exact receiving-use and Work references to select method families, plans, performed Work, and result measurement without making the card a P2W pattern.
SoTA Decision-Use Source Material
The following external anchors are adopted or adapted only where they change this pattern's local answer by value.
If a C.22.2 use carries a wider external claim than these dispositions, the claim is outside this pattern and requires a separate content decision or demotion to a non-FPF-governed example.
Each FPF-governed SoTA use is recovered as a local test: source idea, FPF invariant, practitioner check, and popular shortcut rejected. A source citation without that local test is not enough to carry pattern use.
Local SoTA-to-action tests:
Rationale
ProblemCard gives the practitioner one compact problem-side record between vague problem talk and downstream P2W. The card is useful because it is light enough for ordinary use and specific enough to show when comparison, characterization, evidence, selection, mathematical-lens use, method, work, gate, autonomy, bridge, representation transition, or refresh requires another FPF pattern.
The card gives the practitioner one thing to write, inspect, and challenge. A practitioner can see whether a problem is ready without first assembling the problem-side record from TaskSignature, Q-bundle, parity report, evidence note, selected-set output, and refresh record. Claims beyond the problem-side record stay with their subject patterns.
The archive and portfolio distinctions remain current when they matter because the card preserves sourceSetRef and names the subject pattern for any current set, archive, or portfolio claim. Changed problem formulations, diagrams, functional descriptions, or transformation-flow path interpretations require the accepted representation or retargeting relations before a local cue or readiness disposition is reused. Current SoTA and first-principles cues matter only when they change fields, relation references, boundaries, or the problem formulation itself.
Problem-Card Use Invariants
Misuse Modes and Repairs
Use-Quality Checks
These checks protect the card's practical use; they do not add fields.
Worked Slices and Anti-Cases
Five-Case Worked Slices
These rows are recognition slices, not complete Thin cards. Before using one, complete the exact Thin contract in C.22.2:2.1; add the relation cues shown here only when they change that card's next use. The compact filled Thin example follows in 20.1a.
Compact P2W-ready Disposition Slice
A support team sees repeated failed hand-offs after a new interface policy. The incoming request says "rewrite the escalation workflow." A conforming ProblemCard first repairs the problem-side record instead of accepting the work-shaped request.
The P2W export is narrow: signal, joint EntityOfConcern, effective ReferenceScheme, ClaimScope, claim family, not-wish or not-preselected-Work reason, improvement check or acceptance probe, and honest next use. In this case it also carries the qualification window, validation boundary, follow-up reason, and subject-pattern cues because the stated next use relies on them. Add freshness, unknown handling, source-set, representation, evidence, or other conditional content only when it is current. If the improvement check or acceptance probe is missing, the card stays reviewable-only or source-finding and cannot claim P2W-ready. If the next user wants evidence sufficiency, a gate decision, Work authorization, or selected method, the card preserves the cue and its direct governor carries that downstream claim.
Card/PFR Cardinality Replay
Every PFR reference below designates a world-side occurrence established under C.22.PFR; no card-side fact supplies its participants, adverse extent, or identity. PFR-InspectionAssignment-17 and later PFR-InspectionAssignment-18 are the two Robot-7 occurrences replayed in C.22.PFR:5.
For the unrelated branch, InspectionReleaseAssignment is a declared U.SystemRoleAssignment species. Occurrence InspectionAssignment-27 has admitted System Robot-8 as holder and local kind InspectorSystemRole as assigned-kind value. It obtains without interruption on [2026-07-13T10:00, 2026-07-13T10:30]; MaintenanceRoles-2026, Maintenance-Scheme-A, and the interval description interpret or describe the assertion but are not extra assignment participants.
Robot8ReleaseCriterionApplicability-4 uses predicate NoInspectorSystemRoleBeforeValidation-v2, maps the occurrence's assigned-kind participant to the adverse nominal coordinate and its holder to Robot-8, and names Robot-8, its release ClaimScope, and [2026-07-13T09:30, 2026-07-13T12:00] as the other applicability participants. Those facts establish PFR-InspectionAssignment-27 on [2026-07-13T10:00, 2026-07-13T10:30] under C.22.PFR.
Anti-Cases
Machine-Assisted Drafting Boundary
Machine-assisted ProblemCard drafting is only a drafting aid. Before the draft is used for P2W or selector-facing work, a practitioner checks the card's local fields and any subject-pattern cues for claims outside C.22.2.
Required practitioner checks for a machine-assisted draft reuse the exact Thin contract:
- problem signal;
- one joint EntityOfConcern, effective ReferenceScheme, and ClaimScope;
- exact claim family;
- reason this is not merely a wish, ticket, slogan, label, or preselected Work request;
- improvement check or acceptance probe; and
- one honest next use.
Check problem-formulation follow-up reason, validation boundary, freshness or expiry, unknown handling, source-set reference, representation or retargeting relation, and outside-pattern cues only when that content is current for the chosen next use. Omit a non-current field; do not invent a value or write unknown merely because the drafting aid exposes that field.
First Practical Entry Aid
This section is a discoverability aid only. It helps a practitioner or assistant find a candidate pattern; it does not prescribe a transition sequence and does not require opening C.22.2 for every problem-sounding text.
These likely practitioner entry phrases point to C.22.2:
- "We have a problem, but it is not yet clear what work should be done."
- "This looks like a ticket, but I am not sure the problem is stated."
- "A signal or anomaly keeps recurring before method selection."
- "We selected this candidate from a front, archive, pool, or selected set, but need to state why it is a problem now."
- "P2W would otherwise use 'implement X' as if it were reviewable problem-side output."
- "There is a symptom, but we do not yet know what to solve."
- "We need to know whether this problem is ready for P2W or should apply another pattern."
Direct-entry cues that are not C.22.2:
- accepted method or work planning: use
A.15; - proof, provenance, reliability, or assurance claim: use
A.10,G.6, orB.3; - local choice among explicit options: use
C.11; useG.5when selector-facing set-result declaration is current; when that result already exists and actual audience availability is current, useE.17for its source-backed publication face and return to source andE.24.PUBfor the publication occurrence and availability; - agent tool-call, gate, or autonomy claim: use
C.24,E.16, orA.21;ProblemCardmay only name the problem-side cue or relation named by value; - ordinary discussion with no downstream receiving use: no
C.22.2use.
First-use Thin-card test:
Given a messy signal, a practitioner can produce a Thin ProblemCard in under one page with the exact core from 2.1: signal; one joint EntityOfConcern, effective ReferenceScheme, and ClaimScope; exact claim family; not-wish or not-preselected-Work reason; improvement check or acceptance probe; and one honest governed next use. That use may be P2W-ready, characterize, compare or parity, search or pool, refresh, retire, abstainOrNoChange, or apply the FPF pattern that defines or constrains the claim, relation, or boundary outside the card.
Entry relation:
The entry relation is local: C.22.2 is introduced under C.22, and C.22 names the ProblemCard relation. The C.22.2 body carries the Problem frame, first-entry phrases, tempting-wrong-pattern boundaries, and first-use Thin-card test needed for ordinary discovery.
Downstream Cue Export
ProblemCard exports problem-side claim content, not authority over downstream use.
The compact export contains:
- problem signal and exact signal reference;
- one joint EntityOfConcern, effective ReferenceScheme, and ClaimScope;
- exact claim family and polarity: actual-PFR assertion, anticipated-condition claim, method-availability or solvability claim, or another named direct claim;
- reason this is not merely a wish, ticket, slogan, label, or preselected Work request;
- improvement check or acceptance probe;
- one honest next use and its disposition: reviewable-only,
P2W-ready,abstainOrNoChange, refresh, retire, archive, or subject-pattern cue; - current qualification window, exact PFR, source-set, A.15.6 composite or component Work, or representation reference only when independently governed and relied on; and
- problem-formulation follow-up reason, validation boundary, freshness condition, and stop only when the receiving use relies on them.
For P2W carry-through, use E.18.1 with the accepted problem-side distinctions. For TaskSignature constitution and assignment, use C.22. For selected-set or search use, apply G.5 only when that relation is current. For intended or performed Work, use A.15 only after its exact object is current; when the question is whether intended Work may enter its boundary, A.15.5 governs WorkEntryReadiness@Context. For evidence, gate, autonomy, or any other claim, apply the direct pattern; the whole card never carries that claim by itself.
Consequences
Benefits
- FPF gains a clear problem-side output for problematization as the input P2W can use.
- P2W uses a typed problem-side record rather than a slogan, ticket-shaped wish, or preselected method.
C.22.2has practical value for FPF when it reduces at least one expensive failure: a wish enters P2W asTaskSignature; a preselected work request is treated as the problem; method selection happens before the problem is reviewable; a problem from a set losessourceSetRef; an indicator is used without a declared indicator-use relation; problem-formulation follow-up reason is cited as proof; a stale problem remains active; scalar readiness replaces set-return; or the problem-formulation follow-up reason is inherited across a changed representation without the governing representation-continuity or wording-use relation.- Current archive, pool, front, shortlist, set-return, parity, refresh, evidence, and
C.29patterns are reused instead of duplicated. - The positive use of mathematical and first-principles thinking is preserved: it can find missing structure, not only check already-written mathematics.
- Characterization and parity are no longer optional background when they are prerequisites for problem reviewability.
- Representation-change relations are handled through named relation references rather than local proof inside the problem card.
Costs of Use
- A
ProblemCardadds a small writing step before P2W. The cost is justified only when the signal is not yet reviewable before downstream use. - The practitioner keeps the card small: preserve the split between problem, task, method, work, and result; keep
TaskSignatureminimal; and add conditional fields only when their relation is current. - For problems emitted from archives, pools, fronts, selected sets, or portfolios, the practitioner preserves
sourceSetRefor the set-source relation without turning the card into a portfolio, archive, selected-set, or work-planning carrier. - External or source-local terms may guide recognition only when they change a concrete boundary, field, relation, or validation requirement. Otherwise they remain examples or local cues.
Relations
- Builds on:
E.2,E.9,E.10,C.2.P,A.6.P,C.16.Q,C.16,A.19,C.22,C.25,C.29,G.5,G.9,A.6.3.RT, andA.6.4. - Coordinates with:
C.11,C.18,C.19,C.22.1,C.22.PFR,A.15,A.15.5,A.21,E.16,G.6,G.11,A.10,B.3,E.17,E.17.ID.CR,A.6.3,F.9,E.18,E.18.1,C.32.P2S, andE.10.MOVE. UseC.22.PFRwhen actual Problem obtaining or identity is current. UseC.32.P2Sonly when a problem-side record exposes architecture pressure that must continue into selected structures, candidate synthesis, decision, realization, actual-structure feedback, or refresh.
C.22.2:End
MethodFamily Evidence & Maturity (Method‑SoS‑LOG)
LOG (logic) for deductive shells for admissibility First use expansion: SoS‑LOG = Science‑of‑Science LOG (LEX short‑form discipline applied).
Registration boundary. A MethodFamily is registered by one exact G.5 registry row and registry edition. That record names the family, its admitted members or grouping basis, and intended selector use. It does not create a U.BoundedContext or supply evidence, claim scope, validity, or a decision result.
Builds on. G.5 (MethodFamily registry/selector), G.4 (Acceptance & EvidenceProfiles), C.22 (TaskSignature S2), C.18 NQD‑CAL (QD/illumination), C.19 E/E‑LOG (emitters/policies), B.3 (Assurance lanes & R_eff), A.10 (Evidence Graph Ref), E.10 (LEX), E.18 (GateCrossing / CrossingBundle visibility). Coordinates with. G.6 (EvidenceGraph), G.8 (LOG bundling), G.9 (Parity), G.11 (Refresh).
Problem frame
Families of methods compete inside a CG‑Frame. The selector (G.5) must admit, degrade, or abstain per family without universal scores, using typed problem descriptors and auditable evidence. Maturity of a family (how far it has travelled from “clever idea” to “run‑safe”) must be visible to LOG rules yet separate from thresholds (which live only in AcceptanceClauses, G.4).
Problem
Unstructured “readiness” stories and undisciplined evidence lead to:
- (i) Illicit scalarisation across mixed scale types,
- (ii) Prose‑only gating that a dispatcher cannot execute,
- (iii) reuse after the family, evidence profile, claim scope, qualification window, or comparison basis changed, or reliance on an unstated source-local, kind, or plane relation, and
- (iv) Immature families leaking into production.
We need a notation‑independent LOG layer that turns TaskSignature (S2) + EvidenceProfiles into executable rules for admit / degrade / abstain, routing any CL penalties to
R_effonly (never mutating F/G).
Forces
- Pluralism vs. dispatchability. Competing Traditions expose different invariants; selection must compare without semantic flattening.
- Maturity vs. opportunity. Open‑ended exploration (E/E‑LOG) must coexist with run‑safe exploitation; immature ≠ forbidden → provide safe degrade paths.
- Unknowns (tri‑state). Missing or
unknownS2 fields must propagate explicitly to degrade/abstain/sandbox; no silent coercions. - Lexical discipline. Head‑anchoring, EntityOfConcern / Description / specification-use separation, Bridge hygiene; no tool names in Core.
Solution — Method‑SoS‑LOG: deductive shells over Eligibility & Evidence
Objects & heads (LEX/I‑D‑S)
Tech heads; Plain twins are published via UTS.
MethodFamily (registered in G.5) carries Eligibility and artefact identity; MaturityCard (this pattern) carries evidence‑aware maturity; SoS‑LOG.Rule (this pattern) is an executable rule schema that returns one of {Admit | Degrade(mode) | Abstain} for a (TaskSignature, MethodFamily) pair. Descriptions live as …Description; when harnessed they become …Spec.
Rule schema (normative)
For each MethodFamily f, author an executable rule set:
with the following branch obligations:
R0 — CG-Spec gate (precondition). For the exact G.5 registry row and MethodFamily, verify the cited CG-Spec.MinimalEvidence and EvidenceProfile for every CHR characteristic used by the family's acceptance clauses and flows, under the declared claim scope and selected slices, qualification window, and intended selector use. Failure ⇒ Abstain with reasons. Publish the consulted CG-Spec, EvidenceProfile, registry, and policy editions.
Rationale: selector legality requires the CG‑Spec gate to be explicit, not implicit in prose. Publish associated ReferencePlane notes alongside the consulted ids.
R0.QD — QD/OEE pre‑gates (if applicable). If S2 declares BehaviorSpaceRef/ArchiveConfig/EmitterPolicyRef or PortfolioMode=Archive, verify:
(i) CharacteristicSpaceRef characteristics are CHR‑typed, d≥2, ReferencePlane per characteristic declared;
(ii) ArchiveConfig is lawful (topology, resolution, K>0, InsertionPolicyRef, DistanceDef with edition id and declared metric/pseudometric status);
(iii) EmitterPolicyRef present (with edition id);
(iv) DominanceRegime present; if absent, default= ParetoOnly.
Failure of any ⇒ Abstain with reasons.
R1 — Admit. Admit IFF
(a) S2 satisfies Eligibility predicates of f (tri‑state aware),
(b) the exact EvidenceProfile minima referenced by Acceptance/Flows for f are met for the declared claim scope and selected slices, qualification window, and intended selector use (post R0),
(c) all relevant CAL.AcceptanceClauses (G.4) evaluate to true under lawful CHR comparisons,
(d) any maturity gating (e.g., a floor on Maturity rungs) is expressed as an AcceptanceClause and referenced here by id (no thresholds inside LOG).
LOG never sets thresholds; it only executes and cites Acceptance verdicts.
R2 — Degrade. If (a) holds but (b) or (c) is partially satisfied or unknown, return Degrade(mode) where mode ∈ {scope-narrow | sandbox | probe-only}. Record the exact S2 unknowns or evidence minima, narrowed claim scope or execution mode, qualification window, governing policy edition, and result. LOG-Degrade never changes CHR scales or planes.
Note (CAL vs LOG). CAL‑level degrade.order (fall‑back to order‑only comparisons) is governed by G.4/CG‑Spec and is not a LOG mode. SoS‑LOG never overrides CAL outcomes; a LOG branch only narrows Scope(G) or execution mode (e.g., sandbox, probe‑only), it does not alter CHR scales or admissible orders.
probe‑only MUST cite an E/E‑LOG policy id (exploration budget) and Acceptance‑bound guards.
R3 — Abstain. If S2 violates Eligibility or R0 fails, return Abstain with the failed rule, policy edition, evidence profile, claim scope, qualification window, and reasons. Abstain is mandatory for illegal CHR operations and when a conclusion depends on an F.9 Bridge, kind relation, or plane relation that has not been established.
R4 — Relation and loss routing. Cite an F.9 Bridge, kind relation, or plane relation only when the admission decision actually relies on that obtaining relation. Record its participants, direction, what meaning is preserved and what is lost, receiving use, and applicable policy edition. Any supported loss reduces R_eff only; F and G remain unchanged. A changed registry row, evidence profile, claim scope, qualification window, or intended use is not by itself a crossing.
R5 — Proof hooks. Every branch MUST cite Evidence Graph Ref (A.10), lane tags (TA/VA/LA), freshness windows, and (if bridged) Bridge ids + loss notes; the decision is SCR‑visible. When G.6 EvidenceGraph is present, also publish EvidenceGraph path id(s) for the branch (admit/degrade/abstain). No self‑evidence.
R6 — QD archive / PortfolioMode semantics (if applicable). If PortfolioMode=Archive, Admit may return a QD archive (per ArchiveConfig) instead of only a Pareto set. Unless CAL authorises DominanceRegime=ParetoPlusIllumination (policy‑id recorded in SCR), IlluminationSummary is a report‑only telemetry summary and any coverage/regret are telemetry metrics (reported) that do not affect dominance.
R7 — GeneratorFamily branches (open‑ended). If S2 includes GeneratorIntent, SoS‑LOG MUST:
(i) verify EnvironmentValidityRegion is declared and lawful;
(ii) verify TransferRulesRef exists; if unknown ⇒ Degrade(scope‑narrow) or Abstain per family policy;
(iii) treat the selection surface as pairs {environment, method}; publish coverage/regret and IlluminationSummary as report‑only telemetry (IlluminationSummary = telemetry summary; coverage/regret = telemetry metrics); dominance participation per R6.
R8 — Telemetry & Refresh hooks. On any illumination increase or archive change, publish edition increments for CharacteristicSpaceRef/DistanceDefRef and the policy‑id (Emitter/Acceptance) that caused the change; expose PathSliceId for refresh/decay in SCR.
Aphorism. “Admit on admissibility and sufficiency; degrade on uncertainty; abstain on inadmissibility.”
Maturity ladder (poset, not a scalar; Description, not Spec)
Publish one editioned MaturityCardDescription for the exact evaluated MethodFamily, G.5 registry edition, evidence profile, claim scope and selected slices, qualification window, and intended admission use (UTS enum ids; scale kind = ordinal; reference plane declared). Do not embed thresholds here; an admission floor remains a G.4 AcceptanceClause cited by R1.
- L0 — Anecdotal. Claims exist; lanes sparse; examples ad‑hoc.
- L1 — Worked‑Examples. Multiple worked examples with lane tags and Scope slices declared; no replication yet.
- L2 — Replicated. Independent replications identify their distinct bearers or operating conditions and declare the claim scope and selected slices, source and method editions, and qualification windows used; lane separation is observed and decay windows are explicit.
- L3 — Benchmark‑Severe. Repeated wins or parity on community baselines or severe tests; cross‑Tradition bridges declared with loss notes.
Optional rung (for QD/OEE‑heavy families; ordinal, closed enum):
- L4 — QD‑Hardened. Archive stability under declared InsertionPolicy/DistanceDef editions; reproducible IlluminationSummary improvements under controlled budgets; OEE generators pass EnvironmentValidityRegion severe tests.
Norms.
M1. The ladder is lane‑aware (TA/VA/LA) and freshness‑aware; it is not a global numeric score. Declare Scale kind=ordinal and the closed enumeration of rungs; register the enum at UTS (twin labels; editioned).
M2. Transitions MUST be justified by EvidenceGraph paths (once G.6 is available) and UTS publication; missing anchors ⇒ no advance.
M3. Any maturity floor used for admission—for example, a run-critical selector use requiring at least L2—MUST be authored as a CAL.AcceptanceClause and cited by R1 with its policy edition, claim scope, qualification window, and verdict; SoS-LOG does not embed thresholds.
M4. Declare the MaturityCard reference plane. If an admission decision relies on a relation to another plane, cite that exact obtaining plane relation, its direction and loss, and the applicable policy edition; supported loss affects R_eff only.
Rationale note. Treating maturity as a poset aligns with B.3’s lane calculus and avoids scalarisation across ordinal/ratio scales; assurance penalties remain on R, never F/G.
Unknowns & Shift classes (tri‑state discipline)
U1. (LEX). Enumerations for Degrade(mode) and Maturity rungs MUST be declared as closed value sets and registered at UTS (twin labels). Lexical SD (E.10) applies.
U2. Every S2 field is tri‑state; unknown MUST map to a branch (Degrade or Abstain) declared on the family (no coercions). Each branch publishes a branch‑id and (where used) a mode from a closed enum registered at UTS (LEX enum clarity).
U3. ShiftClass semantics follow C.22. If ShiftClass ∈ {covariate‑shift, concept‑drift, adversarial} or unknown, default outcome is Degrade(scope‑narrow) unless a CAL.AcceptanceClause explicitly guards the regime.
Publication & wiring
W1. For each evaluated MethodFamily, publish an editioned MaturityCardDescription naming the registry edition, evidence profile, claim scope, qualification window, reference plane, and intended admission use; register the SoS-LOG rule ids. RSCR tests cover Admit, Degrade, Abstain, and unknown paths. Relation and loss-policy ids appear only where a branch actually relies on them.
W2. Admissibility Ledger. Publish an editioned AdmissibilityLedger: each selector-facing row names the exact MethodFamilyId, G.5 registry edition, RuleId and rule edition, MaturityRung, EvidenceProfile, claim scope, qualification window, BranchIds, AcceptanceClause and policy ids, decision result, evidence paths, DominanceRegime, PortfolioMode, and any obtaining relation and loss-policy ids actually used. UTS registers the row vocabulary; the ledger does not create validity or a Context object.
W3. Strategy composition. Strategy is a G.5 composition under E/E-LOG unless a separate E.24.UK admission proves durable kindhood for a different governed object.
W4. Selector (G.5) consumes these rules; results appear in the Dispatcher Report with reasons in/out and cited anchors/bridges.
Archetypal Grounding (Tell–Show–Show)
(Plain register for pedagogy; Core remains notation‑independent per E.10/E.8.)
Show‑1 - Continuous dynamics (ODE task).
S2 excerpt. DataShape=ODE; stiff?=unknown; Size≈10^3; Objective={↓error@ratio, ↑throughput@ratio}; Constraints={safety_gate@ordinal}; Jacobian_sparsity=high; Missingness=MAR.
Families. Implicit‑BDF vs Explicit‑RK vs Symplectic.
Rules.
Implicit‑BDF: Eligibility toleratesstiff?=unknownifJacobian_sparsity=high(guarded precondition); MaturityCard=L3(replicated & benchmarked). Outcome:Admit.Explicit‑RK: requiresstiff?=false; withunknown⇒Degrade(sandbox)(probe).Symplectic: eligible only whenHamiltonian=true; here ⇒Abstain. Didactic anchor. This mirrors C.22’s typed‑signature discipline and CHR legality (no ordinal means; unit alignment for ratio).
Contemporary ecosystem examples of these families (post‑2015) are organised in DifferentialEquations.jl, which exposes multiple solver families under one call surface—precisely the pattern G.5 expects. (Journal of Open Research Software)
Show‑2 - Planning/scheduling (MIP task).
S2 excerpt. DataShape=MIP; NoiseModel=deterministic; Objective={↓cost@ratio, ↑service_level@ordinal}; Size≈10^5 vars; convex_relaxation=available.
Families. MILP (branch‑and‑bound), Constraint‑Programming, Heuristic meta‑search.
Rules.
MILP: Eligibility requiresconvex_relaxation=available; the cited L3 MaturityCard edition names the registered family, evidence profile, benchmark basis, claim scope, qualification window, and intended selector use ⇒Admit.Constraint‑Programming: MaturityCard=L2; Acceptance demandsservice_level≥B(ordinal predicate). WithBmet but baseline parity unknown ⇒Degrade(scope‑narrow).Heuristic meta‑search: MaturityCard=L1⇒Degrade(sandbox)orAbstaindepending on RSCR parity policy. Didactic anchor. Selector returns a Pareto set (no cross‑ordinal weighting), as required by G.5.
Contemporary “single call / many solvers” packaging that motivates MethodFamily rows is exemplified by JuMP (2017–2022), which cleanly separates model description from solver choice. (Miles Lubin)
- DifferentialEquations.jl illustrates family‑based solver packaging (multi‑method under one interface), 2017–2024 ecosystem. (Journal of Open Research Software)
- JuMP illustrates model/solver separation and registry‑like selection (2021–2022 papers, site). (Miles Lubin)
- Science of Science review (2018) supports the emphasis on replication/benchmarks in maturity assessment. (Science)
Show‑3 - QD archive (policy search).
S2 excerpt. PortfolioMode=Archive; CharacteristicSpaceRef(d=2); ArchiveConfig(CVT, res=1k cells, K=1, DistanceDefRef.edition=v2, InsertionPolicyRef=dyn‑elite); EmitterPolicyRef=v3; DominanceRegime=ParetoOnly.
Rules. Admit returns an archive; illumination reported; changes to DistanceDef/Emitter editioned in SCR; dominance remains ParetoOnly.
Show‑4 - Open‑ended GeneratorFamily (POET‑class).
S2 excerpt. GeneratorIntent{GeneratorFamilyRef=GF‑01, EnvironmentValidityRegion=EVR‑A, TransferRulesRef=TR‑A, CoverageMetric=…}; PortfolioMode=Archive.
Rules. Admit yields declared sets over {environment, method}; Degrade(scope‑narrow) if TransferRules=unknown; telemetry publishes coverage/regret and IlluminationSummary with edition/policy‑id on improvements.
Bias‑Annotation
Principle‑taxonomy lenses. Universality (trans‑discipline), Didactic primacy (Tell–Show–Show), Open‑ended evolution (refresh‑ready), Lexical firewall (no tool names in Core), Notation independence. Limits: Worked examples reference widely‑used ecosystems in Plain register only.
Conformance Checklist (normative)
Consequences
- Explainable admission. Every Admit/Degrade/Abstain is backed by anchored evidence and explicit unknown handling (selector reports are SCR‑linked).
- Run‑safe pluralism. Multiple families can co‑exist with policy‑governed exploration (E/E‑LOG) and maturity‑aware gating.
- Portable governance. Bridge hygiene and CL routing make cross‑Tradition reuse deliberate and costed (penalties to R only).
Rationale
The ladder and LOG shells align with FPF’s Assurance calculus: F (form) is governed by artefact kind, G (scope) by USM slices, and R (reliability) accumulates via WLNK then Φ(CL) penalties. Treating maturity as evidence‑typed rungs—rather than a “score”—avoids illegal arithmetic and lets DesignRunTag values remain separate via DesignRunTag discipline (A.4) and explicit GateCrossings. This mirrors contemporary science‑of‑science insights: replication, benchmarking, and field health indicators are the currency of maturity, not anecdote. (Science)
Relations
Builds on: G.5 (selector consumes these rules), G.4 (Acceptance & EvidenceProfiles), C.22 (S2 typing), C.18 NQD‑CAL, C.19 E/E‑LOG, B.3 (Assurance tuple & WLNK). Publishes to: UTS (MaturityCards, rule ids), SCR/RSCR (branch coverage; parity hooks). Constrains: G.8 (LOG Bundling must cite MaturityCards), G.9 (parity harness draws baselines per rung), G.11 (refresh windows per rung & decay), G.5 (Open‑Ended Family mode for GeneratorFamily). Outcome. The pattern introduces new content (LOG shells + maturity poset + degrade modes + publication Standard) and does not duplicate CG‑Spec legality rules, CHR guard‑macros, or CAL acceptance mechanics; it integrates them into admissibility logic for MethodFamilies.
C.23:End
Agentic Tool-Use and Call Planning (C.Agent-Tools-CAL)
Type: Calculus (C) Status: Stable Normativity: Normative
Plain-name. Agentic tool-use and call planning.
Intent. Help a practitioner turn an already fixed action or option into a budgeted call plan, then revise that plan or return a bounded checkpoint without confusing planning with selection or execution.
Instantiates and refines Pillars. E.2 P-3 Scalable Formality, P-7 Pragmatic Utility, P-10 Open-Ended Evolution, P-11 SoTA Alignment, and C.19.1 Bitter-Lesson Preference when a real scale comparison is current.
Depends on. A.15 and its planning and Work patterns for Methods, descriptions, plans, performed Work, and attribution; A.15.7 for a situation-responsive next-action decision; C.11 for a fixed choice among a current OptionSet; C.2.1 when the relied-on decision or checkpoint needs a persistent episteme; C.18 for candidate generation; C.19 for live-pool policy; C.19.1 for a scale-based comparison or waiver; C.16 for measured comparison inputs; G.6 for call-trace representation; and B.3 only when a named assurance use needs one bounded assurance result.
Coordinates with. U.PromiseContent for service acceptance conditions, C.28 when a planned call is intended to support a causal use, and E.17/E.24.PUB when an already obtained result is being published or made available.
Use this when
Use A.15.7 first when ongoing Work still needs the next action to be chosen from current facts within a domain Method. Enter C.24 only after that action is fixed and tool or service calls must be planned. A call plan is neither the situation-responsive decision nor proof that the chosen action was performed.
Use C.24 when a decision has already fixed the action or option and the practical question is now:
- which admitted Methods to call, in what order;
- which time, compute, cost, and risk budget to reserve;
- what stops or replans the route; and
- whether the useful output is a
CallPlanor aCheckpointReturn.
Do not use it to generate candidates, keep a live pool, choose among unresolved options, execute calls, or score completed Work.
What goes wrong if missed
- a route is scheduled by an opaque heuristic, so nobody can see which budget is being burned or what should stop it;
- unresolved choice or pool-policy work is smuggled into a plan;
- a route description is mistaken for a Method, a plan for performed Work, or a successful probe for committed rollout; and
- replanning loses the decision that made the route admissible in the first place.
What this buys
- one small, tool-neutral plan that cites the accepted decision basis;
- visible budgets, stop conditions, and replan triggers before calls are made;
- one replayable call-trace reference after Work occurs; and
- one bounded checkpoint when more route probing is justified but commitment is not.
Primary working object. One ATC.CallPlan : U.WorkPlan. Each step selects a U.Method. A route description may help locate or constrain that Method, but remains a separate U.MethodDescription. Actual calls are dated U.Work and remain outside this planning result.
First useful move. Say whether the fixed action came from A.15.7 or C.11 and cite exactly one corresponding reference in decisionBasis. Then write the ordered Method refs, budget, stop or replan condition, and next planned action. Add route-description refs only where the route cannot be understood without them.
Not this pattern when. Use C.11 while fixed-option choice is unresolved, C.19 while treatment of a live pool is unresolved, G.5 when the current task is selector-facing result declaration, A.15.5 for work-entry readiness, and A.15.1 when the question is what Work actually occurred or which Method it enacted.
First-minute questions
- Which accepted A.15.7 decision or C.11
ChoiceResultfixed the action or option now being planned? - Does every planned step name an admitted Method, rather than only a vendor route or endpoint label?
- Which budget is current: a still-upstream probe budget or an enactment/call budget?
- What event stops or replans the route?
- Is the useful output a plan, a checkpoint, or a return to a neighbouring pattern?
First output
The first useful output is one of these:
nextPlannedAction and recommendedNextAction are local fields, not claims that Work has occurred. Exactly one decision-basis reference is present. Add one of the branch-specific refs in C.24:4.4 only when that constraint still affects the plan. A plan with no current policy branch needs no policy placeholder. If neither output can cite its accepted decision basis and state what happens next, the C.24 work is unfinished.
If the A.15.7 decision changes, is withdrawn, or no longer fixes the action, reopen the plan and return to A.15.7. If the C.11 ChoiceResult changes or no longer says choose now, return to C.11. A changed live-pool branch returns separately to C.19. Do not revise the call plan as though its decision basis were still settled.
Problem frame
Tool-using Systems may plan across web services, local programs, instruments, robots, or human-operated routes. The implementation may be an LLM agent, a search system, a conventional planner, or a fixed program. The planning problem is the same: turn a fixed action or option into an ordered and bounded route without hiding route grounding, budget, or stop logic.
A local system-role kind or assignment is recorded only when that separate fact matters. When planning, revision, or a call is claimed as precise performed Work, recover each exact actual performer through A.13 and let A.15.1 independently admit the dated Work from its performer, Method, interval, and containment facts. Add the exact A.2.1 assignment reference and F.6 only when the plan or receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; F.6 identifies neither assignment nor performer, and missing or failed F.6 leaves the Work intact.
Problem
We need a tool-neutral way to produce or revise one call plan under explicit budgets and policy while keeping Method, route description, plan, performed Work, service promise, trace representation, the decision basis that fixed the action, and any assurance result distinct.
Forces
Solution
Local objects and boundaries
ATC.CallRouteDescriptionis aU.MethodDescriptionfor one callable route. When it carries vendor-local route data, it states the vendor or source scheme, exact scheme or API edition, intended use, and selected Method ref before any access details, inputs, outputs, or route limits. It is not the Method or anything executed.ATC.CallPlanis aU.WorkPlanfor intended calls. Its steps select Methods and may cite route descriptions.ATC.CheckpointReturnis a C.2.1 result episteme stating what was tested, what budget was burned, and what route action is recommended next. It is not the tested Work.ATC.CallGraphRefcites the applicableG.6trace representation over actual call Work. The representation records or points to facts; it creates none of them.
decisionBasis contains exactly one of two references. situationResponsiveDecisionEpistemeRef refers to an episteme identified under C.2.1 because this plan relies on an A.15.7 decision; the episteme states the selected action, deciding System, intended performer, action-changing fact, relevant Method limit, and stop or feedback condition. fixedOptionChoiceResultRef refers to a C.11 ChoiceResult whose result is choose now. The first is not a ChoiceResult, and the second does not become a situation-responsive decision by being consumed here.
There is no catch-all ATC.PolicyRef. When a constraint branch is current, cite its actual object: C.19 PoolPolicyResult or EmitterPolicy, a C.19.1 probe, comparison, local-policy, or waiver result, or a domain constraint whose kind and defining pattern are named. Time, compute, cost, risk, stop, and replan ceilings remain fields of this plan.
State the distinction among Method, route description, plan, and Work here and apply it throughout. Repeat a qualifier only when it changes identity, action, stop, or reliance at that locus.
Owned planning operations
C.24 owns only planning and replanning:
[A.3.1](/generated/patterns/A.3.1) supplies Method admission. The decision basis fixes the action or option being planned; it does not admit the Methods chosen for plan steps. An A.15.7 basis keeps the selected action, deciding System, intended performer, action-changing fact, relevant domain-Method limit, and stop or feedback condition. A C.11 basis is a ChoiceResult whose lawful result is choose now; probe again, reject current set, and reroute do not fix an action for C.24. C.18 may supply generated candidate or front material, and C.19 may supply a live-pool treatment that informed the decision; neither record admits a Method. Comparison comes from the selected evaluation Method and, when scale preference is claimed, [C.19.1](/generated/patterns/C.19.1). Actual execution, observations, and provenance rows come from dated Work and [G.6](/generated/patterns/G.6). C.24 only constrains what the plan or checkpoint must retain for those later uses.
Bounded scout or probe cycle
When the accepted decision basis permits enactment planning but the usable route is still unfamiliar, the admitted System may perform a bounded scout pass and return a CheckpointReturn.
If another probe could still change which option survives the OptionSet, the budget remains a C.11 probe budget and planning returns there. If changed live facts or domain-Method limits could change an A.15.7 action, return there instead. If the action or option remains fixed and only route shape or rollout order is uncertain, the probe uses enactment budget and its checkpoint belongs here.
A successful probe is not a commitment. Commitment needs the named commitTrigger, enough residual budget, and any separately required safety or assurance condition.
Planning laws
ATC-1 — Plan the call, not the app. A plan step selects a Method. A route description, endpoint, service promise, trace row, or response does not become that Method or an actual call.
ATC-2 — Use the actual C.19.1 branch. Start with C.19.1's scale-claim probe. Consume its actual first result: no scale claim yet, local analogy or policy, bounded scale comparison, or full Scale-Audit selected. Only the latter two open comparison or audit work. A completed comparison may then warrant a bounded preference or no scale-based preference. Keep a BLP-waiver separate: it is used only when a declared generality preference would otherwise decide the use, and it records rationale, the admitted review System, the direct waiver-review responsibility or missing governor, and expiry or review. If comparable evidence is absent, stop the empirical preference; do not invent a slope vector or treat a waiver as evidence.
ATC-3 — Make budgets and harm limits visible. A CallPlan states its planned ceilings. A CheckpointReturn or Work-side record states actual burn. The admitted System stops or replans when a named ceiling or safety condition is breached.
ATC-4 — Keep live-pool exploration declared. Cite a C.19 PoolPolicyResult only while treatment of that still-live pool constrains this plan. Cite its exact EmitterPolicy only when the plan actually uses that profile; then record explore_share, including 0 when the current profile explicitly plans none. Do not fabricate either ref after the fixed action or option has made pool treatment irrelevant, and do not silently turn illumination or novelty telemetry into a decision criterion.
ATC-5 — Preserve replay after execution. Each actual call is recovered as dated Work with its performer, enacted Method, interval, containing system when material, plan ref, actual budget delta, inputs and outputs subject to privacy, and any route-description edition used. Cite the applicable G.6 trace representation. The plan and trace do not establish these facts by themselves.
ATC-6 — Add assurance only for a named use. When a planning or rollout decision depends on assurance, name the target claim and use, then cite the B.3 result with its basis, disposition, limits, and reopen condition. No policy label or confidence level substitutes for that result.
ATC-7 — Bind vendor routes to the selected Method. Vendor-specific tokens belong in an edition-pinned ATC.CallRouteDescription that recovers the vendor or source scheme, exact scheme or API edition, intended use, and selected Method ref. Access details, inputs, outputs, and limits may follow. An arbitrary profile, executable adapter, or F.9 Bridge does not satisfy this binding. When executable adaptation is current, identify the Method, MethodDescription, System, and performed Work through their direct patterns. Cite an F.9 Bridge only when its relation independently obtains between two local meanings.
Policy and comparison branches
Add only the branch that still constrains this plan:
Each comparison tolerance names its characteristic, bearer, scale, evidence basis, and window. Graduation, rollout, or widening uses a concrete condition defined by the cited result or direct domain pattern. Plan-local ceilings and stop conditions need no policy object. If another domain constraint is current, give its field the actual result-kind name and cite its defining pattern; do not put it in a catch-all constraint ref. When a condition relies on assurance, cite the exact B.3 result and its supported scope; no universal assurance level is inherited from C.19.
Causal action-use field
Add the causal field only when the planned calls are intended to observe, intervene, collect counterfactual-rung evidence, simulate for a causal claim, condition a counterfactual policy, or evaluate a policy causally:
The field states the planned causal use and any support already consumed. It does not estimate an effect, prove identification, certify fairness, or turn simulation output into realized counterfactual evidence. Use [C.28](/generated/patterns/C.28) for those support questions.
Public quick card
Record:
- exactly one decision-basis reference—an A.15.7 decision episteme or a C.11
choose nowChoiceResult—plus the objective and ordered Method refs; - route-description refs only when needed, with their source scheme, exact edition, intended use, and selected Method binding;
- dependencies or safe parallelism only when they change the route;
- time, compute, cost, and risk budgets plus stop and replan conditions;
- next planned action; and
- an exact C.19 or C.19.1 result, B.3 assurance result, causal-use result, provenance ref, or named domain-constraint result only when that branch is current.
This is enough for an ordinary plan. Do not fill the heavier branches merely to make the record look complete.
Closure and worked cases
Close as a CallPlan when route order and budgeted enactment are the current question. Close as a CheckpointReturn when one bounded route probe remains justified. Return to A.15.7 or C.11 when the corresponding decision basis reopens; return to the applicable neighboring pattern when pool treatment, selector declaration, readiness, execution, or publication becomes the current question.
A.15.7 decision into a known route.
During ongoing repository-repair Work, changed source facts make produce_patch_and_verify the next action under the current repair Method. Using the steering Method in A.15.7, the responsible maintainer makes that decision. The retained decision names the repair agent as intended performer, the changed-source fact, and test failure as the stop and feedback condition. Because the call plan relies on the decision later, the team retains it in one episteme identified under C.2.1. The episteme describes the situation-responsive decision; it is not a C.11 ChoiceResult.
The plan claims no call occurred. If the first call is performed, recover its dated Work, performer, assignment where current, Method, interval, plan ref, and trace representation through the direct patterns.
Unfamiliar route.
Two vendor routes with one token. Vendor A and Vendor B both publish a route called search. vendor_a_search_v2 states scheme VendorA API, edition 2026-07, intended use repository text search, and selected Method RepositoryTextSearchMethod_3. vendor_b_search_v5 states scheme VendorB agent tools, edition 2026-08, intended use web source retrieval, and selected Method WebSourceRetrievalMethod_8. The shared token identifies neither binding; the description fields do. An executable adapter, if used, remains a separate Method, and its execution remains separate Work.
Scale comparison, when current. The cheap C.19.1 probe for BatchSearchMethod_3 and IndexedSearchMethod_6 returns bounded scale comparison for the same repository-search task and 10k–100k files window. The comparison then uses elapsed time and missed-match rate from repo_search_benchmark_12, including uncertainty and cost limits, and warrants a preference for IndexedSearchMethod_6 only inside that window. If one Method is evidenced only on small text files and the other only on large mixed repositories, the comparison returns no scale-based preference. A project may separately cite a local policy or BLP-waiver; neither changes the empirical result.
Near misses. A route label with no recovered Method remains probe material. A plan with no Work is still intent. A trace row does not prove performer, assignment, Method, or service acceptance. A successful probe without a commit trigger is not rollout.
Transfer examples. The same result shape works for research assistance, program repair, and lab automation. The Methods and safety conditions differ; the plan/checkpoint boundary does not.
Bias-Annotation
Keep notation and vendors out of the conceptual contract. Do not average unlike scales. Do not let a route description, plan, trace, response, or confidence label stand in for a Method, performed Work, evidence result, or assurance result.
Conformance Checklist
- Every result cites exactly one accepted decision basis: the A.15.7 decision episteme or the C.11
ChoiceResultthat made planning current. - Every planned step names an A.3.1-admitted Method that realizes or supports the fixed action. The decision basis fixes the action or option; selecting it does not establish Method identity. Route-description refs remain separate and optional.
- The plan records time, compute, cost, and risk ceilings plus stop or replan conditions.
- C.18 candidates or front material and C.19 live-pool treatment may inform the decision basis but do not admit Methods; C.24 owns only planning and replanning results.
- A scale branch first cites one actual C.19.1 probe result, then any selected comparison or Scale-Audit result; a
BLP-waiverremains separate from evidence. - Every vendor-bound
ATC.CallRouteDescriptionidentifies source scheme, exact edition, intended use, and selected Method; an arbitrary profile, adapter, or Bridge cannot substitute. - Each current policy or constraint ref resolves to its actual C.19, C.19.1, B.3, or domain-defined object; a plan with no such branch remains valid.
- A
CheckpointReturnstates tested Methods, evidence, burned and residual budget, next action, and commit trigger. - Actual call claims retain dated Work, performer, Method, interval, plan, budget delta, and G.6 trace refs; the admitted System performs and records the Work.
- A causal action-use branch uses the current C.28 question, support-component, and support-result contract and grants no downstream authority.
- The ordinary quick path remains readable without ontology or assurance apparatus.
Common Anti-Patterns and How to Avoid Them
- Planning the whole tool lifecycle. Keep candidate generation, selection, execution, scoring, and publication outside C.24.
- Route description as Method. Recover the Method or keep the route in probe state.
- Plan as execution. Put actual burn and call facts in Work-side results and the trace.
- BLP slogan as comparison. Use C.19.1's probe and any selected comparison; keep a waiver separate or return no scale claim or no scale-based preference.
- Catch-all policy or profile ref. Cite the actual PoolPolicyResult, EmitterPolicy, C.19.1 result, B.3 result, or domain-defined constraint, or omit the branch.
- Confidence threshold as assurance. Use a direct condition and cite B.3 only for a named assurance use.
- Executable adaptation by implication. Store the binding in a route description; identify any executable adaptation independently.
- Successful probe as commitment. Require a checkpoint with a commit trigger.
Consequences
Tool use becomes inspectable before execution: the result shows which accepted decision fixed the action or option, which Methods are planned, what budget is reserved, and what changes the route. Identical vendor tokens remain distinguishable by source scheme, edition, intended use, and selected Method. The cost is explicit Method grounding and branch-specific constraint refs. Heavy assurance, causal, or scale-comparison records appear only when their use justifies them.
Rationale and current practice
Qualification window. This comparison was reviewed through 2026-08-21. Reopen it when a later result changes the relative value of explicit planning, route grounding, active information gathering, checkpoint use and replanning, multidimensional evaluation, or long-horizon budget and dependency handling for the declared use.
This set is non-dominated for C.24's declared use because it keeps the smallest common planning contract while exposing the failure dimensions that later work shows can move independently. Remove a field when it changes no route, stop, reliance, or replay; reopen when a new contribution changes that trade-off rather than merely adding another benchmark.
Relations
A.3.1supplies admitted Method identity; neither decision branch admits a Method merely by selecting an action.- The steering Method in
A.15.7is used to reach the situation-responsive decision cited throughsituationResponsiveDecisionEpistemeRef; when this plan relies on the decision, its episteme has the identity conditions defined in C.2.1. - A C.11
ChoiceResultwhose result ischoose nowis cited throughfixedOptionChoiceResultRef. C.18supplies generated candidate or front material, andC.19suppliesPoolPolicyResultorEmitterPolicyonly when live-pool treatment still constrains the plan. Neither admits a Method.C.19.1supplies the scale-claim probe, any selected comparison or Scale-Audit result, and any separate local policy orBLP-waiver; C.24 invents none of them.A.15,A.15.1,A.15.2,A.2.1, andF.6keep Method, description, plan, Work, performer, and attribution distinct.G.6supplies the trace representation cited byATC.CallGraphRef.B.3supplies one bounded assurance result only when a named assurance use is current.C.28supplies causal-use support when the plan is used for causal evidence, intervention, policy, fairness, or counterfactual work.C.27evaluates temporal claims about speed, narrowing, recovery, or stop/replan rate. More calls or faster narrowing is not success by itself.E.23may use C.24 plans and checkpoints inside improvement Work; C.24 does not restate the improvement loop.E.10.MOVE,E.11.PUR, andA.15.5recover project moves, pattern-use recommendations, and work-entry readiness when those questions are not plan-local.
C.24:End
Q-Bundle: Authoring "-ilities" as Structured Quality Bundles
Type: Definitional (D) Status: Stable Normativity: Normative unless marked informative
Plain-name. Quality-bundle normal form.
Builds on.
C.2.1 for the enclosing quality-claim episteme, A.2.6 for scope algebra, A.6.1 for exact mechanism references when current, and C.16 / A.18 for Characteristic and Scale legality.
Coordinates with.
C.17-C.19 for quality-related measurement families, C.16.P when characteristic/scale/score wording is not yet recoverable, A.15 for method, work-plan, or work-occurrence gating, and C.16.Q for quality/evaluative-characterization wording before the endpoint is one explicit characteristic, Q-Bundle-shaped claim content, objective, or another governing pattern.
Use this pattern when. Use C.25 when a familiar quality family such as availability, resilience, security, or maintainability may be hiding several differently typed contributors and the reader needs one claim that keeps them distinct.
First useful move. Ask: what would make this quality claim false? If one measure on one declared Scale answers the question, state that one Characteristic and stop. Use Q-Bundle-shaped claim content only when several differently typed contributors—such as a measure and scope, or measures plus a load-bearing window or mechanism—jointly determine the answer.
First result. Write one readable quality claim about one exact bearer and include only the contributors on which its truth or the next receiving action depends. An optional slot is omitted unless changing that slot could change the current claim or receiving action.
Nearest non-use. Stay with the direct Characteristic pattern when one measure and Scale carry the claim. Use the direct scope, measurement, evidence, assurance, gate, publication, viability-envelope, or temporal pattern when that neighboring question—not quality-family decomposition—is the current work.
Problem frame
Engineering quality language repeatedly drifts into one of two invalid simplifications: either every -ility is treated as one scalar characteristic, or every engineering-quality statement is left as loose evaluative prose. A conforming engineering corpus therefore needs a uniform discipline that keeps admissible measurements, scope declarations, mechanisms, statuses, and evidence visibly separated without inventing a new kernel ontology.
Problem
Without a normal form for engineering quality families:
- Composite families are scalarized illegally. Terms such as resilience, security, or maintainability are treated as if one number exhausted them.
- Scope is confused with measurement.
A claim's
ClaimScope/WorkScopeis spoken of as if it were a magnitude rather than a USM set-valued applicability object. - Mechanism and status are mistaken for evidence or metrics. Presence of redundancy, certification, or audit controls is described as if it were itself a measurement value.
- Guards become unstable. Admission checks silently mix scope coverage, numerical thresholds, mechanism presence, and evidence freshness in one phrase.
- Evaluative governing-pattern selection remains underspecified.
After
C.16.Qrepairs a bare quality term, orC.16.Prepairs characteristic, scale, score, metric, or proxy wording inside that term, the admissible endpoint is unclear unless FPF distinguishes single-CHR cases from bundle-shaped quality families.
Forces
Solution - Q-Bundle normal form
C.25 defines a lightweight normal form for the claim content of engineering quality families. A publisher facing a quality term first decides whether one claim episteme should state:
- one admissible CHR characteristic, or
- one structured quality bundle whose measurable slots, scope slots, mechanisms, statuses, and evidence remain explicit.
Endpoint split
Use the single-characteristic branch when one exact U.Characteristic, one declared Scale, and the ordinary CHR laws carry the quality claim. The claim-bearing result is still one C.2.1 episteme about its exact bearer; C.25 adds no bundle record.
Use the Q-Bundle branch when several differently typed contributors are part of one quality claim. The result is one C.2.1 episteme whose ClaimGraph contains the record-shaped Q-Bundle content below.
Q-Bundle shape and identity boundary
The full escalation form is:
Q-Bundle := <Name, QualityBearer, ClaimScope?, WorkScope?, Measures[CHR], QualificationWindow?, Mechanisms?, Status?, Evidence?>
Q-Bundle names a C.25-local record-shaped part of one exact U.ClaimGraph. It is not a new Kernel kind, an independently identified world object, or a second identity beside the enclosing episteme. That episteme supplies the exact claim content, one independently identified QualityBearer as its EntityOfConcern, and the effective U.ReferenceScheme under which the quality claim is read.
The ? is operative: omit any optional slot unless changing it could change the current claim or receiving action. A bundle may therefore contain only Name, QualityBearer, Measures, and one load-bearing scope or window. The full tuple is an escalation aid, not a form every author must fill.
Changing any bundle content that changes the quality claim changes the ClaimGraph and therefore identifies another episteme under C.2.1. A changed layout, form, publication occurrence, or carrier can leave that episteme unchanged. A gate, publication, proxy, comparison, or roll-up cites the exact episteme or one exact C.2.1 ClaimAddress, meaning the exact edition plus an intrinsic claim identity declared by that edition's ClaimGraph. Later ClaimAddress uses in C.25 mean that same value; a field list or raw record reference is not enough.
Field meanings
- Name. The engineering quality family label inside the claim content, such as
Availability,Resilience, orSecurity; it is not an identity key. - QualityBearer. The one independently identified EntityOfConcern of the enclosing claim episteme. It may be an exact
U.System,U.PromiseContent,U.Episteme, or another exact entity under its direct identity pattern. When selected organization is the subject, use oneA.22U.Structurewith exact constituents, selected obtaining relations, applied constraints, and one selection-use frame. A list of local system-role kinds and assignment occurrences does not by itself identify a bearer. - ClaimScope / WorkScope. USM sets over
U.ContextSlicedescribing where the claim holds or where the capability can deliver. These are set-valued scope objects, not characteristics. - Measures[CHR]. One or more admissible CHR characteristics, each bound to one declared scale.
- QualificationWindow. The temporal policy under which the quality claim is judged.
- Mechanisms / Status. References to
U.Mechanismrealizations, control presences, certification states, or similar gating structures. They are not measurements. - Evidence. Anchors that justify the measures, mechanisms, or scope claims.
Guard reading
A quality guard is conjunctive only over the truth conditions that the current claim actually declares. For example:
declared scope covers TargetSlice AND declared measures satisfy their own laws AND each other declared prerequisite holds
An absent optional slot contributes no condition. Each measure keeps its own Scale and comparison law; a trade-off, alternative, weighted combination, or partial order must be stated under the pattern that defines it rather than being smuggled into AND. If this typed decomposition cannot express what makes the claim true, do not force the family into C.25.
Archetypal Grounding
Tell. A quality family is not automatically one metric. Use one Characteristic when one measure and Scale carry the claim; use a Q-Bundle only when several differently typed contributors are jointly load-bearing.
Minimal completed availability case. Under ServiceQualityScheme-v4, the claim says: CheckoutAPI maintained at least 99.9% availability for customer-facing request handling over the rolling 30-day window. Its exact bearer is the independently identified CheckoutAPI System. Its Q-Bundle content has Name: Availability, ClaimScope: customer-facing request handling, Measures: AvailabilityRatio[%] >= 99.9, and QualificationWindow: rolling 30 days. WorkScope, Mechanisms, Status, and Evidence are omitted because this drafting use does not rely on them. If evidence reliance, a failover prerequisite, or a gate later becomes current, add only the direct relation or slot that question needs.
Escalation examples. A resilience or security claim often needs several measures, scenario or attack-class scope, mechanisms or control statuses, and a qualification window. Those contributors belong in the bundle only when they are part of that claim's truth conditions; treating the family as one scalar score would erase which contributor failed.
Bias-Annotation
The pattern biases authors toward explicit decomposition. That bias is intentional. It is better to publish a visibly structured quality bundle than to gain short-term convenience by collapsing scope, measures, and mechanisms into one overloaded quality label.
Conformance Checklist
CC-C.25-1If an engineering quality claim is intended as one measurement characteristic, the publisher SHALL bind it to one namedU.Characteristicwith one declared scale.CC-C.25-2If the claim requires multiple measures, scope slots, mechanism slots, status slots, or qualification windows, the publisher SHALL use Q-Bundle-shaped ClaimGraph content rather than an undeclared scalar surrogate.CC-C.25-3ClaimScopeandWorkScopeSHALL remain USM set-valued scope objects; they MUST NOT be treated as ordinal or numeric quality levels.CC-C.25-4Mechanism or status slots MUST NOT be conflated withMeasures[CHR].CC-C.25-5Any scalar comparison or thresholding inside a Q-Bundle SHALL apply only to declared CHR measures, not to scope slots.CC-C.25-6When cross-context comparison is current, the publisher SHALL align the exact bundle heads or slots, resolve the two exactF.17local senses, test the directF.9Bridge predicate, and state a separate bounded-use claim only if that Bridge obtains. The comparison and its reliance MUST NOT change any Q-Bundle slot; ordinary reliance usesA.10, whileB.3opens only when an actual named assurance claim is current.CC-C.25-7A materialized Q-Bundle SHALL be recoverable as content of one exactC.2.1episteme with one independently identified QualityBearer as EntityOfConcern and one effective ReferenceScheme. A gate, publication, comparison, proxy, or roll-up MUST NOT cite a field list as though it were an independently identified bundle object.
Common Anti-Patterns and How to Avoid Them
Consequences
Rationale
Engineering quality language is useful precisely because it groups recurring concerns under memorable family labels. The same grouping becomes dangerous when those labels are mistaken for one universal metric. C.25 preserves the family labels but forces the underlying structure to stay typed and visible.
SoTA-Echoing
The comparison below selects lines by the quality-family problem they can solve, not by publication popularity or by the availability of a convenient form.
FPF-local synthesis. C.25 combines only the non-dominated moves needed before a direct domain pattern takes over: one exact bearer; a single-Characteristic exit; otherwise a typed separation of load-bearing measures, scopes, windows, mechanisms, statuses, and evidence references; and a guard over only the conditions the claim actually states. The tuple and this conditional guard are FPF synthesis, not a claim that contemporary practice already shares one universal Q-Bundle.
Defeating and reopen conditions. Prefer a direct domain pattern when it already supplies a clearer composite-quality identity, aggregation law, and practitioner route. Reopen C.25 when a useful quality claim cannot be stated through the available typed contributors without inventing filler, when a non-conjunctive trade-off or dependency cannot be named under its direct pattern, when the record costs more than the receiving decision warrants, or when a proxy repeatedly becomes the decision object despite the source claims remaining load-bearing.
Relations
E.21 specialises Q-Bundle-shaped claim content for FPF pattern-quality claims. C.25 remains the general endpoint pattern for engineering quality families; E.21 governs the claim when its exact EntityOfConcern is one FPF pattern version evaluated as action-guiding FPF text.
C.27 temporal-claim relation.
-
C.27 may flag: a quality-family statement where agility, resilience, adaptability, recovery, or robustness depends on braking, redirection, stabilization, recovery rate, or rhythm under effort.
-
This pattern keeps: quality-family bundle structure, scope, mechanism/status slots, evidence, qualification window, and failure mode.
-
Non-admissible use: temporal adequacy is not quality adequacy; speed, recovery, or rhythm becomes quality content only when C.25 declares the quality family, scope, mechanism/status slots, evidence, and failure mode.
-
Coordinate with C.27 only when the temporal dynamic changes admissible use; do not make every quality bundle carry dynamic slots.
-
Builds on:
A.2.6for scope algebra,A.6.1for mechanism references, andC.16 / A.18for CHR legality. -
Coordinates with:
C.2.2a,A.16.0,A.10for ordinary reliance on a bounded cross-context use,B.3only when an actual named assurance claim is current,A.15for gate use,C.16.Pfor unresolved characteristic, scale, score, metric, or proxy wording inside a quality-family statement,C.16.Qfor overloaded quality or evaluative-characterization wording,C.33,C.34, andC.35when captured structure, lost structure, preservation, or generated-result adequacy becomes part of a composite architecture quality family,C.17,C.18, andC.19for adjacent quality-family measures, andF.9orF.9.1when cross-context bundle comparison or bridge stance annotation is required. -
Constrains: engineering quality authoring whenever a quality term would otherwise drift between single-CHR and composite-bundle readings.
Endpoint function in evaluative classification
In evaluative repair, C.25 is the system-side endpoint pattern for engineering quality families after overloaded quality wording has been repaired by C.16.Q and any hidden characteristic, scale, score, metric, or proxy wording has been repaired by C.16.P. qualityTermAscription(...) may remain a transitional repair record, but it is not the universal resting place when the admissible result is a claim about one Characteristic, one episteme with Q-Bundle-shaped claim content, or an explicit objective-oriented quality claim under its own endpoint pattern.
Decision Test: Single Characteristic or Bundle?
The most common authoring failure is not in the bundle syntax itself; it is in choosing the wrong endpoint shape. The quickest useful test is to ask what would make the quality claim false.
Use one U.Characteristic when
A quality claim should terminate in one admissible CHR characteristic only when all of the following hold together:
- one measurable aspect is actually doing the evaluative work,
- one declared scale is enough to compare relevant cases,
- the bearer and scope are already clear without introducing extra quality slots,
- mechanism or status presence is not itself part of the core quality head,
- and downstream gates can read the claim without needing a bundle decomposition.
Examples include a narrowly declared AvailabilityRatio[%], a specific latency percentile, or one response-time threshold under one fixed window.
Use a Q-Bundle when
A quality claim belongs in C.25 when one family label is standing over several distinct typed concerns, for example:
- several measures are needed together,
- scenario or claim scope is load-bearing,
- mechanism presence or certification state constrains admissibility,
- qualification windows alter the reading materially,
- or one scalar head would hide which part of the family is actually failing.
The bundle is not a fallback for laziness. It is the explicit authoring form for claims whose truth conditions are already composite.
Borderline cases
Some quality families contain both a bundle-shaped form and a narrow single-characteristic form. For example, a service team may use:
- one CHR characteristic for a very narrow uptime commitment, and
- one Q-Bundle for the broader service-availability family that includes scope, windows, failover mechanisms, and evidence.
This is legitimate as long as the text states clearly which head is currently in play. The single-characteristic form does not replace the broader family; it selects one evaluative slice of it.
Slot Interaction Law
The practical payoff of C.25 is not just that it names the slots. It also stabilizes how those slots interact.
Scope and measure remain orthogonal
ClaimScope and WorkScope answer where or under what contextual slice the quality claim holds. Measures[CHR] answer how a measurable aspect behaves. A broader scope is not a larger measurement value; a narrower scope is not a penalty value. Scope is governed by set inclusion and coverage, not by scalar order.
Mechanism and status are gating slots
Mechanisms and statuses may be load-bearing for admissibility, but they do not become measurements merely because they matter. A redundancy mechanism may be required for claiming a resilience bundle, and a certification status may be required for external publication, yet neither slot is itself the Measures[CHR] head.
This matters because many quality arguments fail by turning mechanism presence into an implicit hidden score.
Qualification windows are not decorative
A quality claim that depends on rolling windows, observation periods, maintenance intervals, or disruption horizons must publish that temporal qualifier explicitly. If the truth of the quality claim changes when the window changes, then the window is part of the declared bundle record rather than optional commentary.
Report-only summary proxies
A publisher may compute a report-only summary proxy for convenience, for example a compact quality summary value or an oversight-facing composite score. State in claim content which exact Q-Bundle slots the proxy summarizes and what it leaves out. The proxy may be another Characteristic or claim under its direct pattern, but it does not replace the source quality-claim episteme or its addressed claims in a norm, gate, comparison, or cross-context use.
Worked Quality Families
Availability family
A narrow service commitment may use AvailabilityRatio[%] as one characteristic. A broader availability family usually still needs a bundle because the claim depends on:
- declared service and time scope,
- observation and qualification window,
- one or more mechanism slots such as failover or redundancy,
- and evidence tying the measurement to declared observation conditions.
The bundle form makes it possible to distinguish "the measurement fell short" from "the measurement is fine but the declared mechanism prerequisite was absent".
Resilience family
Resilience is almost never one scalar. It commonly binds together:
- disruption scenario scope,
- restoration-related measures such as
MTTR,RTO, orRPO, - recovery mechanisms and preparedness states,
- and scenario-specific evidence about drills, restorations, or incident traces.
Trying to compress this into a single resilience value usually destroys the difference between fast recovery in one scenario and structural fragility in another.
Security family
Security claims routinely combine:
- trust-zone or attack-class scope,
- measurable characteristics such as patch latency, control coverage, or response interval,
- control-set and certification slots,
- and evidence from audit, observation, or incident review.
C.25 therefore treats broad security-family claims as bundle-shaped unless the claim has already been narrowed to one admissible CHR characteristic.
Maintainability and evolvability
Maintainability or evolvability claims often drift into pure rhetoric. In C.25, they become usable only when the publisher separates:
- the declared scope of systems or change classes,
- the measurable slots (for example change lead time, defect reintroduction rate, restoration interval, review load),
- the enabling mechanisms (modularity rules, test harnesses, interface discipline),
- and the window or evidence conditions under which those measures were observed.
This is exactly the kind of quality family that looks scalar in speech but turns composite once the claim is made explicit.
Authoring and Review Guidance
For authors
Begin with what would make this claim false? Then:
- identify the exact bearer and the quality-family label used in the claim;
- if one measure on one declared Scale carries the claim, state that Characteristic and stop;
- otherwise add only the differently typed contributors that jointly carry the claim;
- omit scope, window, mechanisms, status, or evidence when changing that slot would change neither the claim nor the receiving action;
- identify the enclosing C.2.1 episteme through its claim content, bearer, and effective ReferenceScheme; and
- add a proxy, gate, publication, evidence relation, or assurance result only when its own receiving question is current.
The schema remains available for a demanding case; it is not the authoring order for every bundle.
For assessors
A checking reader should ask:
- whether the chosen endpoint shape is admissible,
- whether any scope slot has been smuggled into scalar language,
- whether mechanism presence has been mistaken for a metric,
- whether the window is truly optional or actually load-bearing,
- and whether any summary proxy is trying to replace the underlying bundle.
In practice, most defects are visible as soon as the checking reader asks what exactly one reported number stands for.
For gate designers and assurance leads
Resist a guard such as resilience must be high. Cite the exact quality-claim episteme or addressed claim and name only the slots the decision actually uses—for example one scope, one measure threshold, a load-bearing window, or a required mechanism. Do not require an absent slot merely because the source claim uses Q-Bundle-shaped content.
Repair and Boundary Notes
Repair from bare quality requirement prose
Bare phrases such as quality requirement, security requirement, or availability requirement should not survive as bare heads when the underlying endpoint is actually a characteristic or bundle. The repair rule is:
- choose the endpoint shape first,
- then bind the requirement or commitment to that explicit head.
C.16.Q may still be the entry repair for overloaded quality wording, and C.16.P may repair characteristic, scale, score, metric, or proxy wording inside the same statement; C.25 is the resting place only after the engineering quality family has been made explicit.
Boundary to cross-context use and reliance
Cross-context comparison does not change whether the endpoint is one characteristic or one bundle and does not modify any bundle slot. Align the exact bundle heads or slots, resolve their exact F.17 local senses, and test the direct F.9 predicate. If a Bridge obtains, state the proposed direction, correspondence rule, tolerated loss, and polarity in a separate bounded-use claim. Observed loss remains evidence; permitted loss remains that claim's tolerance. Use A.10 for ordinary bounded reliance and open B.3 only when an actual named assurance claim is current.
Boundary to publication convenience
A report, summary publication, or executive summary may express only one slice of the selected quality-claim episteme. Keep the selected episteme and any exact ClaimAddress distinct from its publication occurrence, form, and carrier under E.24.PUB. A coarser form does not collapse the source claim content, while changed Q-Bundle claim content identifies another episteme even when the file or layout stays the same.
Serviceability and supportability
Serviceability, supportability, and adjacent family labels often look simple in prose but become composite as soon as operational use is declared. An admissible bundle for this family may need:
- support-scope slices,
- measured restoration or service intervals,
- mechanism slots for support mechanisms, access discipline, or replacement procedures,
- and evidence from service traces or support records.
The lesson is the same as elsewhere in C.25: once the truth of the family claim depends on several typed contributors, the bundle should stay explicit.
Boundary to description-side and selector-side evaluation
C.25 is for engineering quality families whose bearer is a system-side, promise-side, or explicit quality-bearing artifact. It does not automatically cover:
- viewpoint-fit or grounded architecture adequacy claims, which may belong in viewpoint or evaluative-ascription patterns,
- or selector/objective heads where quality means use-value under a search or portfolio frame.
This boundary matters because the same word quality appears across those zones. C.16.Q repairs overloaded quality wording, C.16.P repairs characteristic, scale, score, metric, or proxy wording when that is the hidden object, and the resting endpoint depends on what is actually being evaluated.
Bundle Decomposition and Comparison Law
Local decomposition rule
A family label may remain stable while its internal slots differ materially across contexts. Conforming comparison therefore starts by aligning the bundle decomposition: scope slots with scope slots, measure slots with measure slots, mechanism/status slots with their own kinds, and evidence/window slots with their own kinds. Comparing one bundle's measure directly to another bundle's mechanism claim is a category error even if both sit under the same family label.
Narrow slice versus whole family
A publication may expose one narrow Characteristic claim from a broader Q-Bundle-shaped claim episteme, but it must identify that addressed claim as only one contributor to the broader family. It must not cite the slice as though it exhausted or reidentified the source episteme.
Cross-context family comparison
Cross-context comparison of quality families starts with explicit bundle alignment: compare scope with scope, measures with corresponding measures, mechanisms or statuses with their own kinds, and windows or evidence only when the receiving comparison uses them. For each meaning that crosses local schemes, resolve the two exact F.17 senses and test the direct F.9 predicate. Cite a Bridge only when it obtains, then state the proposed use separately with its direction, correspondence rule, tolerated loss, and polarity. Keep observed loss in evidence, use A.10 for ordinary reliance, and open B.3 only on its own assurance trigger. None of this changes the Q-Bundle or supplies an automatic penalty.
Gate, Proxy, and Reporting Discipline
Report-only summary proxy
A summary proxy remains a separate downstream claim. It identifies the source quality-claim episteme or exact ClaimAddress, states what it summarizes and omits, and never replaces that source in a norm, gate, or endpoint classification.
Gate binding rule
When a gate uses a quality family, its decision claim cites the exact quality-claim episteme or addressed claims and names only the bundle slots on which the decision relies: for example declared scope, specific measures, a qualification window, or required mechanisms or statuses. The gate does not bind to a family label or raw record, and C.25 does not define the gate decision.
Roll-up caution
A roll-up is another claim-bearing episteme. It cites the exact source epistemes or ClaimAddresses being combined, states the admissible aggregation or summary rule, and remains distinct from them. If the roll-up begins to drive local engineering action directly, reopen the source claims and the exact Q-Bundle slots on which that action relies instead of treating the summary score as the bearer or bundle.
Review Matrix and Repair Tests
A checking reader can test a Q-Bundle with five questions:
- Is the endpoint shape admissible? One characteristic where one characteristic is live, one bundle where several typed contributors are load-bearing.
- Are scope and mechanism slots kept distinct from measures?
- Is any summary number trying to replace the bundle?
- Would a gate still be auditable if the family label were removed?
- If the claim crosses contexts, is bridge work kept in
F.9rather than hidden inside the family bundle?
Repair from bare family prose should therefore recover bundle shape first, then choose whether any narrow slice deserves a separate CHR publication.
Viability-envelope, quantum-like, and temporal-claim relation note
Use C.25 when the question under repair is a quality bundle, "-ility" decomposition, proxy metric, trade-off, gate, or report. A viability claim should not become quantum-like merely because it involves uncertainty, feedback, several qualities, or changing operating conditions; a temporal claim should not become a Q-Bundle merely because the working phrase mentions speed, cadence, rhythm, or recovery.
Practical reading:
- Decide whether one Characteristic answers the quality question; if it does, stop there.
- If several differently typed contributors are load-bearing, identify the bearer and include only those measures, scopes, windows, mechanisms, statuses, or evidence anchors.
- If one proxy or this proportional bundle answers the receiving question, stay in
C.25. - Open
C.26.3only when the current question concerns a viable region, disturbance, boundary condition, intervention, adaptation cost, or failure mode. - Open
C.27only when rate-change under effort, window, resistance, recovery, or cadence changes the admissible use of a temporal claim. Minimum viability-envelope note:
Useful outputs:
- one
C.2.1quality-claim episteme with Q-Bundle-shaped content when the issue is quality decomposition; - a
C.26.3envelope-regulation note when probes/actuators/boundary conditions change the admissible viability reading; - a
C.27temporal-claim adequacy card when rate-change, effort, window, resistance, or cadence changes the admissible use; - no QL wording when ordinary quality-bundle, proxy, feedback, or control tuning carries the work.
Architecture-decision Q-Bundle boundary
C.32.P2S, C.32.PAD, and C.32.ADA may cite exact C.25 quality-claim epistemes or ClaimAddresses as architecture-characteristic inputs, accepted-loss structure, guardrail rows, feedback concerns, or adequacy concerns. C.25 keeps their Q-Bundle claim content, bearer, scope, measures, mechanisms, qualification window, and evidence distinct from the problem-to-structure architecturing flow, project architecture decision relation, and ADR-like publication projection.
C.25:End
Quantum-Like Modeling Lens
Type: Architectural pattern Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
FPF already has local patterns for decisions, boundaries, bridges, work, measurement, search, and quality bundles. Some real architecture cases still break when those patterns are applied as if every read, question, dashboard, workshop, bridge, or simplified representation were a passive view of a stable state.
Use this pattern only after the ordinary FPF subject assertion and exact predicate are in place and one exact contextual-model obstruction still changes what may be inferred or done. The obstruction may be a no-global-section result, incompatible probe algebra, order-sensitive instrument result, or another named failure of passive read, joint comparison, faithful-enough export, or use-preserving coarsening. A broad word such as context, a diagram, different labels, ordinary DDD locality, or mere model plurality does not open C.26.
What goes wrong if missed. A dashboard, workshop, metric, bridge, export, or coarsened model is treated as a passive faithful readout even when the probe, frame, publication, or representation shortcut changes what can be inferred.
What this buys. The user keeps the ordinary FPF pattern in charge and adds only the minimum quantum-like lens needed to prevent that concrete representational mistake.
Identity before the lens. When C.26 carries a quality ascription or model claim, first name the quality bearer or C.2.1 claim-bearing episteme, its effective U.ReferenceScheme, the probe or model frame, the comparison frame, and the applicable U.ClaimScope. State separately whether an EpistemeEmpiricalGroundingRelation obtains; a measurement, evidence reference, card, or label does not make it obtain.
If a viewpoint matters, record one U.ViewpointRef that resolves to the U.Viewpoint episteme P. Neither P nor its reference evaluates.
When evaluation Work is claimed, the evaluator is the System that performs that Work. Name the enacted Method, assignment occurrence and its declared species, and F.6 attribution. A non-performing participant in an evaluation relation is named only by that relation and position, not called an evaluator by implication. These neighboring values do not become identity fields of one omnibus QL record.
This pattern is not a physics claim. In FPF, quantum-like names a detached mathematical and representational lens, comparable in use to probability, calculus, optimization, or state-space modeling. It is cheap as a QL-lite note and expensive only when the claim becomes reusable law, assurance evidence, empirical superiority, formal reconstruction, or ontology.
Unifying principle: use QL to cheapen the first correct move, not to make the first mention more expensive.
What this lens buys in practice:
Plain glosses:
quantum-like: a detached mathematical or representational lens, not a claim about what the target is made of.probe: an operation that both produces an output and may change the represented state or admissible use of the output.frame: the exact probe frame, measurement frame, comparison frame, or model frame selected by its subject pattern; it is not a semantic owner, a universalU.Frame, or a substitute for an effectiveU.ReferenceScheme.state: the represented condition relevant to the current decision, not a generic newU.Statekind.state update: a typed update claim. When load-bearing, say whether the update is a system change, work change, epistemic reading update, carrier update, emitted-output update, formal model update, or update-law change; do not let one phrase carry all of them.context: an ordinary-language warning that locality may matter, never a participant or owner by itself. Recover the exact claim scope, reference scheme, local-sense endpoint, selected model-use structure, qualification window, viewpoint relation, or direct subject relation that the sentence actually needs.export: a carried representation whose use may lose timing, coordination, system-role or participation relations, use conditions, confidence, or relation structure.coarsening: an intentionally cheaper state representation with declared loss and reopen conditions.
Phrase hygiene:
Example style:
Informative bilingual translation note:
Problem
Without this pattern, teams make five recurring mistakes.
They treat a probe as a neutral read when the probe changes later answers or behavior. They combine two posterior-looking outputs as if both came from one shared sample space. They export a team state, dashboard value, or context-map result as if it were a faithful-enough export for the intended use. They compress a large state representation for speed and then reuse the shortcut outside its admissible-use scope. They let words such as quantum, entanglement, collapse, or field import ontology that the model never earned.
The result is not merely loose wording. The team may approve a release from a dashboard whose publication and operational use changed the work it was supposed to report, average results produced in incompatible local algebras, reuse a local decision under a different effective reference scheme after the admitted bridge lost load-bearing meaning, or claim a speed gain because the representation was low-bit, linear, symbolic, or compressed without naming the loss.
Forces
Solution
Start with the ordinary FPF pattern. Recover the exact claim, bearer or EntityOfConcern, effective reference scheme, scope, probe or model frame, and comparison frame before asking whether a quantum-like lens remains useful. Add C.26 only when a named contextual-model obstruction survives ordinary measurement, comparison, bridge, causal, work, evidence, and representation treatment and changes an admissible engineering inference. Preserve incompatible-probe results in their own local algebras; C.26 does not force them into one global algebra. The main entry question for the whole cluster is: "Which exact obstruction remains, and what should the user now do differently because it remains?"
Application sequence:
- Name the ordinary FPF pattern that already carries the baseline question.
- Recover the exact claim-bearing subject: quality bearer or C.2.1 model-claim episteme, effective
U.ReferenceScheme, probe or model frame, comparison frame, andU.ClaimScope; record grounding and viewpoint only through their separately obtaining relations. - Name the concrete representational mistake: passive read, shared comparison frame, false faithful-enough export claim for the intended use, exact-state shortcut, or unsupported coarsened representation.
- Apply the ordinary subject patterns and retain C.26 only if one named contextual-model obstruction survives and changes the admissible inference or action.
- Fill the QL-lite card if that cue survives; otherwise return to the ordinary subject pattern without QL wording.
- Emit one practical result: use the ordinary pattern only, add a QL-lite note, select one C.26 child pattern as the applicable pattern body, add evidence and assurance, or drop the QL wording.
- Escalate only when the claim becomes reusable, assurance-bearing, formal, empirical-superiority-bearing, or ontology-bearing.
C.26 ordinary output: produce one of these, then stop or select the neighboring applicable pattern body:
- no C.26 pattern selection because the ordinary FPF pattern carries the case;
- QL-lite note with the minimum sufficient field set;
- use the ordinary pattern that carries the question under repair;
- escalation to evidence, assurance, or formal-model work when the claim’s evidence or authority demand requires it.
Keep the entry cost proportional to the use. A QL situation does not begin with a full record.
Do not make the decision-bearing or assurance record the ordinary entry cost. The everyday pattern move is a small recognition note plus a bounded action.
Affordability by working-reader situation:
Do not require a practitioner or architect to produce a researcher-level record when the claim is only recognition or local-working support condition.
Checking discipline:
Cluster maxim: quantum-like wording does not raise assurance load by default. Assurance load rises only when the claim itself is reused, contested, evidence-bearing, release-facing, high-impact, comparative, formal, or ontology-bearing.
Pattern-local-note dependency rule: when an existing FPF pattern cites C.26 or a C.26.* child, the pattern's ordinary action guidance and conformance text remain primary. The citation means only: if a residual QL cue remains after the ordinary FPF pattern has carried its part, use this lens for that residue. It does not make every citing-pattern case depend on the full C.26 record or on every child-pattern semantic.
Model-use structure and crossing boundary. Select a BoundedModelUseStructure only when the organization of one exact model episteme, admitted model-use holons, obtaining applicability/use/coherence relations, applied constraints, invariants, and one named receiving use changes the decision. Compare two such structures only after each is independently selected on that basis. Assert a subject crossing only when an exact direct governor makes one direction-sensitive crossing occurrence obtain among those exact structures. A C.26 finding, local vocabulary, F.9 sense Bridge, diagram, context map, card, reference, or shared participant does not establish that crossing; when the direct governor is absent, return the exact missing-governor blocker.
QL boundary selection:
The default output is a QL-lite card. Keep it short: the three conditional identity rows below may be written as one line, and they are required only when the note carries a quality ascription or model claim.
Decision diff examples:
Minimum viable QL-lite note:
This is enough for QLP-0 / QLP-1 ordinary working use unless the claim is reused, externalized, contested, assurance-facing, comparative, formal, or ontology-bearing.
Use the [C.11](/generated/patterns/C.11) mini-output discipline across the cluster: finish with one choice result or governed follow-up, not with an interesting label.
Retire QL when the residual cue disappears. If [A.6](/generated/patterns/A.6), [F.9](/generated/patterns/F.9), [C.16](/generated/patterns/C.16), [A.10](/generated/patterns/A.10), [B.3](/generated/patterns/B.3), [A.15](/generated/patterns/A.15), [C.25](/generated/patterns/C.25), [A.6.3.CSC](/generated/patterns/A.6.3.CSC), [A.6.3.RT](/generated/patterns/A.6.3.RT), or another ordinary FPF pattern now carries the claim without a false passive read, false shared frame, false faithful export, unsupported distributed-state reading, or QL-specific coarsening residue, remove QL wording from the active working note or pattern prose.
Use the lens only after the activation test survives both sides. C.26 remains active only when one named contextual-model obstruction survives the ordinary subject patterns and changes an admissible engineering inference or action: for example, a no-global-section result, an incompatible-probe algebra, or an order-sensitive instrument effect. Bridge loss, feedback, coupling, openness, compression, coarsening, vocabulary, graph shape, and DDD locality are not QL cues by themselves. Preserve each local result in its own algebra unless an independently admitted joint-comparison route exists; do not manufacture a global frame or infer a structure crossing from comparison.
Canonical cue grammar:
Keep incompatible-probe outputs in their own exact algebras. A common label, common diagram, or desire to average does not supply a joint probability space, comparison relation, grounding relation, or cross-structure occurrence.
Practical payoff in ordinary prose:
- "the metric reported readiness" becomes "the metric publication or measurement regime functioned as a probe interaction that changed readiness behavior";
- "two risk scores disagree" becomes "the two scores may come from non-shared comparison frames with no declared admissible joint comparison route";
- "the workshop discovered the split" becomes "the workshop was a probe whose order and framing changed alignment and local meaning";
- "the team knows" becomes "coordinated work evidences a low-recoverability distributed-state reading with carriers, window, and export loss";
- "this smaller model is enough" becomes "this coarsened state representation carries only its declared admissible-use scope and reopen condition".
Inherited QL boundary
Invariant QL-NQ: within FPF, quantum-like is a detached mathematical and representational modeling lens. It may use quantum-theory-derived structures such as contextual probability, Hilbert-like state spaces, non-Boolean logic, instruments, operator-like update, order effects, open-system descriptions, or incompatible probes.
Quantum-like does not assert physical quantum substrate, microscopic quantum process, qubits, quantum computation, physical entanglement, nonlocal causality, literal collapse, mystical observer effects, social substance, or collective mind. A physical-quantum claim is a different claim and needs separate physical or empirical support outside this pattern cluster.
Child patterns inherit QL-NQ. They should not restate the global boundary as local guidance unless they are repairing a specific confused phrase.
Pattern selector
Causal-use exit before QL retention
Before retaining QL-lite, QL-NQ, or a quantum-like framing for a claim being made, check whether the actual question is intervention, counterfactual comparison, causal effect, causal fairness, causal policy, off-policy causal evaluation, or realizability of counterfactual-rung data. If so, redirect the claim or question to C.28 before any quantum-like retention.
What changes in practice: "the model is quantum-like" cannot be used to skip causality-ladder rung declaration, causal identification, causal evidence support basis, or counterfactual sampling realizability.
What this does not authorize: [C.26](/generated/patterns/C.26) does not become a causal-use pattern and does not treat counterfactual material as a quantum-like subcase; it keeps quantum-like modeling discipline, while causal-use support remains governed by [C.28](/generated/patterns/C.28).
Use this as a diagnostic sequence before retaining QL wording. DDD, microservice domain analysis, and direct boundary, model-use, local-sense, and Bridge subject patterns stay first for service cuts, integration points, and exported meaning. Retain QL only when one named contextual-model obstruction survives those subject patterns and changes what can admissibly be inferred.
- Measurement, metric, scale, method, evidence, or assurance load goes first to measurement and evidence patterns:
[C.16](/generated/patterns/C.16),[A.10](/generated/patterns/A.10), or[B.3](/generated/patterns/B.3). - Bridge, translation, publication availability, rendering, or exported-loss question goes first to its applicable subject pattern:
[F.9](/generated/patterns/F.9)for an exact SenseCell Bridge;[E.24.PUB](/generated/patterns/E.24.PUB)for publication occurrence, form, and carrier;[E.17](/generated/patterns/E.17)only for a current multi-view publication form or face; and[E.17.EFP](/generated/patterns/E.17.EFP)only for a current explanation-faithfulness claim. - A causal intervention, command, or routine question goes first to its pattern. For precise Work enactment, recover each exact actual performer System through A.13 and let A.15.1 independently admit the dated Work and enacted Method. Add an assignment occurrence, its declared species, and F.6 only when the account or its receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; F.6 identifies neither assignment nor performer, and missing or failed F.6 leaves the Work intact. A non-performing relation participant stays with its relation and position.
- Boundary or interface wording, service-interface typing, bridge endpoint, relation precision, or lexeme-collision question goes first to the subject pattern:
[A.1](/generated/patterns/A.1)for holon delimitation or boundary crossing,[A.6.P](/generated/patterns/A.6.P)for relation precision or service/access recovery,[A.6.0](/generated/patterns/A.6.0)or[A.6.5](/generated/patterns/A.6.5)for signature or slot claims,[A.6.M](/generated/patterns/A.6.M)for module-interface claims,[A.6.F](/generated/patterns/A.6.F)for functional ports or elements,[A.6.C](/generated/patterns/A.6.C)only when recovered contract, SLA, protocol, or agreement-like wording bundles promise, utterance or publication, governance, Work or consequence, or evidence claims,[A.6.B](/generated/patterns/A.6.B)only for L, A, D, or E statement classification inside a boundary package, and[A.7](/generated/patterns/A.7),[E.10](/generated/patterns/E.10), or[F.18](/generated/patterns/F.18)for wording-use repair. - Quality, viability, feedback, or control-tuning question goes first to quality, dynamics, and measurement patterns:
[C.25](/generated/patterns/C.25),U.Dynamics, and[C.16](/generated/patterns/C.16). - Suspect option menu, unknown alternative, local plateau, basin movement, or candidate-generation question goes first to search and regime patterns:
[B.5.2](/generated/patterns/B.5.2),[C.18](/generated/patterns/C.18),[C.19](/generated/patterns/C.19), or[A.19](/generated/patterns/A.19). - Retain QL only for the remaining declared state, probe, export, frame, open-information-system, or coarsening cue.
C.26 does not choose among options, generate missing alternatives, or settle [C.11](/generated/patterns/C.11) decision quality. It can mark that the available readings sit in non-shared comparison frames or lack a declared admissible joint comparison relation; the choice or search output still belongs to [C.11](/generated/patterns/C.11), [B.5.2](/generated/patterns/B.5.2), [C.18](/generated/patterns/C.18), [C.19](/generated/patterns/C.19), or [A.19](/generated/patterns/A.19).
Escalation by evidence or authority demand
Math reveal sequence:
Most C.26 use should stay at M0 or M1.
Evidence-use class is escalation by consequence, not an admission gate. QLP-0 or QLP-1 is the ordinary entry class for quick QL-lite use; QLP-2 / QLP-3 appears only when the claim is reused, contested, decision-bearing, assurance-facing, high-impact, or made part of reusable pattern action guidance or conformance text.
Evidence-use class scales by use:
Recognition case matrix
State-representation coarsening card
This card discipline is active when a fuller state representation is too detailed, unstable, unavailable, or expensive for the current bounded decision and a reduced-detail state representation is useful only under a declared QL cue. It is not a standalone speed pattern, not a standalone coarsening pattern, and not a new state-representation kind.
C.26 does not carry ordinary coarsening. A.6.3.CSC carries controlled coarsened rendering; A.6.3.RT carries same-selected-entity representation-scheme transition; A.19, U.Dynamics, modeling patterns, and ordinary abstraction patterns carry ordinary state abstraction. C.26 carries only the residual QL cue plus the loss/use boundary for this shortcut.
Question-to-pattern map:
Start with this coarsening mini-card:
For the representation shortcut itself, fill this coarsening card:
If the text claims that the shortcut is faster, cheaper, more compressed, more linear, more stable, or more tractable, add this claim declaration. The claim is separate from the coarsening card: the card controls the reduced-detail state representation; the declaration controls the performance or tractability assertion.
No speed, compression, linearity, or tractability claim follows merely from the words linear, operator, quantum-like, quantized, tokenized, low-bit, finite-dimensional, compressed, or symbolic.
If the shortcut carries a transition-speed, stabilization, or control claim, add the optional dynamics card:
Archetypal Grounding
Tell: A reliability dashboard says "Ready" after a new readiness metric is published. Before publication, teams treated incidents as local triage. After publication, they change priorities to satisfy the metric, while unmeasured recovery work gets delayed.
Show, System side: the delivery system, teams, dashboard, incident-handling cycle, and release decision form one operational situation. The dashboard is not only a window; it is part of the work ecology because it changes attention, escalation, and behavior.
Show, Episteme side: the QL-lite card says the ordinary FPF patterns are C.16, A.10, B.3, and C.25. The QL cue is an instrument-like metric publication that changes readiness behavior. The minimal admissible output is "treat the dashboard as probe-coupled evidence, not release proof." The local stop is release approval without fuller evidence.
Second grounding: a large state-space model is too expensive for triage, so the team uses four typed operational states. That shortcut is admissible only if the source model, state reduction, loss, admissible use, and reopen trigger remain explicit. The shortcut helps choose a work response; it does not prove the four states are the full system.
Bias-Annotation
This pattern intentionally biases authors toward ordinary FPF patterns before QL vocabulary. That bias prevents prestige use of the word quantum-like and keeps the mathematical lens useful rather than theatrical.
It also biases authors toward minimal admissible outputs. In ordinary use, the right result is often "apply the neighboring FPF pattern", "do not merge these comparison frames", "mark this dashboard as an instrument", or "return to the source representation if the shortcut fails", not a new doctrine about the target system.
The pattern may under-admit some mathematically valid QL models when the author cannot explain the practical payoff. That is acceptable for FPF pattern prose: a model that cannot say what it buys the working reader is not ready for Core-facing law.
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Near-miss taxonomy:
Cluster conformance scenarios
Use these as quick applicability tests. A good C.26 use leaves one practical output, not just a clever label.
QL can also generate better design options:
AI and LLM work-cycle route examples
LLM-mediated work cycles often create the same representational mistakes C.26 repairs: false passive read, false faithful summary, false shared comparison frame, and shortcut without loss/use declaration. This does not make LLMs quantum-like.
Consequences
This pattern gives FPF a single place to define QL-lite and the inherited non-quantum boundary. That reduces repeated disclaimers in child patterns and makes ordinary use lighter.
Cluster success criteria:
The best outcome may be fewer but better QL mentions.
Do not retrofit QL into existing FPF examples merely because they involve measurement, context, service boundaries, feedback, coarsening, or distributed work. Patch only examples where a named false passive read, false shared frame, false faithful export, low-recoverability distributed-state reading, or QL-specific coarsening residue changes the decision.
The cost is authoring discipline. A writer must name the ordinary FPF pattern, the actual QL cue, and the local stop. That is more work than saying "context matters", but it prevents the most expensive mistake: treating a changed, thinned, or frame-bound representation as if it were a full state.
The state-representation coarsening card makes speed and tractability claims more honest. It lets teams use cheaper state descriptions while keeping loss and reopen conditions visible.
Rationale
The cluster stays small on purpose. A single giant "Quantum-Like Architecture" pattern would hide distinct modeling concerns. Scattering the lens across local pattern bodies would repeat the same definition and boundary notes. This modeling-lens pattern lets the common lens live once while child patterns carry their own primary EntityOfConcern and admissible move.
The key rule is simple: quantum-like is not quantum. Once that is typed, FPF can use the math lens normally. The lens earns its keep when it prevents a passive-read, one-space comparison, faithful-copy, or exact-state shortcut.
Evidence is not prestige. Literature supports the modeling move; local evidence supports the local state, export, or probe claim. A source anchor can justify why order effects, contextual probability, instrument-like readings, or open-system modeling are legitimate modeling patterns. It does not prove that this dashboard changed this team's state, that this workshop changed a boundary, or that this export lost the live coordination. That proof or evidence still belongs under A.10, C.16, A.15, B.3, and the ordinary pattern for the local claim.
SoTA-Echoing
Selected operational source anchors
This section is intentionally short. It carries operational anchors for using the pattern, not an expanded bibliography.
Relations
C.28 causal-use relation.
- C.28 governs causal-use question, causality-ladder rung, causal estimand, identification, counterfactual sampling realizability, causal evidence support basis, causal-use verdict, causal fairness, causal policy, and causal method parity.
- This pattern keeps residual quantum-like probe, frame, order, export, or coarsening discipline after ordinary causal-use explanation has been tried.
- Non-admissible use: intervention, causal effect, causal fairness, causal policy, counterfactual comparison, causal method parity, or counterfactual-rung-data realizability do not activate quantum-like modeling by themselves.
- Exit: when the question under repair is causal, cite
C.28before retaining QL-lite or QL-NQ.
C.27 temporal-claim relation.
-
C.27 may flag: ordinary state/rate/rate-change, effort-window, rhythm, braking, coasting, or intervention-timing claims before any quantum-like cue is considered.
-
This pattern keeps: residual quantum-like probe, frame, order, export, or coarsening discipline.
-
Non-admissible use: discreteness, finite differences, typed states, state-space reduction, tokenization, dashboards, probes, measurement plans, speed words, rhythm words, or Dyn2 words do not activate quantum-like modeling by themselves.
-
Boundary: use C.27 and ordinary FPF patterns first; use C.26 only where residual probe, frame, order, export, or coarsening cue remains after those relations are named.
-
Builds on:
E.8,E.9,C.11,C.16,C.25,A.6,A.6.P,F.9,E.24.PUB,E.17,E.17.EFP,A.15,A.10,B.3,A.3,C.18,C.19,A.19. -
Constrains: QL wording in
C.26.1,C.26.2, andC.26.3. -
Carries: state-representation coarsening as a card inside
C.26:4.5, not as a separate pattern. -
Does not cover: physical quantum claims, a generic probe ontology, a generic state ontology, a service/cell pattern, or a field-like synchronization pattern.
-
Name boundary:
Quantum-Like Modeling Lensis a pattern label for a modeling lens and modeling discipline, notU.Lens, notQuantumLikeArchitecture, notQuantum Substrate, notQuantum Ontology, and not a universal architecture doctrine.
C.29 mathematical-lens use relation
C.26is a C.29-compatible specialization for quantum-like modeling. It carries a pre-filled adequacy profile for QL work: preserved structure includes order, probe, and contextual-probability effects when supported; lost structure includes physical quantum ontology; the canonical stop condition remainsQL-NQ. A QL-lite note does not inherit a blank fullMathLensUse.FullCard. A full C.29-compatible profile is needed only when the QL claim is decision-bearing, reusable, publication-bearing, assurance-bearing, bridge-bearing, or formal-model-bearing.
C.26:End
Probe-Coupled Boundary Interaction
Type: Architectural pattern Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when a boundary read, meeting, metric, API read, dashboard, workshop, survey, split, bridge, or message is being used as if it merely revealed or transferred state, but the probe or interaction changes the represented state enough to alter the architecture decision.
This is the main everyday entry into the QL cluster. It is useful because many teams already know how to talk about boundaries, interfaces, metrics, and workshops. The missing move is to notice when the act of reading or crossing the boundary participates in the state being read.
Plain glosses:
passive read: treating a workshop, metric, dashboard, API read, survey, or message as if it only reports state.probe-coupled: the read/export/intervention participates in the represented state enough to change the lawful decision.coupling channel: the concrete workshop, metric, message, API, dashboard, meeting, bridge, or event stream through which the effect travels.export loss: what the carried output cannot faithfully carry into another context or decision.
Problem
Architecture work often treats boundary interactions as passive. A dashboard "shows readiness". A workshop "discovers the context map". An API read "returns state". A meeting "collects alignment". A message "transfers a decision".
Sometimes that is good enough. Sometimes it is false for the current decision. Publishing the dashboard changes readiness behavior. Running the workshop changes alignment and local meaning. Reading the API changes timing assumptions. Sending the message changes trust, escalation, or error handling. Splitting the service changes the viability envelope that the split was meant to optimize.
When the false passive reading survives, the team may keep the wrong boundary, trust the wrong export, combine incomparable outputs, or redesign the system around an artifact that partly created what it reports.
Forces
Solution
Before accepting a passive read or unjustified lossless-transfer reading, ask whether the probe or interaction changed what the output may admissibly mean.
C.26.1 is active only when the interaction both participates in the represented state and its output is being used as evidence, export, comparison input, or decision input as if it were passive. Mere behavior change, ordinary feedback, or ordinary influence is not enough.
A probe-coupled interaction may be useful and intentionally state-shaping. The repair is not to avoid it; the repair is to stop using its output as if it were a neutral pre-probe read.
Start with this recognition note:
Use the fuller decision-bearing record below when the boundary result will be reused, contested, used as evidence, or used to change an architecture decision.
Full decision-bearing record:
Activation boundary
This pattern is active only when the interaction both participates in the represented state and its output is being used as evidence, export, comparison input, or decision input as if it were passive. A passive-read, unjustified lossless-transfer, one-way-message, or ordinary-bridge treatment must be materially false for the current decision.
Ordinary influence is not enough. A meeting that changes attention is ordinary work unless the meeting output is later used as a passive reading of alignment. An API call that is a mutating operation by its interface semantics is ordinary service/API semantics unless the call result is used as a neutral state export. A feature flag that changes behavior is ordinary intervention unless the flag readout is being used as evidence of the state it changes.
Performative prediction is also an important ordinary rival. If a prediction, score, or metric changes behavior because people act on it, but no incompatible probe frame, order-sensitive reading, contextual-probability cue, or instrument-like state/export support load remains, try performative-prediction analysis and the ordinary C.16, A.10, and B.3 patterns first. Keep C.26.1 only for the residual probe admissibility question.
Finish conditions
The pattern emits one of these results:
Probe-coupled context-cut worked use slice
This worked use slice is not a standalone pattern. It tests DDD and bounded-context work when the context cut is not only discovered but also changes meaning, coordination, export validity, or viability.
Ask: was the bounded-context cut merely discovered, or did the workshop, dashboard, API extraction, bridge, split, merge, or orchestration change alignment, ownership, vocabulary, export validity, or viability?
Boundary interaction under concern and operational sequence
The boundary interaction under concern is a boundary interaction used as evidence, export, comparison input, or architecture decision input. The interaction may be a meeting, question sequence, dashboard, metric, API read, survey, workshop, event stream, canary, test harness, service split, bridge, message, or management review. The pattern is active only when that interaction participates in the represented state enough that passive-read wording or unjustified lossless boundary-to-decision inference would change the decision.
The pattern governs one move: convert an apparently passive boundary read into a typed probe-coupled boundary decision. That decision says what the interaction read, what it changed, what the output can support, what it cannot support, and which neighboring FPF pattern takes over if the question is really bridge, measurement, evidence, work, decision, or viability.
Operational sequence:
- Name the boundary or relation being crossed.
- Name the probe lane, including the concrete artifact or work act that produced the output.
- State the false passive reading: what the team would have assumed if the probe were only a window.
- State the pre-probe hypothesis and the observed or inferred post-probe state.
- State the evidence carriers and uncertainty posture.
- State the export loss, memory, order effect, or frame effect that makes the output not faithful enough for the declared use.
- Choose the finish result: keep boundary with probe note, redesign probe, order, or frame, redesign bridge or export, change the split, merge, or orchestration, or apply a neighboring FPF pattern.
Required output: produce a probe-coupled interaction reading, a corrected use of the output, and, when it would reduce the problem, a redesign or decoupling move for the probe, order, frame, bridge, metric, dashboard, API read, or boundary interaction.
This sequence is deliberately small. It is the boundary analogue of the C.11 local choice pass: the pattern should end with a usable result, not with a richer vocabulary label.
Well-formed probe-coupled boundary state
A probe-coupled boundary decision is usable only when the record states all of the following:
- the boundary, context bridge, service interface, team boundary, role relation, authority relation, or system edge involved;
- the probe lane and output carrier;
- the state reading before the interaction and the state reading after the interaction;
- the state-change evidence, including traces, changed labels, changed priorities, changed timings, changed routines, changed bridge fields, or changed downstream decisions;
- the local stop condition: which use the output does not support without another pattern;
- the neighboring FPF pattern that would carry the other claim.
The record is unfinished when any of these remains true:
- the output is named, but the operation that produced it is hidden;
- the operation is named, but the state that changed is not named;
- the state changed, but the decision that changes because of that fact is not named;
- the bridge/export loss is stated only as a vague warning rather than as a concrete non-admissible use;
- the same interaction is alternately treated as evidence, command, measurement, and bridge without role split.
The minimal admissible output is often enough: "this dashboard value is probe-coupled evidence for readiness behavior under window W"; "this workshop work changed alignment and therefore the workshop note cannot be treated as passive discovery"; "this API read is a non-neutral observation under these interface semantics"; "this context cut needs both F.9 bridge loss and C.26.1 probe-coupling treatment."
Probe, observable, output, and carrier split
Do not identify the thing being asked with the method that asks it, the output that appears, or the output carrier.
This split prevents a common mistake: "the dashboard says ready" hides at least four objects. The dashboard definition, the displayed result, the behavior it changes, and the readiness decision are distinct.
Reroute and disambiguation guide
Use this guide when a draft says that a boundary, system, team, or service is "coupled", "aligned", "interacting", "measured", "exported", "synchronized", or "read".
When relation wording is load-bearing, do not mint a relation token here. Keep the sentence as local explanatory prose or apply A.6.P or F.18 to reusable relation work.
Positive examples and near misses
The positive examples are intentionally ordinary. QL value here is not exotic formalism; it is noticing that a read, metric, workshop, or interface often participates in the state it later claims to report.
Evidence posture for probe-coupled claims
Use the least-committing evidence posture that still supports the intended use.
Do not make QLP-3 the ordinary entry cost. Most practical C.26.1 use lives at QLP-0 or QLP-1, with escalation only when the output is reused or carries higher consequence.
Archetypal Grounding
Tell: A team runs a service-boundary workshop after a series of incidents. The first map says "Payments is separate from Checkout". A week later, incident triage and backlog priorities have changed because the workshop reframed payment failure as a customer-promise risk.
Show, System side: the teams, services, dashboards, event stream, workshop format, and escalation routine are part of the boundary situation. The workshop is not only a carrier of information; it changes alignment and future work.
Show, Episteme side: the minimal evidence-bound claim is not "the workshop discovered the true topology." It is "the workshop work functioned as a probe lane that changed the represented boundary state and exposed export loss across Checkout and Payment." The next admissible use is a boundary or probe decision plus F.9 bridge notes.
Bias-Annotation
This pattern biases authors against passive-reading convenience. That bias is useful when dashboards, workshops, surveys, and API reads are treated as if they carry state without changing it.
The pattern also biases authors against overusing QL. It keeps ordinary intervention, ordinary message passing, ordinary bridge loss, ordinary API semantics, and ordinary work enactment with their existing FPF patterns when no probe-coupled reading remains.
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
This pattern makes boundary decisions more honest. It turns "the workshop showed the split" into "the workshop both showed and changed the split-relevant state." It turns "the dashboard says ready" into "the dashboard is probe-coupled evidence with a limited decision use."
The cost is that some familiar artifacts lose false authority. Dashboards, workshops, surveys, API reads, and messages remain useful, but they no longer get to pretend they are always neutral windows.
Rationale
The pattern exists because boundary work is where the QL lens becomes practically visible fastest. Teams already experience dashboard effects, workshop effects, order effects, and bridge loss. The pattern gives those experiences a lightweight, typed, ordinary-pattern-compatible form.
The pattern is not a generic interaction theory. It is a boundary/probe repair for cases where passive read or unjustified lossless-transfer reading is materially false.
SoTA-Echoing
Worked-use-slice discipline from these rows:
- start from the ordinary FPF pattern before QL wording;
- show the concrete operation that produced the output;
- show the state update or export loss that changes the decision;
- keep relation tokens local unless
A.6.P/F.18gives them a reusable declaration; - keep source-formalism language as modeling support, not as pattern-body ontology.
Relations
- Builds on:
C.26,A.6,A.6.B,A.6.P,F.9,A.15,C.16,A.10,B.3,C.25,A.1.1. - Coordinates with:
C.26.2when coordinated work evidences a non-exportable distributed state;C.26.3when the boundary interaction changes a viability envelope. - Carries: a worked use slice inside
C.26.1:4.3, not a standalone pattern or relation token. - Does not mint:
U.Probe, a new boundary kind, or reusable relation predicates. - Name posture:
Probe-Coupled Boundary Interactionnames a boundary and probe relation, notEntangled Boundary,CoupledBy(...),Interaction Field,State-Changing Communication, or a reusable relation token. Relation wording remains local untilA.6.PandF.18ratify it.
C.26.1:End
Enacted Distributed State Evidence
Type: Architectural pattern Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when coordinated work, behavior, or trace patterns give evidence that a team, organization, service mesh, market, or other collective system is acting from a state that no single participant report, survey, policy sentence, dashboard, or API export faithfully carries.
The pattern supports only a minimal evidence-bound claim. It lets an author say that coordinated work, behavior, or trace patterns are consistent with a distributed-state reading during a declared window, while keeping the claim tied to carriers, probes, rival explanations, and export loss.
Plain glosses:
collective bearer: the declared team, organization, service mesh, market slice, or otherU.Systemwhose coordinated work, behavior, or trace pattern is being read.coordinated work or behavior: role-work, service behavior, market participant traces, routine, commitment, artifact use, or coordinated action.distributed-state reading: a minimal evidence-bound interpretation of coordinated work or behavior, not a new hidden group entity.carrier: a log, trace, artifact, commitment, routine, dashboard, report, API response, or document that grounds but does not equal the state.faithful-enough export: a representation good enough for the current decision; when it is not faithful enough, state what was lost and why.
Problem
Teams often need to talk about latent alignment, readiness, market posture, service-mesh behavior, or an enacted "we already decided" before one explicit representation exists. Without a pattern, they oscillate between two bad options.
One option is magic language: "the organization knows", "the culture decided", "the market wants", or "the service mesh understands". The other option is false reduction: a survey answer, policy sentence, dashboard, or report is treated as the whole state.
Both fail. Coordinated behavior may evidence a real working state, but it does not automatically identify a durable mind, internal representation, causal mechanism, or faithful-enough export for the intended use.
Forces
Solution
Model the claim as evidence-bound U.Episteme over a declared collective U.System. Do not make the distributed state a bearer-independent thing. Do not treat a survey, dashboard, report, or API response as the state itself.
If the bearer is a market slice or service mesh, declare whether it is a collective U.System, delivery system, trace population, or evidence set. Do not infer systemhood from coordinated-looking traces alone.
The primary evidence family is coordinated work, service behavior, market participant traces, distributed cognition, routine dynamics, team cognition, work traces, and socio-technical evidence. QL enters only when probe, frame, export, incompatible read, or carrier/export structure that is not faithful enough for the declared use changes the admissible state reading.
The canonical EDSE move is to separate the factorable part from the coordination residue before making the minimal state reading:
- state what ordinary routines, policies, incentives, shared stimuli, dashboard-following, or copied artifacts explain;
- state what the carriers show;
- state what residue remains as a minimal state reading;
- state what action this residue supports.
Start with this recognition note:
Use the fuller EDSE record below when the reading will change coordination, be reused, be contested, support evidence, or leave the immediate local discussion.
Full EDSE record:
Minimal claim principle
Preferred wording stays close to observed work:
- "During window W, the incident-response organization acted consistently with a rollback-readiness posture, evidenced by release timing, escalation criteria, and shared trace use."
- "The service mesh exhibited a coordinated throttling regime under policy P, evidenced by route changes and saturation traces."
- "Market traces support an expectation-shift claim under probe Q, with media amplification still a rival explanation."
Avoid wording that asserts a heavier claim, such as "the organization decided", "the market knows", or "the team has a distributed mind", unless another FPF pattern and evidence requirement independently support it.
Finish conditions
This pattern emits one of these results:
Rival explanation rule
Before using this pattern, name the principal ordinary rivals:
Export-loss discipline
The phrase "not faithfully exportable under current probe and bridge conditions" is supported only when the text says:
- what export was attempted;
- what would have counted as faithful enough for the current decision;
- what state, coordination, evidence path, timing, role alignment, option structure, survivor relation, or use limit was lost;
- whether the loss comes from bridge, measurement, representation, audience, timing, state change, or another cause;
- whether a more discriminating probe, bridge, representation, or time window could produce a higher-fidelity export.
Compound-state decomposition card
When the distributed-state reading is load-bearing, state the decomposition explicitly. Its practical purpose is the canonical EDSE move: ordinary rivals first, carriers second, coordination residue third, admissible use or action invitation fourth.
Evidence-bound state reading and claim floor
The evidence-bound state reading is an evidence-bound U.Episteme reading over coordinated work, behavior, or trace patterns by a declared collective U.System. The pattern does not govern an inner group entity, a culture substance, a market mind, a hidden service intelligence, or a reusable kernel state kind.
The minimal state-reading move is to turn coordinated work, behavior, or trace patterns into the minimal useful state reading while keeping the reading bound to:
- the collective bearer and its boundary;
- the observed work and evidence carriers;
- the time window and persistence support;
- the probe or export conditions;
- the ordinary rival explanations;
- the current export loss and higher-fidelity export possibility;
- the next neighboring FPF pattern if a claim requiring additional evidence is needed.
This pattern is useful because many real work states are enacted before they are articulable. A team may behave as if a release freeze exists before any single person states it cleanly. A service mesh may exhibit one routing posture before any one dashboard carries the whole situation. A market may shift expectations before any one survey faithfully exports the shift. The pattern lets FPF say that much, and no more, without pretending that one carrier is the state.
Operational evidence sequence
Operational evidence sequence:
- Name the collective bearer as a declared
U.Systemboundary, not a bare social label. - Name the coordinated work, behavior, or trace pattern being read through
A.15: actions, routines, commitments, role-work, service behavior, market participant traces, artifacts, or timing. - Name the evidence carriers through
A.10so the reading is inspectable. - State the time window, persistence support, decay/refresh condition, reprobe cost, and ordinary rival explanations.
- Name the candidate state reading only as a minimal evidence-bound
U.Epistemereading. - State the attempted export and what it lost.
- State the minimal supported claim, the supported action or use it carries now, and the other uses that remain unsupported by this reading.
- Add
B.3assurance only when consequence level, audit, release, or accountability use demands it.
Required output: produce a minimal evidence-bound distributed-state reading, the time window that bounds it, the live rival explanations, and the supported bounded action or use that follows from that reading.
The pass is complete only when the resulting sentence can survive without magical collective wording. A good output sounds like:
During incident window W, the incident-response organization acted consistently with rollback-readiness posture P, evidenced by deployment queue changes, escalation messages, rollback artifacts, and support-routing changes; this reading is not faithfully exported by survey S because S loses timing, role-work, and trace linkage.
That sentence is narrower than "the organization decided", but it is much more useful. It supports adjusting incident communication and release-triage posture during window W; it does not support a durable culture claim or release-readiness assurance claim.
Well-formed EDSE record
A usable EDSE record has this shape:
The syntax is illustrative. The content is not optional when the state reading is used for a decision.
Well-formedness constraints:
collectiveBeareris a declared collective system, not a metaphorical subject.evidenceCarriersare inspectable publication units, traces, records, commitments, logs, or work-result records.timeWindowbounds the claim; persistence beyond that window needs its own support.ordinaryRivalsinclude at least the principal policy, incentive, routine, shared stimulus, dashboard-following, copied-artifact, or social-desirability explanation that could explain the same coordination.minimalSupportedClaimstates only what survives after rivals and export loss are named.unsupportedUsenames the neighboring claim or use that the current claim does not carry without applying the neighboring FPF pattern governing that claim that governs that claim.
Carrier, probe, report, and state split
The pattern keeps four objects separate:
A survey can be an evidence carrier and a probe. It is not the distributed state. A policy can be a carrier or a routine explanation. It is not automatically evidence that everyone shares one state. A dashboard can be a carrier, a probe, and a behavior-changing instrument. It is not automatically faithful enough for the intended use.
Case bank and near misses
Evidence posture and confidence
EDSE claims become useful when the text says how much consequence the evidence can carry.
For QLP-0 or low-consequence QLP-1, do not force persistence, decay, or reprobe-cost fields when the claim is explicitly momentary and the bounded action is local. Name the bearer, carriers, window, minimal reading, rival, practical change, and local stop; add the fuller temporal fields only when reuse, contest, or consequence makes them load-bearing.
The ordinary EDSE claim is minimal but actionable. It says: "this coordinated work or behavior supports this bounded reading for this use." It does not say: "the collective has one hidden durable state that a report can copy."
Archetypal Grounding
Tell: During an incident, several teams independently stop non-critical releases, reroute support, and prepare rollback evidence before any single manager issues a written decision. Later, a survey asks whether "we had decided to freeze release", and answers conflict.
Show, System side: the collective bearer is the incident-response organization during a declared incident window. Its carriers include deployment logs, meeting records, escalation messages, rollback preparation, support routing, and release queue changes.
Show, Episteme side: the supported claim is minimal. The organization acted consistently with a release-freeze readiness posture during window W. The claim does not say every participant knew the same proposition or that the coordination exists apart from the declared evidence carriers. A management directive, playbook, or dashboard effect remains a rival unless evidence narrows it.
Bias-Annotation
This pattern biases authors toward minimal evidence-bound claims and explicit evidence. That may feel conservative, but it makes distributed-state language usable without magic.
It also biases authors to keep primary grounding in distributed cognition, team cognition, organizational routines, socio-technical work, and evidence practice. The QL lens is secondary and only becomes active when probing, exporting, or comparing the state changes or loses load-bearing structure.
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
This pattern lets FPF discuss enacted collective states without mysticism. It gives authors a disciplined way to use traces, routines, coordinated work, and export loss in one minimal claim.
The cost is that many attractive claims become narrower. That is the point. Minimal evidence-bound claims are often more useful than confident but ungrounded stories.
Rationale
Existing FPF patterns can carry parts of the support requirement, but no single ordinary pattern makes the combined minimal distributed-state claim easy to write. A.15 carries work, A.10 and B.3 carry evidence and assurance, F.9 carries export loss, and C.16 carries formal measurement. C.26.2 coordinates those neighboring-pattern applications for the specific case where coordinated work evidences a non-articulated state.
SoTA-Echoing
Worked-slice discipline from these rows:
- ground the claim in coordinated work before QL vocabulary appears;
- state the evidence carriers and time window before stating the state reading;
- name rivals before retaining a distributed-state claim;
- treat survey/report/dashboard outputs as carriers or probes, not as the state;
- escalate to measurement, evidence, assurance, or authority patterns when the use requires measurement, evidence, assurance, or authority support.
Relations
- Builds on:
C.26,A.15,A.10,B.3,F.9,C.16,E.17.EFP,C.11. - Coordinates with:
C.26.1when the probe changes the state being evidenced;C.26.3when the coordinated state is part of viability-envelope regulation. - Does not mint:
U.DistributedState, a bearer-independent group entity, or a durable state beyond declared evidence and time window. - Name posture:
Enacted Distributed State Evidencenames an evidence-boundU.Epistemereading over work carriers, notDistributed Mind,Collective Consciousness,Social Field, orOrganization Knows.
C.26.2:End
Viability-Envelope Boundary Regulation
Type: Architectural pattern Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when architecture work is maintaining, recovering, or changing viable operating ranges across boundaries. The working problem is not "optimize one metric"; it is "keep a bundle of characteristics inside a viable region while disturbances, probes, candidate interventions, boundary conditions, and operating regimes change."
What goes wrong if missed. The team treats one dashboard value, stability slogan, or local metric as viability, while another envelope variable, intervention cost, boundary condition, or failure mode is already breaking the protected promise or function.
What this buys. The viability claim becomes an inspectable envelope-regulation decision: the exact object filling the local viability-bearer position and the pattern used to identify it, protected promise or function, variables, disturbances, sensors or probes, candidate interventions, boundary condition, adaptation cost, and failure mode are all named before acting.
Use C.26.3 for the general envelope-regulation claim when several characteristics must remain inside a viable region under a disturbance and a candidate intervention, boundary condition, adaptation cost, or failure mode matters. Continue to use the direct control, quality, SRE, causal, measurement, boundary, and work patterns for the exact objects and claims they define; using them does not make the envelope result leave C.26.3.
QL is an optional coordination branch. Use C.26 and its QL vocabulary only when a probe, frame, export, coarsening, order, incompatible representation, or measurement-changing-state issue remains load-bearing after the ordinary patterns have carried their part. FEP, allostasis, and active inference remain source analogies rather than a second entry condition.
Plain glosses:
viability bearer: a local lens position, not a kind or relation. If the bearer is a System, cite that System's A.1 identity. If it is a selected organization of systems, system-role kinds, and assignment occurrences, identify one A.22U.Structurefrom exact independently identified constituents, exact selected obtaining relation occurrences, exact constraints as applied, and one named selection-use frame. Kind declarations or assignment occurrences listed together do not identify a Structure. A population or market slice instead needs a declared domain and effective reference scheme, membership or scope, and identity basis. If no branch supplies one exact object, stop.protected promise / function: the separately governedU.PromiseContent, stakeholder-value claim, function claim, operating-regime claim, commitment payload, or delivery promise whose continued satisfaction or realization the regulation decision is meant to protect. It is not a slot or part of the object in the local viability-bearer position.serviceor market wording: the wording does not itself identify the viability bearer. Apply the A.1 System branch, the four-discriminator A.22 Structure branch above, or the population/market-slice branch, as applicable. Keep promise content, access points, assignments, commitments, Work occurrences, evidence, and direct relations as separate claims. If no branch identifies one exact object, stop; do not turn the phrase or a list of role kinds and assignments into a bearer kind, situation kind, or bundle.viability envelope: the region of declared characteristic values within which the exact object remains inside the viability bounds stated for the current protected claim or use.envelope variable: one characteristic that must stay within bounds, such as latency, reliability, support load, compliance exposure, safety margin, energy, or operator attention.actuator/candidate intervention: actuator is a control-theory or source label, not an FPF kind and not a synonym for Work. Use candidate intervention only as a local prompt until its proposal-side object is recovered: a Method; aU.MethodDescriptionor policy episteme; a proposed setting change; aU.WorkPlan; an access or permission claim; or a Bridge proposal or description. Separately identify any datedU.Work, independently groundedU.Transformation, obtaining relation occurrence, or resulting state claimed to exist. Keep these objects distinct.allostasis: preserving function through separately governed changes to settings, environment relations, boundary conditions, or operating regime when circumstances change.
Problem
Teams often collapse viability into one dashboard value or fixed target. They optimize latency and damage operator load. They improve availability and increase compliance exposure. They preserve one metric while exhausting the team, hiding risk, or making recovery slower.
A second failure is passive sensing. A metric, probe, dashboard, alert, or health check is treated as a neutral window into viability, even when its use or publication changes behavior through separately grounded Work, interaction, or governance, or hides unmeasured dimensions.
A third failure is static stability. Teams say "keep the system stable" as if stability always means holding one internal variable fixed. In real architecture work, preserving viability may require a candidate intervention. Recover whether the proposal concerns a Method or description, setting proposal, WorkPlan, access or permission claim, or Bridge proposal or description. Separately identify any dated Work, actual change, obtaining relation occurrence, or resulting state claimed to exist; words such as caching, staffing, routing, protocol, and measurement design do not choose among them.
Forces
Solution
Use C.26.3 when the work must regulate a multi-characteristic viability envelope under disturbance. Use C.25, U.Dynamics, measurement, boundary, causal, and work patterns to state the exact qualities, changes, observations, relations, and Work on which the envelope claim relies. Add C.26 / QL only when a probe, frame, export, coarsening, order, incompatible representation, or measurement-changing-state issue remains part of the decision. If no such issue remains, omit the QL fields and checks; do not discard an otherwise useful envelope-regulation result.
Start with this recognition note:
Use the fuller envelope-regulation record below when the viability reading will change a metric, candidate-intervention choice, boundary, staffing, routing, promise, or evidence decision.
Full envelope-regulation record:
Homeostasis and allostasis reading
Homeostasis means keeping a parameter or bundle inside viable bounds. Allostasis means preserving functioning through separately governed changes to internal settings, external relations, boundary conditions, or operating regime when circumstances change.
Do not say that all architecture is homeostasis. Say that some architecture decisions are viability-envelope decisions.
Finish conditions
This pattern emits one of these results:
Metric-induced distortion
Name sensors, probes, dashboards, alerts, metrics, disturbances, and candidate interventions in the envelope claim when they matter. They participate only in world-side relations defined by their direct patterns; C.26.3 does not infer a generic viability relation from their appearance in the same card. A probe or dashboard may still affect behavior, but that effect needs its own grounded claim.
Conditional dynamics detail
When rate, acceleration, second-order change, inertia, damping, resistance, effort, or the strength and latency of a recovered intervention or resulting actual change is load-bearing, state:
- what rate or acceleration matters;
- what slows or speeds the change;
- whether the rate of change itself is changing, rebounding, overshooting, or damping out;
- which inertia is useful and which is harmful;
- which recovered intervention object is proposed, what Work, relation, or setting change can lawfully realize it, and which independently grounded actual change affects the envelope fast enough;
- which evidence shows the dynamic state.
If those variables are not load-bearing, do not force dynamics machinery into the case. The short recognition note or the full envelope-regulation record is enough.
Claim identity and operational sequence
The primary result is one C.2.1 episteme. Its EntityOfConcern is the exact viability bearer, its effective ReferenceScheme fixes how references are read, and its ClaimGraph states the envelope-regulation claim. The writing card below is only a local shape for that ClaimGraph; it is not the episteme's subject and does not create another object.
Keep planned and proposed objects separate. A U.WorkPlan remains a WorkPlan. A setting proposal, policy proposal, Bridge description, or other proposal is a separate claim-bearing episteme about its exact proposed object unless a direct pattern identifies another kind. None of them becomes the envelope episteme merely by appearing in its ClaimGraph.
The first useful move is to turn a one-scalar stability story into an inspectable envelope-regulation decision.
Envelope-regulation sequence:
- Point the local viability-bearer position to one exact object. For a System, cite its A.1 identity. For selected organization, cite one A.22
U.Structurethrough exact independently identified constituents, exact selected obtaining relation occurrences, exact constraints as applied, and one named selection-use frame; a role-kind/assignment list is insufficient. For a population or market slice, state its declared domain and effective reference scheme, membership or scope, and identity basis. Then name the separately defined promise or function being preserved. If no branch identifies the bearer, stop. - Name the envelope variables and the viable range or qualitative boundary for each.
- Name the disturbance or regime change.
- Name sensors/probes and say whether they only report, also frame, or also change behavior.
- Name each candidate intervention and recover the exact object of the proposal: Method or description, setting proposal, WorkPlan, access or permission claim, or Bridge proposal or description. Separately identify any dated Work, actual change, obtaining relation occurrence, or resulting state. Work may change an access, permission, assignment, local-sense claim, reference scheme, Bridge description, bounded-use claim, or other world-side object only as its direct pattern permits. If an F.9 endpoint or profile changes, test the resulting Bridge candidate anew; a fixed Bridge occurrence cannot be revised or ended by authority.
- State the boundary condition being preserved or changed.
- State the trade-off condition and adaptation cost.
- State the failure mode and re-probe/destabilization condition.
- Add dynamics detail only if rate, inertia, damping, latency, resistance, or acceleration changes the decision.
Ordinary output: produce a viability-envelope record with envelope variables and viable region, a disturbance/sensor/probe map, a candidate-intervention-to-direct-object recovery, and a trade-off, adaptation, and failure condition that tells the practitioner what changes in the work.
The output should give one direct next move: revise a MethodDescription or policy episteme; amend a WorkPlan; use A.13 to identify the actual performer and A.15.1 to admit exact Work independently; if that Work account must also identify the assignment under which it was performed, check the relation separately through F.6; change a setting through a separately grounded transformation; change an access or permission relation when its direct pattern permits; revise a local-sense claim, reference scheme, Bridge description, or bounded-use claim; test a new F.9 candidate after an endpoint/profile change; record the resulting state; or drop the envelope claim.
Viability envelope record
A usable envelope record is a C.26.3-local normal form for the ClaimGraph content of one C.2.1 episteme about the exact viability bearer. The enclosing episteme supplies the EntityOfConcern and effective ReferenceScheme. The card is not a constructor and is used only when envelope regulation is load-bearing.
The record is not U.ViabilityEnvelopeRegulation, not a new U-kind, and not a universal architecture constructor. Changing its ClaimGraph content changes the claim and therefore identifies another episteme under [C.2.1](/generated/patterns/C.2.1). A new layout, publication occurrence, form, or carrier can leave the episteme unchanged. New evidence can change the support for the claim without changing that claim; if the asserted ClaimGraph changes, the result is another episteme.
Well-formedness constraints:
- the local viability-bearer position points to one exact object and introduces no kind or relation: a System has its A.1 identity; an A.22
U.Structurehas exact independently identified constituents, exact selected obtaining relation occurrences, exact constraints as applied, and one named selection-use frame; a population or market slice has its declared domain and effective reference scheme, membership or scope, and identity basis; a list of system-role kinds and assignments satisfies none of these branches; - service or access wording names each current object and relation separately—the exact object in the local viability-bearer position, promise content, system, system-role assignment, commitment, Work occurrence, evidence, or another direct relation—through the pattern that defines that object or relation; the wording creates neither a root bearer nor a bundle;
- at least two envelope dimensions are visible when the claim says "viability" rather than one ordinary metric;
- at least one candidate intervention is named when the text proposes regulation rather than only diagnosis, and its proposal-side Method, description, setting proposal, WorkPlan, access or permission claim, or Bridge proposal or description is recovered under the subject pattern; any dated Work, actual transformation, obtaining relation occurrence, or resulting state is identified separately;
- authority and latency are stated only for an object to which they apply; a description, Method, plan, setting label, Bridge description, or resulting state is not made an actor or Work by this card;
- the adaptation cost is named, because allostasis hides cost when phrased as "stability through change";
- the failure mode is named, because viability is otherwise indistinguishable from optimism.
Sensor, probe, candidate-intervention, and metric split
Do not let one dashboard value stand for the whole envelope.
A metric value or dashboard carrier is neither Work nor an actual change. Its use, publication, or a surrounding governance routine may participate in a separately grounded behavior-changing claim. When Work is asserted, use A.13 to identify the actual performer and A.15.1 to admit the dated occurrence independently. If the claim must also identify the assignment under which the Work was performed, name that assignment and check the relation separately through F.6. Name any changed setting, actual transformation, access or permission relation, or boundary relation separately. Repairing one envelope variable may still damage another.
Homeostasis, allostasis, and architecture work
Homeostatic wording is useful when one separately governed claim keeps a variable or bundle inside a stable range. Allostatic wording is useful when preserving the named function requires one or more separately governed setting, boundary, environment, access, staffing, routing, protocol, cache-policy, or operating-regime changes. The wording does not decide whether each item is a Method, description, plan, Work, transformation, relation, or resulting state.
Use the minimal reading that carries the case:
Do not call every adaptation allostasis. The term earns its place only when stability-through-change is the useful architecture reading.
Case bank and near misses
Source-to-pattern translation
Allostasis, active inference, FEP, Markov blankets, and computational-boundary sources are useful here only after translation into FPF architecture terms:
This translation keeps the pattern practical for architects. The reader should be able to move from a source line to one concrete action: change a metric or probe; recover the candidate proposal as its exact Method or description, setting proposal, WorkPlan, access or permission claim, or Bridge proposal or description; separately identify any dated Work, actual transformation or other change, obtaining relation occurrence, or resulting state; where a direct relation pattern permits Work or a transformation to establish, change, or end its occurrence, state that occurrence under its predicate; for F.9, revise only the relevant claim, scheme, endpoint sense, profile, or description and test any new Bridge candidate independently; change a boundary condition; state a trade-off; or reroute.
Archetypal Grounding
Tell: A platform team tries to preserve checkout latency during a traffic spike. The first move is to increase cache aggressiveness. Latency improves, but support load rises because stale payment-failure status causes confused customer contacts.
Show, System side: take CheckoutSystem-1 as a case premise: it has already been independently recognized under A.1 as the deployed U.System whose viability envelope the team regulates. If that recognition is unavailable, stop; checkout, payment, and service wording do not establish the bearer. Keep the protected promise separate: CheckoutPromiseContent-1 is the U.PromiseContent stating the checkout outcome and reliability on which the customer may rely. For this envelope decision, latency and payment-correctness measurements support claims about selected behaviour and results of CheckoutSystem-1; support-load measurement concerns the team's dated support Work; operator-attention measurement concerns the people doing that Work; and customer-promise reliability is tested by a separate evaluation of whether CheckoutPromiseContent-1 is fulfilled. The decision uses these claims as distinct constraints; it does not turn them into facets of one bearer. Candidate interventions are proposed cache-policy, retry-policy, or routing changes. If the team plans one as intended Work, place that intention in a U.WorkPlan; the proposal is not U.Work. Assert U.Work only after A.13 identifies its actual performer and A.15.1 independently admits the dated occurrence from its history, enacted Method, temporal extent, and containing-System relation. If the case must also identify the assignment under which that Work was performed, check the relation separately through F.6. This case asserts only the observed cache-setting change, not a Work individual. A dashboard query remains a probe unless the case separately names a behaviour-changing occurrence. Changing escalation terms, a local-sense claim, a reference scheme, an F.9 endpoint/profile component, or a Bridge description keeps the resulting promise content, commitment, claim, description, and dated Work separate. After an endpoint/profile change, test the new F.9 candidate independently; do not say that Work revised the fixed Bridge occurrence. Here the observed cache-setting change improves latency while stale payment-failure status increases support load, so optimizing one declared dimension damages another.
Show, Episteme side: the supported claim is not "latency is the viability state." It is an envelope-regulation claim: the observed cache-setting change preserved latency while damaging another envelope dimension. The text records that actual change separately from the proposed cache-policy intervention and makes no Work claim without A.13 identifying the performer and A.15.1 independently admitting the dated occurrence. F.6 is added only if the account must also identify the assignment under which that Work was performed. The repair is to state the trade-off, adaptation cost, applicable authority and latency, and failure mode.
Bias-Annotation
This pattern biases authors against scalar comfort. That bias prevents "green dashboard" from replacing viability.
It also biases authors toward actionable architecture work. The pattern asks which direct object a boundary, access, protocol, staffing, cache, throttle, bridge, or measurement proposal denotes and how quickly its separately governed effects can matter. For any precise Work claim, A.13 identifies the actual performer and A.15.1 independently admits the dated occurrence. An assignment and F.6 are added only if the account must also identify the assignment under which that Work was performed. Any actual transformation is grounded separately.
The pattern may feel too broad if it is applied to every quality concern. It is not for every quality concern. Use C.25 alone when one quality bundle or metric can be handled without envelope, disturbance, boundary condition, recovered candidate intervention, adaptation cost, or viability failure mode.
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
This pattern helps architects see stability-through-change. It supports decisions about candidate interventions only after each throttling, staffing, routing, protocol, context-boundary, cache, measurement, or escalation proposal is recovered as its exact Method, description, setting proposal, WorkPlan, access or permission claim, or Bridge proposal or description, while any dated Work, actual transformation or other change, obtaining relation occurrence, and resulting state remain separately grounded.
The cost is that simple metric stories become less simple. That is acceptable when the metric story hides another envelope dimension, an intervention cost, a boundary condition, or a failure mode.
Rationale
Ordinary quality-bundle work does not always show boundary conditions, candidate interventions and their recovered direct objects, disturbances, adaptation cost, and failure modes together. C.26.3 coordinates those elements while preserving ordinary FPF patterns.
The QL lens is secondary. It matters when the way viability is probed, exported, or coarsened changes the state reading or admissible use of the representation.
SoTA-Echoing
Worked-slice discipline from these rows:
- state the envelope before importing source terminology;
- translate source terms into selected structures,
ArchitectureOf@Contextrelations, architecture descriptions, structural views, or named C.30 subcases; - keep sensors, probes, metrics, candidate interventions, and every recovered direct object distinct;
- state adaptation cost and failure mode;
- apply ordinary quality and measurement patterns to one-scalar quality concerns.
Relations
C.27 temporal-claim relation.
-
C.27 may flag: braking, throttling, cadence, recovery, or stabilization moves in claims such as slow rollout protecting support capacity, request throttling preventing collapse, or cadence change preserving attention/team health.
-
This pattern keeps: viability bearer, protected promise/function, viable region, disturbance, sensor/probe/candidate-intervention/direct-object split, adaptation cost, and failure mode.
-
Non-admissible use: stabilization wording is not a viability envelope, and C.27 is not the pattern for all stability-through-change claims.
-
Exit: if the claim being made is only better quality, healthier team, or more resilient service without a declared viability envelope, use C.25, E.13, or the relevant quality/proxy/value pattern rather than C.26.3 or a C.27 profile.
-
Builds on:
C.26,C.25,U.Dynamics,A.6,A.15,C.16,A.10,B.3,A.3,A.19,C.18,C.19. -
Coordinates with:
C.26.1when sensors, probes, dashboards, or metrics change represented state;C.26.2when coordinated work evidences the envelope state. -
Does not replace: ordinary quality-bundle patterns, generic control theory, full FEP doctrine, or biological homeostasis claims outside FPF bridge and loss discipline.
-
Name boundary:
Viability-Envelope Boundary Regulationnames architecture work over a viability envelope and boundary/action conditions, notHomeostasis Pattern,Allostasis Doctrine,Control Ontology,Quality Optimization Pattern, orViability Substance.
C.26.3:End
Temporal Claim Adequacy: State Readings, Temporal Trends, and Intervention-Sensitive Change
Type: Claim-adequacy pattern Status: Stable Normativity: Normative unless marked informative
Use This When
Use this pattern when a claim about speed, rhythm, throughput, recovery, convergence, rollout, adoption, braking, coasting, redirection, or stabilization is being used to change action.
The practical question is simple:
Are we only reading a state, only reading a rate, or claiming that an intervention changes a rate, rhythm, recovery, or regime?
If the claim is only a state or rate reading, stop. If it is intervention-sensitive, state the effort or input, window, resistance or cost, reason for the reading, supported use, unsupported use, and reopen condition.
What this buys. A trend no longer passes silently as an intervention model. Braking, pausing, stabilizing, redirecting, coasting, widening, narrowing, or slowing rollout remain available when acceleration would be the wrong move.
Primary EntityOfConcern. Recover the source temporal claim as one exact C.2.1 episteme or as the exact claim denoted by a C.2.1 ClaimAddress: exact edition plus intrinsic claim identity declared by that edition's ClaimGraph. Every later ClaimAddress in C.27 means that same reusable value. The source claim's own EntityOfConcern remains the System, Work, Method, practice, service, benchmark, or other exact subject it discusses.
When a C.27 result is materialized, it is a separate C.2.1 episteme. Its EntityOfConcern is that exact source episteme or addressed claim, not the ClaimAddress used to refer to it. Its ClaimGraph states the Dyn reading, supported use, unsupported use, and reopen condition. The world-side subject remains a neighboring object; it is not a second EntityOfConcern of the C.27 result. A local note can remain record-shaped claim content. Use E.24.PUB only when a publication occurrence, form, carrier, audience availability, or source-backed publication face changes the use. A changed page or file does not by itself identify a changed claim.
First useful move. Recover the exact source claim and the exact C.27.TA temporal-aspect claim or ClaimAddress it uses. Then classify the source claim:
Dyn0, Dyn1, and Dyn2 classify authored claims. They do not classify Systems, teams, services, Methods, or practices as kinds of things.
Not this pattern when.
- The temporal wording is ordinary explanation and changes no practical use.
- The result needed is only a positive temporal-aspect claim. Use C.27.TA.
- The question is measurement construction or comparability. Use C.16.
- The question is a transition law, simulation, prediction, or control model. Use A.3.3.
- The question is a bounded transformation. Use A.3.4.
- The question is planned or performed Work. Use A.15.2, A.15.1, and F.6 as applicable.
- The question is causal use, benchmark parity, a promise, assurance, value, harm, viability, scaling, adaptation, search health, publication, or residual QL. Use the direct pattern for that question; keep C.27 only if a separate temporal-claim adequacy question remains.
- The reader has only a cue such as braking difficulty, rhythm mismatch, demand accumulation, divergent event traces, or more activity without better results. Keep the cue through A.16, A.16.1, B.4.1, or B.5.2.0 until an exact temporal claim can be stated.
Problem
The recurring failure is:
A text measures or names a rate and then behaves as if it knows how to change that rate.
Typical consequences include:
- a past slope is used as a future control law;
- visible throughput rises while hidden queues, rework, quality loss, service demand, or burnout worsen;
- a local rate change is projected across scale without an aggregation relation or bearer continuity;
- rhythm becomes a mood word with no exact bearer, temporal reference, window, or supported use;
- a planning assumption is laundered into causal proof, benchmark superiority, a release gate, public promise, or assurance claim;
- more reviewers, data, tokens, tool calls, model capacity, or parallelism is assumed to produce linear improvement;
- slowing, braking, pausing, or recovery is treated as failure merely because speed is the implicit value;
- probe, frame, token, dashboard, or active-sensing language activates QL before ordinary patterns have carried their questions.
C.27 repairs one authored-claim failure. It is not a temporal theory of everything, a dynamics model, a measurement calculus, a theory of practice, or a physics analogy promoted into FPF ontology.
C.27 introduces no U.Force, U.Mass, U.Acceleration, U.Rhythm, U.Practice, or U.SecondOrderProcess kind. It also introduces no universal calculus, control theory, or QL model for ordinary temporal claims. Faster is not automatically better. A temporally adequate claim is not automatically valuable, safe, legal, ethical, feasible, promised, or assured. Direct value, quality, harm, promise, legal, safety, and assurance patterns carry those claims.
Forces
- Cheap recognition versus costly overformalization. The state, rate, and intervention-sensitive distinction must be visible in a minute. Most temporal prose must remain outside C.27.
- Effort profiles versus derivative words. Real interventions can be impulses, scheduled pushes, feedback policies, adaptive regimes, brakes, pauses, coasting periods, or redirections. The useful question is what input occurs over which window, not whether the prose says acceleration.
- Resistance without fake physics. Lag, queue pressure, habit, coordination cost, technical debt, service demand, physical inertia, or another domain-local resistance can matter. None becomes a new mass or force kind.
- Rhythm without a rhythm ontology. C.27 consumes an exact C.27.TA claim. Cross-bearer phase, synchronization, coupling, or entrainment appears only when the receiving use relies on that independently established relation.
- Readable practice versus hidden claim inflation. Ordinary actor and practice wording should stay readable. Exact System, assignment, authority, Work, causal, benchmark, promise, and assurance details appear only when the current claim relies on them.
- Preservation versus copied neighboring schemas. Rare uses need exact trigger questions, but C.27 should cite the result of C.16, C.28, G.9, C.26.3, or another direct pattern instead of reproducing its schema.
- Value neutrality versus acceleration bias. C.27 must allow acceleration, deceleration, braking, redirecting, coasting, pausing, stabilizing, recovering, sustaining, widening, and narrowing without deciding which is valuable.
Solution
Use the least-committing result that changes the receiving action.
- Recover the source temporal claim as one exact C.2.1 episteme or as the exact claim denoted by a ClaimAddress.
- Cite the exact C.27.TA episteme or ClaimAddress that states the positive temporal aspect. C.27 does not redefine its bearer, predicate, temporal reference, window, coupling, or currentness.
- Classify the source claim as Dyn0, Dyn1, or Dyn2.
- If it is Dyn0 or Dyn1 and no intervention-sensitive use remains, stop or use C.16.
- If it is Dyn2, write the one-screen card below.
- Add a direct neighboring result only when the supported use relies on its distinction.
- If the claim cannot meet the small card, narrow it. Do not open a larger profile merely because the card exposed uncertainty.
One-Screen Dyn2 Card
The first C.27 result can be one readable sentence:
[Input] is claimed to [move] [the cited temporal aspect] over [window] despite [resistance or cost]; [reason for the reading] supports [use], not [unsupported use]; reopen when [condition].
Use the short note below when the references need to travel or be reviewed separately:
When materialized, this is ClaimGraph content in one C.2.1 episteme whose EntityOfConcern is the exact source episteme or addressed claim denoted by sourceTemporalClaimRef.
- positiveTemporalAspectClaimRef cites an exact C.27.TA episteme or ClaimAddress.
- move names the claimed temporal change, for example accelerate, brake, coast, recover, stabilize, widen, narrow, or a domain-local move.
- claimedInterventionOrInput says what is claimed to affect the temporal behavior. It does not assert performed Work, authority, capability, or causal effect.
- interventionWindow is omitted when the C.27.TA window is enough. Add it only when the input occurs over a different interval.
- resistanceOrCost names the relevant lag, constraint, stored work, queue pressure, coordination cost, residue, or another domain-local obstacle. Unknown is an acceptable local answer.
- reasonForReading names one exact evidence relation, measurement result, model assumption, planning assumption, diagnostic judgement, or direct neighboring result. These alternatives do not become one generic evidence kind.
- supportedUse and unsupportedUse bound the practical reach of this C.27 result.
- reopenTrigger says what change requires a narrower claim, new evidence, another direct pattern, or a new C.27 result.
One local window may stand for claim, sampling, intervention, rhythm, and validity when the difference changes neither the claim nor the receiving action. Split them when, for example, evidence is sampled over a different interval, input precedes the observed outcome, comparison needs a baseline, follow-up occurs later, or validity expires sooner than the trace.
Unknown resistance can support a local diagnosis or planning discussion. It cannot support durable acceleration, causal, benchmark, promise-like, gate, or assurance use without the direct evidence or assumption boundary required for that use.
Readable Actor and Intervention Boundary
Ordinary practitioner prose may say, for example, “the engineer slowed the rollout” when it recognizably names the System acting in the situation.
If the receiving claim relies on performed Work, identify the actual System actor, recover its A.13 core, and independently admit the dated Work under A.15.1. Add F.6 afterward only when the temporal claim also needs precise assignment-bound attribution. If the claim relies on a local system-role kind, System classification, or assignment, add each distinction separately. An assignment does not act and does not supply authority; cite its directly declared relation species and exact obtaining occurrence while still naming the holder System.
A Method, policy episteme, tool, setting, physical condition, resource input, assignment, capability, or record is not another actor merely because it affects the situation. Name its actual direct relation to the temporal behavior, or keep it as an unresolved or source-side intervention claim. Keep authority, WorkPlan, capability, performed Work, and claimed effect separate.
Rhythm, Coasting, and Reversibility
Observed cadence can remain Dyn1. A rhythm claim becomes Dyn2 only when effort pattern, coordination, recovery, stabilization, or another intervention-sensitive use changes the supported action.
For coasting, ask what continues after effort changes or stops, why it may continue, over which window, what use that reading supports, and what change reopens it. Possible bases include habit, automation, stored work, queue pressure, learned capability, commitment momentum, social norm, physical inertia, or unknown; these are examples, not proof.
Keep coasting and debt distinct. Coasting describes continued movement or stability. Debt or hysteresis describes what remains and how costly reversal or recovery is. A claim may need both. Rework, service demand, quality loss, burnout, hidden queues, risk, or coordination cost can appear after acceleration. Reversibility may be unknown; that bounds use instead of forcing a theory.
Boundary-Crossing Header
Most uses stop at the one-screen card. When an exact beyond-local use depends on another pattern result, add only this header and exact references:
This profile remains ClaimGraph content in a C.2.1 adequacy episteme whose EntityOfConcern is the exact source episteme or addressed claim denoted by sourceTemporalClaimRef. It is not the ClaimAddress itself, described System, temporal bearer, Work trace, dynamics model, publication occurrence, form, or carrier.
Each activeNeighborResults entry names the actual result kind supplied by its direct pattern. Do not replace a C.16 measurement result, C.28 causal-use result, G.9 parity result, C.26.3 envelope-regulation claim, Work occurrence, evidence relation, or assurance claim with a generic C.27 field.
Archetypal Grounding
The cases come before the rare trigger reference because they show where ordinary work should stop.
Backlog Reduction Planning
Source claim: “Adding two reviewers for two sprints will double the backlog-reduction rate.”
For this case, CheckoutReviewSystem-1 is already independently identified under A.1. The source claim is one exact claim about that System and its backlog measure. The planned staffing change is a WorkPlan input; no performed Work or causal effect is asserted.
This card does not need a boundary-crossing profile for a local plan choice.
Braking to Protect Viability
Source claim: “Slowing rollout for two weeks will keep CheckoutSystem-1 inside its usable envelope.”
The exact C.27.TA claim states the reduced rollout cadence and two-week window. The exact C.26.3 episteme or ClaimAddress states the envelope-regulation claim and identifies CheckoutSystem-1 through its A.1 System identity. C.27 neither creates a viability relation nor copies the envelope schema.
Slower rollout is not a failure to accelerate. It is adequate only for the bounded use stated here; C.26.3 carries the viability claim.
Practice Rhythm
Source claim: “Daily twenty-minute drills stabilize the learner's task rhythm.”
For this case, LearnerSystem-1 is already independently identified under A.1. The exact C.27.TA claim says that LearnerSystem-1 has a daily task-practice cadence during the four-week training window.
Cross-bearer coupling is absent because the claim does not rely on synchronization between bearers. A practice intended for replication also states what timing and effort pattern must be transmitted and what error arises if only static poses or rate words are copied.
Compact Case Bank
Optional Boundary-Trigger Reference
Skip this section for ordinary local diagnosis and planning. It is a trigger-and-destination map, not a form. The examples in each row are representative rather than exhaustive.
Pattern-Use Notes
- A local resistance value of unknown is allowed. It blocks stronger use; it does not force a new theory.
- A historical trend does not supply a control horizon, update rule, constraints, or stability.
- Evidence from policy A does not carry policy B merely because both policies concern the same rate.
- Equal final scores do not erase unequal adaptation windows, effort, rework, validity, or recovery.
- Scalar throughput does not describe a whole multi-object work cycle when interactions and aggregation change the result.
- Metric improvement does not establish System improvement.
- A temporal metric does not become value merely by publication or target use.
- Measurement as action does not make QL relevant by itself.
- Adding fields does not turn a diagnostic or planning claim into a causal, benchmark, promise-like, gate, or assurance claim. That use changes only when the required direct result and supported-use boundary are present.
- Add no thin C.27 echo to every neighboring pattern. The C.27 result cites the direct result only when its supported use relies on it.
Bias-Annotation
Lenses tested: Onto, Prag, Epist, Arch, Gov.
- Onto: source claim, described subject, temporal-aspect claim, adequacy claim, direct relation, publication occurrence, form, and carrier remain distinct.
- Prag: ordinary prose, Dyn0, and Dyn1 remain cheap; the first Dyn2 result fits on one screen.
- Epist: evidence, measurement, model assumption, planning assumption, diagnostic judgement, and causal result are not interchangeable.
- Arch: C.27 keeps temporal-claim adequacy and cites the direct pattern for every other question.
- Gov: a local card does not widen into a budget, gate, benchmark, promise, assurance, or public claim without the direct result required for that use.
Plain speed, acceleration, effort, inertia, rhythm, agility, process, practice, service, and tool-call wording may help recognition. In a technical claim, recover the actual rate, temporal window, input or Work, resistance, exact bearer, and direct relation. This is an ontological recovery rule, not a lexical ban.
Conformance Checklist
Common Anti-Patterns
Consequences and Reopen Conditions
C.27 makes intervention-sensitive temporal claims inspectable while keeping ordinary state and rate prose cheap. Its cost is one small card and exact references only when the receiving use needs them.
Refresh remains proportional:
- a local card needs one reopen trigger;
- a boundary-crossing claim may also need a validity window and evidence currentness;
- G.11 carries refresh orchestration, and B.3.4 carries evidence decay and epistemic debt.
Reopen when, for example:
- a claim, sampling, intervention, baseline, follow-up, or validity window changes;
- a rhythm bearer, temporal reference, rhythm window, proxy, or coupling changes;
- effort, resource, actual System actor, assignment, authority, or availability changes;
- resistance changes because tooling, work mix, queue topology, constraints, or service demand changed;
- a measure becomes a target, gate, dashboard, incentive, or public comparison;
- cross-scale transfer is attempted;
- results reverse, overshoot, oscillate, stall, or become unstable;
- hidden queues, rework, burnout, quality loss, service demand, safety demand, or coordination debt appear;
- the use changes from local diagnosis or planning to benchmark, causal, assurance, promise-like, publication, gate, or formal-model use;
- a coasting, braking, recovery, or stabilization claim outlives its evidence or assumption.
Rationale
The source contribution is the shift from “what is the speed?” to “what effort or input, over which windows, changes rate, rhythm, direction, or stability against what resistance and cost?”
C.27 adopts:
- the state, rate, and intervention-sensitive rate-change distinction;
- effort profiles over time rather than one acceleration word;
- braking, redirection, coasting, recovery, stabilization, and rhythm as legitimate working questions;
- interval-sensitive practice transfer, including the error introduced by copying static poses or rate words without the timing and effort pattern.
C.27 adapts physical vocabulary into authored-claim adequacy and direct FPF relations. It rejects literal force, mass, acceleration, rhythm, or second-order-process kinds, mandatory calculus, universal control theory, and automatic QL relevance.
The pattern is successful when it improves action quality more than paperwork and remains easier not to use than to misuse.
SoTA-Echoing
The source set below is the predecessor's June 2026 evidence basis. It supports the architecture without turning C.27 into a survey. Reopen the source use when newer work changes one of the named obligations.
Source references:
- D2-SRC-1: Статика, динамика первой производной, динамика второй производной.
- D2-SRC-2: Learning-Based Model Predictive Control: Toward Safe Learning in Control, Review on model predictive control: an engineering perspective, and Goal-oriented safe active learning for predictive control using Bayesian recurrent neural networks.
- D2-SRC-3: A Survey of Constraint Formulations in Safe Reinforcement Learning, A Review of Off-Policy Evaluation in Reinforcement Learning, Conservative Q-Learning for Offline Reinforcement Learning, Methods in dynamic treatment regimens using observational healthcare data, and Safe Continual Reinforcement Learning Methods for Nonstationary Environments: Toward a Survey.
- D2-SRC-4: Causal Inference: What If and Causal Inference About the Effects of Interventions From Observational Studies in Medical Journals.
- D2-SRC-5: Performative Prediction, Performative Prediction: Past and Future, and Categorizing Variants of Goodhart's Law.
- D2-SRC-6: OCEL 2.0 and Object-Centric Event Logs: Specifications, Comparative Analysis and Refinement.
- D2-SRC-7: Active Inference: A Process Theory and Embodied decisions as active inference.
- D2-SRC-8: Neural entrainment underpins sensorimotor synchronization to dynamic rhythmic stimuli, A review of psychological and neuroscientific research on musical groove, and Finding the rhythm.
- CT-TIME-SRC: David Deutsch and Chiara Marletto, Constructor theory of time.
Relations
At use time, name the exact source temporal claim, cite the exact C.27.TA claim, write the smallest Dyn2 card only when needed, cite the direct result for any other current question, state what use remains unsupported, and stop.
C.27:End
Temporal Aspect: Time Windows, Rhythm, Cadence, and Currentness
Type: Definitional pattern Status: Stable Normativity: Normative except where a section is explicitly informative
Use This When
Use this pattern when a project needs to state a positive temporal-aspect claim about one exact object or exact claim—for example, its time window, cadence, freshness, recovery timing, or currentness.
Use it when the working question is:
- which time window, interval, duration, latency, cadence, rhythm, synchronization, currentness, freshness, validity window, recovery timing, stabilization timing, trajectory, effort over time, inertia, or refresh condition matters;
- which bearer has that temporal property: system, episteme, work plan, work occurrence, claim, source, benchmark, architecture-selected structure, method description, publication, or project-world object;
- which temporal reference makes the statement reviewable: calendar time, clock time, event order, cycle, sprint, epoch, release train, sampling interval, follow-up interval, or domain-local timing reference; and
- whether the property is merely stated, measured, used in a temporal claim, used in a transformation claim, or used in a work, evidence, or decision relation.
Primary EntityOfConcern. The EntityOfConcern is the independently identified bearer or exact claim being qualified. A temporal label such as cadence, freshness, or recovery timing is a predicate or qualifier in the ClaimGraph; it is not a second entity.
C.2.1 and publication boundary. A materialized temporal-aspect statement is record-shaped ClaimGraph content in one C.2.1 episteme whose effective ReferenceScheme makes the temporal terms interpretable. Changing that claim content identifies another episteme. A changed layout, publication occurrence, form, or carrier can leave the episteme unchanged; those publication objects remain separate under E.24.PUB when availability matters. When the claim depends on another direct relation, cite that relation's exact declaration or independently established occurrence. A PatternID remains an ordinary rule citation and is never a relation reference.
First useful move. State four things in one readable sentence: the exact bearer or claim, the temporal predicate, the temporal reference, and the interval or window.
First result. CheckoutSystem-1 had a weekly release cadence during release train R14. This is enough when the receiving action needs no further distinction. Stop there.
Open the fuller statement only when the receiving use also depends on measurement, an exact scheme or scope, a selected Structure, a source or use boundary, currentness, reopen conditions, coupling, another direct relation, or an explicit rule citation or blocked overread.
What goes wrong if missed. Temporal words become vibe labels. A cadence is named without bearer, a freshness claim has no validity window, a rhythm has no timing reference, a recovery claim has no interval, an architecture trajectory has no changed structure, and a transformation claim smuggles timing into method, mechanism, or evidence.
What this buys. A practitioner can state one positive temporal-aspect claim before selecting C.27, A.3.4, A.3.3, A.15.2, A.15.1, C.16, C.28, G.9, or the relevant evidence, source, gate, or assurance pattern for the receiving use.
Not this pattern when.
- If the question is adequacy or supported use of an authored temporal claim, use
C.27. - If the question is bounded transformation under conditions, use
A.3.4. - If the question is a state-space and transition-law episteme, use
A.3.3. - If the question is work planning or dated work, use
A.15.2orA.15.1. - If the question is measurement construction, rate construction, scale, score, or metric comparability, use
C.16and related characterization patterns. - If the question is causal use of an intervention or policy, use
C.28. - If the temporal phrase is ordinary prose and no practical use changes, do not introduce a C.27.TA statement.
Problem Frame
C.27 previously carried two different concerns. One concern is temporal-claim adequacy: whether an authored claim about speed, rhythm, rate-change, recovery, or stabilization can carry a named use. The other concern is positive temporal subject matter: windows, duration, cadence, synchronization, freshness, currentness, inertia, effort over time, recovery, stabilization, and trajectory as aspects of objects or claims.
The rule content located here addresses the second concern. It lets FPF say "what temporal aspect is in play?" without immediately opening an adequacy card, a dynamics model, a work plan, a causal-use record, or a transformation statement.
Problem
Without C.27.TA:
- Cadence and rhythm become decorative words. A text says "release cadence" or "team rhythm" without naming bearer, interval, timing reference, or use.
- Freshness becomes a vague virtue. A source, benchmark, dashboard, or claim is called current without a validity window or refresh relation.
- Recovery and stabilization hide their interval. A claim says "recover faster" or "stabilize" without saying over which window, after which disturbance, and for which bearer.
- Effort and inertia float free. A text speaks about momentum, residue, stored work, adaptation cost, or resistance without linking it to a temporal window and exact object.
- Transformation absorbs time silently. A transformation statement names a change but leaves timing and ordering implicit, so method, mechanism, work, evidence, and temporal claims get tangled.
Forces
Solution
Definition
A temporal-aspect claim says that one exact object or exact claim has a time-bearing or order-bearing property under a stated temporal reference and interval. The property is claim content, not automatically a temporal claim-adequacy result, dynamics law, work trace, method, mechanism, gate, evidence relation, or permission.
Typical temporal predicates and qualifiers include:
timeWindow;duration;latency;freshness;currentness;validityWindow;cadence;rhythm;synchronization;trajectory;recoveryTiming;stabilizationTiming;effortOverTime;inertiaOrResidue;refreshOrReopenCondition.
These names are predicates or qualifiers inside claim content, not new U.* kinds or locally identified aspect objects.
Temporal Aspect Statement
Use this fuller statement only when the four-part first result is not enough for the receiving use:
When this statement is materialized, the record is ClaimGraph content in one [C.2.1](/generated/patterns/C.2.1) episteme. entityOfConcernRef resolves the exact bearer or exact claim being qualified. aspectPredicate says what is asserted of it; the label does not identify a temporal-aspect object. The first four fields are the normal minimum.
Every remaining field is conditional. Add it only when changing that value could change the claim or the receiving action. PatternID citations tell the reader which rule to apply and assert no relation. If the claim relies on another direct relation, cite its exact declaration and cite an obtaining occurrence only after its predicate passes. There is no generic context field; each optional scheme, scope, Structure, source or use boundary, or local-use condition keeps the identity and test supplied by its direct pattern.
Direct Use and Rule Citation
This table supplies rule citations, not relation occurrences. When another relation is part of the temporal claim, cite that relation's declaration and independently established occurrence through the fields above.
Rhythm, Cadence, And Synchronization
A minimal rhythm or cadence claim still needs only the exact EntityOfConcern, temporal predicate, temporal reference, and window. Coupling, phase, synchronization, entrainment, dependency, or coordination wording appears only when the claim depends on a cross-bearer temporal relation.
Escalation form:
The optional fields appear only when the receiving use relies on them. A PatternID citation identifies the rule used to judge a claim; it is not the coupling relation.
A plain "release cadence" or "workshop rhythm" may remain ordinary prose. It needs C.27.TA when cadence or rhythm changes transformation, work planning, benchmark, source, assurance, coordination, or claim-use decisions.
Currentness, Freshness, And Validity Window
A currentness or freshness claim uses the same four-part minimum: exact EntityOfConcern, current or fresh predicate, reference time or edition, and validity interval or window. A source, benchmark, model, dashboard, or claim may be fresh enough for one use and stale for another.
Add a source-use boundary, currentness condition, refresh condition, or reopen condition only when the receiving use changes when that value changes. Use the direct source, evidence, benchmark, assurance, or refresh pattern for the separate provenance, parity, assurance, or refresh-work claim.
Recovery, Stabilization, Inertia, And Effort Over Time
A recovery, stabilization, inertia, or effort-over-time claim first names the exact EntityOfConcern, temporal predicate, temporal reference, and interval. It becomes a C.27 adequacy question only when an authored claim uses that result for a practical action.
Add the disturbance or starting condition, measured reading, effort, resistance, residue, inertia relation, rule-pattern citation, or direct-relation reference only when the receiving use relies on that distinction. These values do not turn the temporal predicate into a transformation, Work, evidence, value, or assurance relation.
Archetypal Grounding
Release Cadence
CheckoutSystem-1 had a weekly release cadence during release train R14.
This is a complete first result: exact bearer, cadence predicate, release-train reference, and R14 window. It does not by itself say that the cadence is good, that quality improved, that particular Work occurred, or that a promised service level was met. Add further fields only when the next use depends on them.
Source Freshness
A benchmark comparison uses a model report from April and a competitor report from June.
C.27.TA names the source-currentness and validity windows. G.9, source-use, evidence, and benchmark patterns carry comparator parity, provenance, and evidence use.
Architecture Recovery Timing
An architecture move is expected to reduce an interlevel conflict after two release cycles.
C.27.TA states the recovery-timing claim about the exact architecture claim under the release-cycle reference and window. Use A.3.4 for the structure-transformation relation, the direct architecture patterns to identify the selected structure and characteristic, and evidence/result patterns for an observed effect.
Work Rhythm
A review practice depends on a two-day response rhythm across several review positions and participants. This is ordinary readable wording; it does not by itself admit Systems, classify local system-role kinds, create assignments, establish responsibility, or prove that response Work occurred.
Name a local system-role kind or a separate System-classification judgement only when the receiving claim uses that distinction. If it relies on an assignment, cite the directly declared relation species and its obtaining occurrence with the actual participant values, holder, applicability, and extent under A.2.1. An assignment may be current in a plan or availability statement before any response Work occurs; it neither classifies a System nor implies completed Work. Only when the claim says that a System performed dated response Work should it first recover that exact performer through A.13 and let A.15.1 independently admit the Work. Add F.6 only if the temporal account also consumes precise assignment-bound attribution through the same obtaining A.13 assignment; missing or failed F.6 leaves the Work intact.
C.27.TA names the exact EntityOfConcern, rhythm or cadence predicate, temporal reference, and window. When cross-bearer coordination matters, cite the direct coupling-relation declaration and an obtaining occurrence only after its predicate passes; keep the PatternID as a separate rule citation.
Bias-Annotation
Lenses tested: Onto, Prag, Epist, Arch, Gov.
Resisted distortions:
- rhythm-as-vibe: rhythm or cadence appears without bearer, timing reference, and window;
- freshness-as-permission: currentness is treated as permission, evidence, or gate passage;
- time-as-transformation: timing language is treated as the transformation relation;
- dynamics theft: a temporal aspect is treated as a state-space or transition-law episteme;
- measurement theft: a temporal aspect is treated as a completed measurement construction.
Conformance Checklist
Common Anti-Patterns
SoTA-Echoing
Consequences
- C.27 can be narrowed to adequacy and supported use of authored temporal claims.
- A.3.4 gains a clean temporal reference slot without carrying the whole temporal ontology.
- A.3.3 stays the dynamics episteme pattern.
- Use the direct patterns for work planning, actual work, source currentness, benchmark parity, and evidence use.
- Users gain one positive temporal-aspect claim before heavier adequacy, dynamics, causal, benchmark, or assurance patterns are needed.
Relations
- Builds on:
E.24,A.6.5,A.7,C.2.1. - Coordinates with:
C.27,A.3.4,A.3.3,A.15.2,A.15.1,C.16,C.28,G.9, evidence, source, assurance, refresh, and publication patterns. - C.27 consumer boundary:
C.27consumes this exact temporal-aspect episteme or one exactC.2.1 ClaimAddressto its intrinsically identified claim; it adds only the adequacy-for-use claim and does not redefine the bearer, predicate, window, coupling, or currentness fields. - Used by: patterns that need a positive temporal-aspect claim without making a temporal-claim adequacy judgement.
C.27.TA:End
CausalUse-CAL: Causal-Use Questions, Identification, and Realizability
Type: Calculus (C) Status: Stable Normativity: Normative unless explicitly marked informative
Plain-name. Causal-use calculus.
Intent. Help a practitioner decide what a causal-looking claim is supported to say, under which limits, and which narrower statement remains when the support is insufficient.
Primary EntityOfConcern. One exact causal-use question. The claim, estimand or contrast, evidence paths, identification result, estimate, sampling-realizability result, performed sampling and resulting data, simulation result, support result, and downstream decision remain separately identified.
Not a physical ontology. This pattern does not define causation in the world or replace domain science. It supplies a practical interface for using causal evidence and models without promoting association, simulation, or a graph label into a stronger causal claim.
Use This When
Use C.28 when a result is offered as support for a causal effect, intervention, counterfactual comparison, causal fairness claim, causal policy, causal benchmark, or causal explanation. Common cues include:
- “method A improves the outcome”;
- “users who received X did better, so X works”;
- “this policy would have prevented the failure”;
- “the model shows what would have happened”;
- “this fairness metric proves the intervention is fair”; and
- “this benchmark shows that one causal method is better”.
The cue opens a question, not a verdict. Ask what claim is being supported and what use of the evidence depends on that support.
Not this pattern when. If no causal statement or causal evidential reliance is current, stay with the direct pattern: C.16 for measurement, C.27 for temporal change, A.10 for an evidence path, C.11 for choice, C.19 for live-pool policy, C.24 for call planning, D.5 for bias or fairness audit, or G.9 for ordinary parity.
Activation condition. C.28 is needed when causal support changes the statement relied on by a downstream publication, choice, deployment, audit, assurance, policy evaluation, or benchmark. C.28 decides only the causal-support boundary. The downstream pattern still decides whether to publish, choose, deploy, certify, assure, or abstain.
Simulation boundary at entry. A report that only describes simulator output and makes no causal use exits to ordinary model or simulation handling. Simulator output offered as support for an effect, counterfactual, policy, fairness, benchmark, or evidence claim stays in C.28 and must name the model, assumptions, validation, supported causal use, and unsupported use.
What Goes Wrong If Missed
- association becomes an intervention-effect claim;
- a changed metric becomes causal fairness;
- a simulated trace becomes realized counterfactual evidence;
- an estimated number is treated as proof that its estimand was identified;
- support for one population or environment is transported to another without an endpoint or assumption; or
- a support verdict is mistaken for permission to publish, deploy, or certify.
What This Buys
The cheap result states the question, rung, available support components, the common validity threat that matters now, the causal statement supported, the statement not supported, and the next useful step. Heavy profiles appear only when identification, estimation, counterfactual-sampling realizability, actual sampling evidence, transport, target-trial emulation, causal policy evaluation, representation learning, or fairness work is actually current.
First-Minute Questions
- What exact causal-use question is being asked, and which claim-bearing episteme states it?
- Is the intended statement observational, interventional, or counterfactual?
- What is actually available: an evidence path and empirical data regime, an identification or bound result, an estimate, a prospective counterfactual-sampling realizability result, dated sampling Work plus resulting data, or a simulation result?
- Which common validity problem could overturn the use: intervention definition or consistency, time order, confounding, overlap, interference, selection or missingness, measurement, or transport?
- What causal statement or evidential reliance is supported now, and what stronger statement is not?
- Does the downstream pattern have enough basis to make its own decision, or should it abstain, downgrade, or request more evidence?
First Output
The first output may be only this triage:
supportedUse means the causal statement or evidential reliance supported under the named limits. It is not a permission or command. unsupportedUse states the nearby stronger causal statement or reliance that the evidence does not support.
Triage may be the final result when it blocks the overclaim and names the narrower statement. Do not open a durable object merely because a causal word appears.
Adjacent simulation examples. “The simulator produced these traces” with no causal reliance returns keepNonCausalSimulationUse. “The simulated traces support what would happen under policy P” remains inside C.28 and needs simulationResultRef, model assumptions, validation, supported use, and unsupported use.
Problem Frame
FPF already has patterns for measurement, temporal claims, evidence, assurance, choice, exploration, call planning, fairness, parity, and mathematical lenses. Each keeps its own result. Causal support cuts across them, so a small shared interface is needed without turning C.28 into a second version of those patterns.
The practical question is not “which causal vocabulary can we attach?” It is “what does this evidence support us to say about this causal question, and what would overturn that conclusion?”
Problem
Three collapses produce most causal overclaim:
- Rung collapse: observation, intervention, and counterfactual comparison are treated as the same question.
- Support collapse: data regime, identification, estimation, direct sampling, and simulation are treated as one alternative-valued “basis”.
- Authority collapse: an evidential conclusion is treated as publication, choice, deployment, fairness, or assurance authority.
C.28 keeps those distinctions visible while allowing a cheap stop.
Forces
Solution
Use the smallest result that answers the current question:
- triage the claim;
- stabilize the question in a small card when it must be reused;
- run the common threat screen;
- add only the specialist result needed now; and
- issue a small
CausalUseSupportResultwhen another pattern must consume the conclusion.
Public contract and support components
C.28 uses references to actual objects. It introduces no universal kind for a causal-use question, estimand, or potential-outcome contrast.
CausalUseQuestionRefidentifies the exact question content, normally a C.2.1 episteme.CausalEstimandRefidentifies the mathematical target or the episteme that describes it under its direct pattern.PotentialOutcomeContrastRefidentifies the exact contrast or its description.CausalUseSupportResultRefidentifies one C.2.1 result episteme defined below.
Support is composable. A real result may use several components:
These fields answer different questions. Do not compress them into one exclusive value. Each optional specialist ref identifies the exact result or record actually used. Keep a component's own assumptions, uncertainty or sensitivity, supported and unsupported uses, and reopen information with that component when its defining contract requires them; do not copy fields merely to complete a standard list. The common CausalUseSupportResult still states its own supportedUse, unsupportedUse, limits, optional evidence window, and reopenCondition. Naming a specialist subject in prose does not make its result available to a consumer.
CausalEmpiricalDataRegime is a local classification used only when it helps distinguish evidence:
realizedCounterfactualSamplingData is used only when an A.10 evidence path cites dated sampling Work and the resulting sample or data. A realizability result or WorkPlan alone establishes no empirical regime. Model output is recorded separately through simulationResultRef, not as an empirical regime.
Causality-Ladder Rung
- observational: passive observation, natural behaviour, or association;
- interventional: action setting, experiment, policy change, or action effect;
- counterfactual: counter-to-fact, potential-outcome, or unit-history-conditioned comparison.
Lower-rung data may contribute to a higher-rung result only through a replayable identification, bound, or other specialist result. The rung label itself supplies no support.
Causal-Use Claim Kind
Choose the kind by the claim being supported, not by the tool or source. Simulation for a causal claim uses the appropriate claim kind plus simulationResultRef; it does not need a simulation-only claim kind.
Question cards and support result
Use a local card when the question must survive beyond the current sentence:
Use a durable card only for a reusable or consequential claim:
When another pattern needs a stable conclusion, issue this small C.2.1 result episteme:
Its identity and reference follow C.2.1. The result states causal support only. A downstream pattern may cite it as one basis and then make its own decision. undecided supplies no causal conclusion; the downstream pattern decides whether to abstain, seek evidence, or use a non-causal result.
Common causal-validity screen
Run only the questions relevant to the current claim. A live threat either points to an existing specialist field/result or lowers the support result; it does not trigger a mandatory dossier.
Ordinary effect case. A randomized treatment study records interventionWellDefinedOrConsistency=clear, temporalOrdering=clear, positivityOrOverlap=clear, interferenceOrSpillover=notApplicable, selectionCensoringOrMissingness=clear, and measurementErrorOrConstructShift=clear for its declared target and window. The screen points to the trial and estimate results; it does not repeat them.
Countercase. An observational cohort has the right rung label and a plausible estimand, but records exchangeabilityOrConfounding=liveThreat and positivityOrOverlap=liveThreat because severity is unmeasured and one treatment region has no comparator. The resulting support boundary is unsupported until a suitable design, bound, or new evidence closes those threats. “Observational data” was classified correctly; that label does not establish validity.
Identification result
Identification answers whether the estimand can be expressed or bounded from the available data and assumptions. The conclusion must be replayable:
An identified label without an identifying expression or derivation is incomplete. A bounded result cites the bound. A nonidentified result exposes the obstruction or failure witness. Identification is neither a numerical estimate nor direct physical sampling.
Replayable identified case. For treatment_effect_in_population_P, AdjustmentSet_Z is justified as blocking the relevant back-door paths. backdoor_adjustment_derivation_7 states the identifying expression in ordinary terms: compare treated and untreated outcomes within each Z group, then average those differences using the target population's Z distribution. The result cites the data regime, assumptions, expression, and the confounding or overlap change that would reopen it.
Replayable nonidentified case. In a treatment cohort, unmeasured severity affects both treatment and outcome, and no valid adjustment set, instrument, proxy, or useful bound is available. unmeasured_severity_obstruction_3 is the failure witness. The result is nonidentified; reporting an adjusted number does not change that status.
Counterfactual sampling realizability
Use this result to answer whether a declared target distribution can be sampled under current constraints. It is prospective: it does not say that sampling was planned, performed, or yielded data.
A realizable result cites the sampling construction that the decision Method accepts. A bounded result cites its bound. A nonrealizable result exposes the obstruction or failure witness. unclear names what remains unresolved. “Realized counterfactual sampling” never means observing incompatible outcomes for one unit in one realized world.
If the team plans to draw samples, use a separate A.15.2 WorkPlan. If sampling occurs, recover every precise performer's A.13 core and independently admit the dated Work under A.15.1. Add F.6 only when the sampling claim also needs precise assignment-bound attribution. If the samples are used as evidence, cite the resulting data through an A.10 evidence path. Actual sampling support requires both the dated Work and resulting data or evidence ref; neither realizable nor a WorkPlan can stand in for them. Identification from those data, when claimed, is another CausalIdentificationResult.
Applied profiles
Target trial.
An observational emulation keeps the protocol and its mapping to available data as separate results:
Every mapping field identifies the actual mapping. protocolToDataGapAccountRef points to one account that lists the observed gaps or explicitly states that none was found within the declared source and window. The residual-confounding and sensitivity fields remain present even when their bounded result is favourable. Reporting completeness is not a risk-of-bias, identification, or estimate verdict.
Filled target-trial mapping. HypertensionEmulationMap-2025 maps HypertensionTargetTrial-1 to ClinicRecords-2022-2024: age and diagnosis fields implement eligibility; prescription records distinguish the two treatment strategies; the prescription date supplies assignment and time zero; encounter records map the twelve-month follow-up; and the recorded systolic-pressure field maps the outcome. GapRecord-17 states that adherence after prescription is not observed, ResidualConfoundingAssessment-17 retains unmeasured severity as a live threat, and SensitivityMap-17 points to the negative-control and quantitative-bias analyses. The result supports construction and review of this emulation. It does not by itself establish identification, low bias, or a transportable effect; new severity or adherence data reopens it.
Estimation.
At least one identification or explicit design-based basis is required before the estimate supports a causal use. Orthogonal scores, nuisance models, and cross-fitting belong in methodSpecificDetailRefs only when a DML Method is selected. estimationConsistencyResultRef points to the consistency result defined by the selected estimation Method or its direct evaluation pattern; C.28 introduces no universal consistency-result kind.
Counterfactual fairness. Before D.5 uses a counterfactual-fairness support result, its C.28 components cite the identification result and the extra assumptions needed to connect the available data to that counterfactual question. When the fairness conclusion depends on an estimate, they also cite the estimate and its estimationConsistencyResultRef. Without those conditions, return bounded or unsupported; more data, even an unlimited amount of the same data, does not repair missing counterfactual identification or an inconsistent estimator. Associative or interventional fairness claims use their own rung and do not inherit this stronger branch by label.
Non-DML estimate. A randomized trial cites random_assignment_identification_4, trial_data_8, DifferenceInMeansMethod_2, standard_error_result_5, and its attrition sensitivity check. It needs no orthogonal-score, nuisance-model, or cross-fitting fields. The estimate supports only the declared population, outcome, assignment, and follow-up window.
Transport.
Identify every endpoint dimension that differs in the current claim. Population, domain, environment, data-generating regime, and semantic scheme answer different questions. A shared label proves nothing; a semantic Bridge is added only when its F.9 relation independently obtains.
Off-policy evaluation.
Causal representation. Use this record only when variables are learned, selected, or abstracted rather than supplied by the domain:
The record states which interventions and queries the learned or abstracted variables preserve, not that they are causal variables for every query or domain.
Filled representation case. WardStateRepresentation-4 derives three state variables from monitor traces through WardStateAbstractionMethod-2. Its intervention-validity result covers dosage interventions, its invariance result covers the two hospitals in the training and hold-out comparison, and its query-preservation result passes the declared one-step counterfactual query but fails the long-horizon query. The record therefore supports the one-step policy comparison only; a new hospital, sensor scheme, intervention family, or long-horizon claim reopens it.
Graph and calculus names
Use specialist names only when the result depends on them:
These values classify the formal support form. Concrete refs point to the model, diagram, derivation, assumptions, or proof. A graph-class label is not a proof and does not replace the plain statement of what was identified or bounded.
Causal evidence design and Work
Use CausalUseEvidenceDesignRecord when additional evidence could change the support boundary:
The three optional specialist refs are included only when an existing target-trial mapping, off-policy evaluation, or causal-variable representation result shows what additional evidence could change the support boundary. Before execution, cite a MethodDescription or WorkPlan only when used. After execution, cite every precise performer's A.13 core and the independent A.15.1 Work admission; cite F.6 only when precise assignment-bound attribution is also current. If performed counterfactual sampling is used as evidence, also cite the resulting sample or data through evidencePathRefs; Work without output data and data without its Work and provenance path each remain incomplete for that claim. Do not copy performer-kind, assignment, or occurrence mechanics into this record unless one of those facts changes causal validity, safety, authorization, or supported use.
Additional evidence is worth planning only when it can change a material causal statement or downstream decision enough to justify cost, risk, and delay, or when safety or release rules independently require it.
Support is not authority
CausalUseSupportResult.verdict has four values:
supported: the named causal statement or evidential reliance is supported under the stated limits;bounded: only the narrower statement or reliance is supported;unsupported: the claimed causal statement or reliance is not supported;undecided: the available work does not establish a causal conclusion.
The result never authorizes publication, choice, deployment, certification, fairness approval, or assurance. The downstream pattern cites it as one basis, considers its own other conditions, and makes its own decision. Practical guidance such as “report association only” states the remaining evidence boundary; it is not a permission issued by C.28.
Causal action policy class
Use this classification only when policy use changes the causal question:
unknown is an unresolved classification, not a fifth member. Omit the field when the distinction changes no support, comparison, or downstream decision.
Naming and ontology settlement
The public ...Ref names above are local reference contracts, not newly admitted universal kinds. Recover the actual object before choosing a reference:
Do not create a universal object merely to preserve a familiar token. Do not replace plain practitioner sentences with a list of ontology fields when the shorter sentence carries the same distinction and stop condition.
Neighbor selection
Non-Goals
C.28 does not define physical causation, choose one causal school for every domain, certify a graph by naming it, replace domain intervention or outcome definitions, replace measurement/evidence/fairness/choice/assurance/parity patterns, or authorize a downstream action. It also does not require a durable card or specialist profile when triage already blocks the overclaim.
Cheap downgrade library
Payoff check
Keep a causal-use record only when it changes the supported causal statement, blocks a concrete overclaim, changes evidence work, or supplies a real basis to a downstream decision. Remove fields that do none of those things. Prefer triage when it preserves the same boundary.
Publication-unit boundary
When only wording inside one publication unit is unclear, use the publication and wording patterns. Open C.28 only when the wording is relied on causally. A publication decision remains with the publication pattern even after C.28 returns a support result.
Causal-laundering cases
Archetypal Grounding
System. A product team observes better outcomes among recipients of X. Triage returns association support. If the team needs an effect claim, it opens identification or evidence-design work; C.28 does not let the observation decide deployment.
Fairness. A report claims counterfactual fairness after a policy change. C.28 identifies the rung and estimand, exposes the additional counterfactual-identifiability assumptions, and cites an estimate with its consistency result when the audit relies on that estimate. Missing identification or consistency lowers the support result even with more of the same data. D.5 carries the BiasAuditReport@Context and makes the audit conclusion.
Policy. Logged behaviour data are used to evaluate a new policy. The result names both policies, horizon, confounding and overlap checks, transport endpoints when changed, estimate and uncertainty, supported regime, and unsupported unqualified optimality. C.11 or another policy pattern makes the choice.
Causal RL. An online learner combines logged behaviour, interventions, and a counterfactual-data source. The sampling-realizability result explains whether that source can be produced; dated Work and the resulting data path show whether it was produced; a separate identification or estimate result says what follows from it. Replay reward does not become an optimal-action claim.
Evidence Work. A lab's CounterfactualSamplingRealizabilityResult cites its decision Method and positive construction. That result supports planning but claims no sample. The later WorkPlan remains prospective. After sampling, the lab cites dated Work, attribution, and the resulting data in an A.10 evidence path before using realizedCounterfactualSamplingData. Identification from those data remains a separate result.
Simulation. A simulator supports rehearsal and sensitivity analysis under named assumptions and validation. The support result blocks realized-sample and intervention-effect wording. A pure simulator-output report exits C.28 earlier.
Transport. The population is unchanged but the care environment and measurement mechanism differ. The transport result names source and target environments and data-generating regimes, then states the assumptions and formula. A population ref alone would miss the shift.
Benchmark. G.9 compares an observational predictor, intervention optimizer, and counterfactual policy only after it checks rung, estimand, support components, window, and endpoints. The admissible result may be a selected set or abstention rather than a scalar winner.
Bias-Annotation
Watch for causal prestige, simulation laundering, metric proxy substitution, graph sufficiency, feasibility-as-performance, data-without-Work, support-label substitution, and benchmark scalarization. The repair is not more formal vocabulary. Recover the question, support components, live threats, supported statement, unsupported statement, and reopen condition in the shortest form that remains replayable.
Conformance Checklist
- One exact causal-use question remains identifiable from entry to result; question, claim, estimand, evidence, and records are not treated as one object.
- This edition introduces no universal causal-use-question, estimand, or potential-outcome-contrast kind; it uses local refs to actual objects instead.
- Data regime, identification, estimate, sampling realizability, performed sampling evidence, simulation, and transport remain distinct and may be combined.
- A support result states evidence support only; every publication, choice, deployment, fairness, or assurance decision remains with its direct pattern.
- An identified result cites an expression or derivation; a bounded result cites a bound; a nonidentified result cites an obstruction or witness.
- A causal estimate cites an identification or explicit design-based result. Method-family details appear only when that Method is selected.
- The common threat screen routes every live ordinary threat or lowers the result; it is not a mandatory dossier.
- Non-causal simulator reporting and simulation-supported causal use take different routes at first entry.
- A sampling-realizability result cites its decision Method, any derivation used, and the construction, bound, or obstruction required by its status; it claims no Work or data.
- Performed counterfactual-sampling support cites independently admitted dated Work and resulting data or evidence; it cites exact assignment-bound attribution only when the receiving support claim uses it. A WorkPlan or
realizablelabel cannot satisfy this branch. - Evidence design cites each precise performer's A.13 core and the independent A.15.1 Work result; it cites F.6 only when exact assignment-bound attribution is current, rather than copying assignment mechanics.
- Transport identifies every changed population/domain/environment/data-generating-regime endpoint separately from semantic schemes.
- A counterfactual-fairness escalation exposes its additional identification assumptions and, when an estimate is used, estimation consistency before D.5 consumes it.
CausalActionPolicyClasshas the same four members in definition, examples, and consumers; unresolved classification is not a member.- Every specialist field changes support, a downstream decision basis, evidence work, or a reopen condition.
- A target-trial mapping result identifies the observational source and every protocol-to-data mapping, gap, residual-confounding assessment, and sensitivity mapping needed for its bounded use.
- Every retained specialist result that can independently change support can enter
CausalSupportComponentRefs; when it shapes further evidence, the evidence-design record can cite the same result without copying it. - The whole pattern remains understandable to a practitioner without requiring the formal graph vocabulary on the ordinary path.
Common Anti-Patterns and How to Avoid Them
Consequences
The pattern makes unsupported causal claims easier to lower while keeping ordinary triage cheap. Consequential claims become replayable across question, support components, threats, limits, and source window. The cost is additional specialist work only where a stronger causal statement or downstream decision genuinely depends on it.
Rationale
Temporal change, a higher metric, a convincing graph, or a plausible simulator can all be useful without supporting a causal effect. Conversely, observational data can support a causal estimate when an explicit identification result closes the inferential gap. C.28 therefore separates the question from the components that support it and separates that evidential conclusion from downstream authority.
The integrated contract is deliberately plural: SCM and graphical methods, potential outcomes, target-trial practice, design-based identification, causal ML, transport, causal representation learning, causal RL, and causal fairness may supply different specialist results. None is installed as the universal method.
SoTA and lineage
Qualification window. This comparison was reviewed through 2026-08-21. Reopen it when a current contribution is materially superseded, TARGET guidance changes, a specialist branch changes the minimum replay fields, or direct consumers need a different support-result contract.
Why this combination is retained. The 2025 realizability result answers whether samples can be produced; the 2026 completeness and bounding result answers what can be identified from realized Layer-3 data; the 2026 fairness result states extra conditions for one consequential downstream use. Keeping those results separate preserves their different questions while allowing explicit composition. The domain-specific 2026 lines improve selected Methods but do not dominate the small shared interface. This is the current non-dominated contract for a practitioner who needs a cheap causal stop plus replayable specialist results.
Synthesis boundary. No source above establishes the whole C.28 architecture. The orthogonal support components, common threat screen, small support-result interface, support/authority split, and cross-pattern consumer contract are a bounded FPF synthesis. Validate them through filled cases and consumer replay; reopen when they hide a real causal distinction, impose unused apparatus, or fail a practitioner.
Relations
C.16keeps measurements and scales;C.27keeps temporal-claim adequacy.A.10keeps evidence paths and provenance and may cite C.28 support components and result.A.2.4classifies how an episteme is used; it cannot promote simulation output or association into stronger causal evidence.A.15keeps Method, plan, Work, and attribution for interventions, target trials, and sampling.B.3may cite a C.28 result as one basis for a separate bounded assurance result.C.11,C.19, andC.24keep choice, pool treatment, and call planning and consume only the needed causal refs.D.5keeps bias/fairness audit and usesBiasAuditReport@Contextwhen a causal fairness question is consequential or reusable.G.5keeps method dispatch;G.9keeps parity and benchmark conclusions;G.11keeps refresh planning.C.26is used only for a residual quantum-like modelling issue after ordinary causal explanations are tried.
C.29 mathematical-lens relation
C.29 may describe a mapping as abstraction-like, quotient-like, coarse-graining-like, simulation-like, or macro-model-like. It does not decide causal support. When intervention, policy, counterfactual, causal explanation, or causal decision use is current, apply C.28; otherwise record no causal-use claim or the exact blocker.
C.28:End
Mathematical Lens Use
Type: Architectural pattern Status: Stable Normativity: Normative unless explicitly marked informative
Plain-name. Mathematical lens use.
Primary EntityOfConcern. C.29 concerns a declared mathematical-lens use for a stated phenomenon, EntityOfConcern, relation, claim, or structure-bearing situation. The use names the mathematical object, formalism, learned representation, simulation object, local formal position, or mathematical family; the mapping mode; the preserved structure; the lost structure; the visible payoff or obstruction; the declared lens use; any justified blocked overread; and the stop or return condition. Such a use can be stated or cited in FPF-governed wording, pattern examples, method notes, review records, PublicationUnits, decision-facing text, comparison-facing text, bridge-facing text, and assurance-input text. Include a blocked overread only when it passes F.19's plausible-reader test.
Object designation, declaration, and representation discipline. CandidateMathObject is the C.29-local field or designation for the mathematical object selected in one declared mathematical-lens-use claim or note; that object retains its direct kind. The field identifies the selected object for the mathematical representation, explicit correspondence, and preserved/lost-structure account; it does not assert a world-side participant meaning, participation, or use relation. U.Signature(profile=FormalSubstrate) in A.6.0 is a separate formal-declaration episteme use: it declares vocabulary, laws, imports, and applicability and is neither the CandidateMathObject designation nor a position in the selected representation. A direct use relation may be asserted only after a separate direct relation settlement supplies its participant meanings, obtaining predicate, applicability, and identity rule. A.6.1 governs mechanism import or realization when that exact declaration is used in a mechanism; E.18.1 governs P2W carry-through when accepted problem-side material needs the declaration for later work. The same mathematical object may be designated in several epistemes or uses, but the subject pattern is selected by the exact governed object and claim, not by a source-local head word.
Relation-ontology boundary. A formula, query, path, graph, diagram, name, assertion, or definition can represent or state a claim or derivation; it does not make a relation obtain, admit a relation kind, or supply occurrence identity. Resolve those questions first through A.6.P, A.6.RCD, and the direct subject settlement. Use C.29 only for the selected representation, its explicit correspondence, and the preserved and lost structure.
Output boundary. C.29 outputs are lens-use notes, one-line entries, mini-cards, full cards, and neighboring-pattern notes. They state which declared mathematical-lens use is bounded as usable, when to stop or return, and which neighboring FPF pattern defines or constrains any non-lens claim being made. Project approval, work, evidence, assurance, decision, or release use must be recorded through the subject pattern for that use.
Use this when. Use this pattern when a mathematical object, formalism, simulation object, learned representation, or mathematical family is being used to make a project claim more inspectable, or when the lack of such a lens hides preserved structure, lost structure, invariants, obstruction, approximation, or stop condition.
What goes wrong if missed. Mathematical prestige starts acting as evidence, mechanism, architecture, causal proof, assurance, benchmark result, or release confidence; or a useful lens is avoided because no one states what it preserves and what it loses.
What this buys. The practitioner can use mathematics as a bounded lens: name the object, mapping, preserved and lost structure, visible payoff, declared use, neighboring subject pattern, and the condition for stopping or returning to the source.
Not this pattern when. If the current claim is evidence, assurance, causal use, measurement construction, architecture adequacy, work, gate passage, decision, formal signature, mechanism import, or publication use, use the subject pattern and keep C.29 only to the mathematical-lens use portion.
No new U.* from C.29 local lens-use outputs. MathLensUse.OneLine, MathLensUse.MiniCard, MathLensUse.FullCard, MathLensUse.Card@Context, MathLensUseOutputRef, and CC-C29-* are C.29-local instruments. They do not mint U.MathLens, U.MathLensUseRecord, LensKind, MathLensUseCompliance, or a durable record family. Durable names, kinds, or records require an accepted FPF naming and kind decision through F.18, C.3, F.8, and E.9.
First-use card
Use this card before the full card. It is enough for the first use pass unless publication, bridge, assurance input, benchmark, model selection, prediction, formal pattern claim, or repeated cross-case use is being made.
Start with the useful lens decision: choose, apply, bound, replace, or remove a mathematical lens when the mathematical structure changes explanation, decision, prediction, comparison, publication, bridge, assurance input, reusable transfer, or the next lens-use repair. If no next lens-use action changes, keep ordinary prose or write NoMathLensUseNeededNote. If state, transition, measurement, causal use, bridge semantics, temporal adequacy, assurance, selector, benchmark, or release is the claim being made, apply the governing FPF pattern and keep C.29 to the mathematical-lens use part.
Problem frame
FPF already uses mathematical structures in several local patterns. A.6.P asks for stable relation-precision structure during relation precision restoration; A.3.3 governs dynamics; A.19 governs characteristic spaces and structural overlays; C.18.1 and C.19.1 govern scale-law and Bitter-Lesson claims; C.26 contains the separation of a quantum-like lens from physical quantum ontology; F.9 governs cross-context bridges and loss.
The positive need is as important as the guard. In working projects, first-principles mathematical thinking starts from the smallest declared structure that can make a next lens-use action derivable, inspectable, or honestly blocked. A queue can expose waiting and bottlenecks, a state space can expose variables and transitions, a graph can expose dependencies, a metric-space distance or topology can expose comparability limits, a symmetry can expose invariants, a variational principle or constrained optimization functional can expose an extremal condition, constrained variation space, boundary condition, conservation link, or trade-off, an information or probability measure can expose uncertainty, a resource bound can expose realizability limits, and an obstruction can expose where a transfer or simplification stops.
The missing FPF rule is general but narrow: when FPF-governed wording, a pattern example, method note, review record, PublicationUnit, or neighboring-pattern note uses or plausibly needs a mathematical object, formalism, or family for explanation, decision, prediction, comparison, publication, bridge, assurance input, or reusable application, the C.29 application records the useful first-principles modeling structure and its boundary. It names the candidate mathematical object or family, what structure is preserved, what structure is lost, what invariant, lens-bounded distinction, obstruction, diagnostic boundary, or constructive limit becomes visible, which LensUseBoundaryValue value is declared for that use, and where the mathematical-lens use stops.
A C.29 application is justified when a mathematical object is used for explanation, decision, prediction, comparison, publication, bridge, assurance input, or reusable transfer, or when a stable working problem is under-lensed and a cheap candidate lens could expose useful structure for the next lens-use action. Mathematical appearance alone is not enough.
The first lens-use action is not a full-card demand. It is a first-principles entry decision: choose the smallest mathematical structure that changes the next lens-use action, keep ordinary prose when no mathematical structure changes the action, or apply the governing FPF pattern when the claim being made is outside the declared lens use. The result records what the lens preserves, what it loses, what it makes visible, what remains blocked, and where the use stops.
Selected compact formulation:
A useful mathematical lens is compression with invariants and declared losses.
This compact line is retained as a Plain-register orientation, not as a substitute for the card. It keeps the useful metaphor of a lens: a mathematical object can make a hidden structure visible, but only by carrying some structure and dropping other structure. The first practitioner questions are: what survives the transfer, what is lost, what can now be done, and where does the lens stop?
First-minute working situation
A practitioner applying FPF faces a working situation where ordinary prose can hide useful structure, or where a mathematical phrase is already doing work:
- waiting, backlog, bottleneck, or throughput can call for a queue or flow lens;
- state change, stabilization, control pressure, or forecast can call for state-space or dynamics vocabulary;
- dependency, interface, composition, or transfer failure can call for graph, hypergraph, category, operad, or compositional vocabulary;
- similarity, distribution shift, population movement, or shape change can call for metric-space distance, topology, embedding, or optimal-transport vocabulary;
- scale transition, coarse behavior, universality, knee, or scaling pressure can call for coarse-graining, RG, or scaling-law vocabulary;
- probe effects, order effects, context effects, or incompatible frames can call for quantum-like or contextual-probability vocabulary.
The useful first-minute intuition is not “hunt for overclaim.” It is “find the structure that would improve the next lens-use action, then name the limits.” A vivid phrase can remain when the C.29 output records what the lens makes visible, what it does not license, and the exact subject assertion plus subject-pattern locator for any causal, evidence, bridge, dynamics, scale, measurement, assurance, or release claim.
Without a general lens-use discipline, the reader cannot tell whether the phrase is a bounded structure-preserving representation, an analogy-only prompt, an ungrounded ontology import, a local domain model, or prestige language.
Minimum scenario and anti-case set
Positive scenario. A production line is represented as a queueing network. The lens preserves flow, bottlenecks, service rates, and waiting times; it loses human meaning, contractual obligations, rare failure modes, and causal interventions not represented by the network. Stop or change the lens when its assumptions fail or the use depends on one of those losses.
Anti-case. “The organization is a quantum system” is written without a candidate mathematical object, probe distinction or readout distinction, preserved structure, lost structure, LensUseBoundaryValue, or stop condition. The C.29 result is either a downgrade to local metaphor or a repaired use through C.29 and, where relevant, C.26.
Under-lensed anti-case. “The work stream has dynamics” or “this portfolio is a network” is used for a diagnosis that affects prediction, comparison, repair, or stop conditions, but no mathematical object changes what can be predicted, compared, diagnosed, repaired, or stopped. The repair is to choose a cheap candidate lens that exposes useful structure, or keep the sentence as ordinary prose.
False-positive scenario. A Markov kernel appears inside accepted local reliability modeling. If no contested lens-transfer, publication, assurance, bridge, or reusable explanation claim is being made, the claim stays under A.3.3 and does not require a C.29 output.
Intended FPF use-value
C.29 gives a cheap-output choice before any full card or boundary table. Its first job is to help the working reader introduce, choose, repair, bound, or decline a mathematical lens by selecting the cheapest honest output: no C.29 output, a candidate note, a one-line repair, a mini-card, a full card when high-reliance use requires it, or a neighboring-pattern note when the claim being made is outside declared mathematical-lens use. Use it only when the mathematical lens affects a claim or next lens-use action; ordinary local math and decorative prose stay outside C.29. A successful C.29 result makes useful mathematical compression available to FPF as a disciplined modeling action while reducing ontology smuggling, prestige vocabulary, loss-free transfer, causal laundering, bridge duplication, evidence laundering, and assurance laundering.
Problem
Accepted FPF mathematical-lens use criteria are distributed and local:
A.6.Pgoverns relation precision restoration, but not every mathematical-object transfer.A.3.3governs state, transition, observation, validity, constraints, and calibration for dynamics, but not all mathematical representation choices.A.19governs characteristic spaces, structural overlays, comparability, normalization, and bridge-aware state comparison, but not the adequacy of all mathematical lenses.C.18.1andC.19.1govern scale-law and BLP claims, but not non-scale mathematical lenses.C.26is the local precedent for mathematical-lens detachment, but only for quantum-like modeling.F.9governs cross-context semantic bridges, but does not decide whether a mathematical object, formalism, or learned representation is adequate inside one context or as a domain-transferring lens.
There are two symmetric failure modes.
The first failure mode is mathematical under-lensing: a working situation needs a mathematical lens that changes prediction, comparison, diagnosis, repair, or stop conditions, but the record contains only ordinary prose, familiar school math, or a broad family name such as graph, field, space, score, trend, dynamics, or quantum-like without a useful invariant, obstruction, state variable, mapping, scale behavior, rival lens, or action-changing payoff.
The second failure mode is mathematical overread:
a mathematical phrase begins as a helpful representation and then silently becomes ontology, evidence, causality, comparability, assurance, or use-boundary claim.
Forces
Solution - selected answer
Selected answer in one paragraph
C.29 — Mathematical Lens Use is the general FPF discipline for mathematical lenses used in explanation, decision, prediction, publication, comparison, assurance input, bridge, or reusable transfer. It handles two first-use cases, with the positive case first: an under-lensed situation where the next lens-use action can benefit from a cheap first candidate lens; and an existing candidate lens proposed for application, repair, bounding, replacement, or rejection. Its job is to help the reader introduce, choose, apply, limit, replace, or remove a mathematical lens so that a useful next lens-use action survives. A mathematical lens is usable for a declared use when it compresses a phenomenon by preserving declared structure, exposing useful invariants, and producing lens-bounded predictions, distinctions, obstructions, or diagnostic boundaries inside a bounded context. It is blocked for an undeclared or out-of-bound use when it imports source-domain ontology, hides loss under metaphor, treats source prestige as evidence, or licenses claims outside its declared scale, context, validation, bridge, causal, or assurance boundary.
C.29 does not mint MathLens, U.MathLens, LensKind, or any universal FPF lens object. In this pattern, “mathematical lens” names a declared use of a mathematical object, formalism, learned representation, simulation object, or mathematical family under declared mapping, preserved structure and lost structure, LensUseBoundaryValue, declared lens use, and stop condition; the target phenomenon and any claim outside that declared lens use keep their own FPF kinds.
Naming boundary: C.29 governs mathematical-lens use claims. It does not mint mathematical-lens kinds, and it does not govern or create the EntityOfConcern named by a neighboring claim-bearing episteme, Bridge, evidence relation, causal-use relation, assurance score, measurement construction, dynamics semantics, decision record, work record, explanation rendering, comparative review unit, representation transition, coarsened rendering, selector, benchmark, or scale audit. Its outputs are local lens-use outputs unless another accepted FPF pattern names a durable FPF kind.
Mathematical Lens Use Principle
Mathematical Lens Use Principle. A mathematical lens is usable for a declared use when it compresses a phenomenon by preserving declared structure, exposing useful invariants, and producing lens-bounded predictions, distinctions, obstructions, or diagnostic boundaries inside a bounded context. It is blocked for an undeclared or out-of-bound use when it imports source-domain ontology, hides loss under metaphor, treats source prestige as evidence, or licenses claims outside its declared scale, context, validation, bridge, causal, or assurance boundary.
Compact plain form:
A useful mathematical lens is compression with invariants and declared losses.
Register policy: Tech exactness below, Plain metaphor above. Plain phrases such as “structures that survive transfer,” “what the lens makes visible,” and “where the lens stops” are acceptable as recognition aids. When a sentence makes an FPF-kind, relation, evidence, use-boundary claim, causal, assurance, bridge, gate, work, decision, or pattern-application commitment, the corresponding C.29 output recovers the fields named by value and subject patterns.
Zero and first-principles compatibility note: E.1 and E.2 govern the mission and pillar authority. C.29 serves them by making mathematical first-principles lens use inspectable for one declared use: candidate mathematical object, preserved structure, lost structure, visible payoff, bounded lens-use action, neighboring-pattern boundary, and stop condition. It does not replace pillar authority, neighboring subject patterns, ordinary FPF reasoning, or the E.9 design-rationale record for normative changes.
Mathematics is not a prerequisite for FPF use. Ordinary prose is enough when no mathematical structure changes the next lens-use action. C.29 earns its place only when a mathematical object, formalism, learned representation, simulation object, or mathematical family changes explanation, decision, prediction, comparison, publication, bridge, assurance input, reusable transfer, or the next lens-use repair.
Plain and Tech bridge:
State and transition semantics stay with A.3.3; temporal aspects stay with C.27.TA; characteristic spaces and overlays stay with A.19; temporal-use adequacy stays with C.27; scale-law and general method-scale preference claims stay with C.18.1 and C.19.1; architecture scale-preference claims stay with C.31.ASAP; causal-use question and verdict stay with C.28.
Mathematicalization Utility Principle
A mathematical lens is worth introducing only when it changes the working reader's next lens-use action by making at least one first-principles modeling structure visible:
- a declared signature, structure, state variable, transition, or observation map;
- a symmetry, invariant, conservation-like constraint, equivalence, or composition rule;
- a local-global relation, boundary relation, scale variable, coarse-graining rule, scale window, or correspondence condition;
- a variational principle, action, energy, free-energy, loss, or value functional, Euler-Lagrange or stationarity condition, constrained optimization target, dual view, objective vector, or resource trade-off;
- an uncertainty, probability, information, typicality, approximation, sensitivity, or validation boundary;
- an algorithmic, constructive, resource, realizability, implementation, or adversarial limit;
- a bottleneck, obstruction, impossibility, consistency boundary, or failed transfer in the candidate-model space;
- a rival-lens distinction that changes model choice;
- a causal, intervention, or counterfactual preservation question governed by
C.28; - a bridge or export loss governed by
F.9; - a measurement or comparability condition governed by
C.16.
If no next lens-use action changes, keep the text as ordinary prose, downgrade it to a didactic metaphor, or return NoMathLensUseNeededNote. A lens that merely makes prose more impressive is not a successful C.29 result.
First-principles lens-family use
C.29 admits first-principles use only when the principle family changes what the working reader can derive, inspect, compare, observe, or honestly block. The family name is never enough. Each row below is a discovery and recovery discipline: it tells the reader what must be named before claim-bearing mathematical-lens use is bounded for use.
This table is normative as a recovery guide, not as a mandatory taxonomy. A local project may name a closer family, but it must recover the same claim-bearing structure: CandidateMathObject or candidate family, preserved structure, lost structure, visible payoff, lens-use boundary value, and stop condition.
P2W and formal-declaration boundary: when one of these families is used in a P2W carry-through from accepted problem-side material into later work, C.29 still records only the declared mathematical-lens use. A declared formal relation can make mathematical-to-mathematical exactness or near-sameness visible; it does not by itself declare a FormalSubstrate signature, PrincipleFrame, mechanism, observation-bound world claim, evidence relation, causal-use relation, Bridge-declared lens use, or work. Use A.6.0 for the U.Signature(profile=FormalSubstrate) declaration, A.6.1 when mechanism import or realization is being claimed, and E.18.1 when accepted problem-side material needs a formal declaration for later FPF use.
Bounded-observer structural-information lens
Use this subcase when a mathematical lens estimates, compresses, codes, compares, or otherwise exposes how much selected structure a bounded observer can recover from a description, relation trace, generated graph, model, or reusable-structure accounting result. Typical examples include MDL-like two-part codes, epiplexity-style extracted-structure estimates, compression-complexity comparisons, and information-functionals over relation graphs. The EntityOfConcern remains the declared mathematical-lens use, not the architecture, not the description, and not the observer.
Minimum record:
When the target is a physical, organizational, or project-world situation, the record must say whether the structural-information claim is observational, postulated, simulated, or only a description-local compression. When the lens is used in architecturing, [C.30](/generated/patterns/C.30) governs architecture as EntityOfConcern, [C.30.ASV](/generated/patterns/C.30.ASV) governs structural-view adequacy, [C.30.AD](/generated/patterns/C.30.AD) governs architecture descriptions, and [C.31](/generated/patterns/C.31) or [C.31.RSA](/generated/patterns/C.31.RSA) governs modularity or reusable-structure accounting. [C.29](/generated/patterns/C.29) records only the declared lens use: what recoverable structure the mathematical lens makes visible, what it loses, and where that use stops.
Architecture-local lens descriptions
Architecture work may use C.29-local descriptions for graph, flow, control, structural-information, RG or coarse-graining, and multilevel-learning or frustration lenses. These names are C.29 output descriptions, not architecture ontology, not proof, and not durable FPF kinds by themselves.
MLU.Description@RGArchitecture applies only when the use names a declared aggregation scope, scale variable or scale window, coarse-graining rule, preserved structure, lost structure, source-return condition, declared use, and stop condition. Include a blocked overread only when it passes F.19's plausible-reader test. If the claim becomes a scale-preference claim, C.31.ASAP governs the architecture preference side; C.29 keeps the declared mathematical-lens use.
Minimum RG architecture description:
For architecture work, a common RG-shaped candidate object is:
InterfaceSpecificationRefs_l contains only governed U.EpistemeRef values that resolve independently identified InterfaceSpecification epistemes under the identifying rule located at A.6.M. The references, their resolution, and the specification content remain separate; changing a lens token or retargeting a reference does not edit the specification.
The index _l is a declared aggregation-scope index inside this C.29 lens, not a generic level, tier, layer, or ladder. Each use names the aggregation scope, the coarse-graining rule, the lost structure, and the source-return condition.
MLU.Description@MultilevelLearningFrustration applies only when the use names declared holon levels or declared scopes, a mapping between them, conflicting constraints or residuals, preserved structure, lost structure, and the nearest neighboring FPF pattern for any measurement, causal, evidence, assurance, work, selected-set, or decision claim.
Minimum multilevel-learning and frustration description:
Declared lens use: triage, explanation, candidate generation, rival-lens comparison, scale-window reasoning, source-return triggers, and architecture-decision rationale only when the neighboring pattern defines or constrains any non-C.29 claim. Stop or return when the mapping, scale window, preserved structure, or source basis no longer supports the use. A causal-proof, assurance-score, or necessary-complexity-growth claim needs its own argument and source basis. Apply [C.11](/generated/patterns/C.11), [C.28](/generated/patterns/C.28), [B.3](/generated/patterns/B.3), [C.16](/generated/patterns/C.16), [G.5](/generated/patterns/G.5), or the applicable stakeholder or ethics pattern when its respective non-C.29 claim is current. Include a project-wide-optimizer or other blocked overread only when it passes F.19's plausible-reader test.
Use boundary
This boundary prevents C.29 from being over-applied.
Use C.29 when a mathematical object, formalism, learned representation, simulation object, or mathematical family is used as a lens for explanation, decision, prediction, publication, comparison, assurance input, bridge, or reusable transfer over a physical, organizational, epistemic, social, computational, scientific, or methodological phenomenon, or when a phenomenon, decision, explanation, comparison, model-selection, diagnosis, or method-choice problem is stable enough that the first useful lens-use action is to choose a cheap candidate lens that makes relevant structure visible.
Do not use C.29 as the subject pattern when:
- the mathematics is ordinary local domain theory already governed by a domain pattern;
- the phrase is a purely didactic analogy that is not reused for decisions, evidence, assurance, publication, bridge, comparison, or transfer;
- the question under repair is causal-use question, causal-use justification, or verdict, which is governed by
C.28; - the question under repair is measurement construction, scale construction, direct comparability, or evidence-stub adequacy, which is governed by
C.16; - the question under repair is cross-context meaning or substitution safety, which is governed by
F.9; - the question under repair is dynamics semantics without a separate lens-transfer claim, which is governed by
A.3.3; - the question under repair is a
CharacteristicSpaceoverlay with no domain-transfer, prediction, assurance, publication, or reusable explanation claim, which stays underA.19. - the use under repair makes a different kind of claim: use
C.11for aChoiceResultor local choice record;G.5for selected-set result declaration;G.9for selector or benchmark result claims;A.15,A.15.2, andA.15.1for a selected Method,U.WorkPlan, performedU.Work, or work-result record;E.17for a source-backed publication face and return to source andE.24.PUBfor publication occurrence and availability; orA.15.4for work-relevant appearance-based reliance repair. - the use under repair is an explanation-facing rendering, bounded comparative review unit, same-EntityOfConcern representation-scheme transition, or controlled semantic coarsening; those claims stay with
E.17.EFP,E.17.ID.CR,A.6.3.RT, orA.6.3.CSC, with C.29 fields carrying only mathematical-lens use when the mathematical lens affects the stated declared lens use. - the claim being made is about forecast, rate, trajectory, rhythm, recovery, convergence, stabilization, speed, temporal window, or rate-change as sufficient for use; temporal-claim adequacy stays with
C.27.
This boundary keeps mathematical-lens use from becoming a shadow record for neighboring work.
Lexical rule: use structure-preserving representation rather than structure-preserving identification in discoverability-bearing prose, unless equivalence or identity is explicitly the declared LensMappingMode.
Output choice before the full card
Begin with action guidance, not with the full card.
First action choices: keep ordinary prose, introduce a cheap candidate lens, name the CandidateMathObject or formal position that fits the stated use more directly, add visible payoff, add loss, choose the principal rival lens, add validation regime, narrow an existing claim, downgrade an overclaim, or apply the applicable FPF pattern to any non-lens claim being made.
Memory hook: a successful C.29 application can raise or lower the mathematical claim-bearing use. It can introduce a first candidate lens, keep ordinary domain prose, remove a mathematical lens, repair relation wording through A.6.P, declare a CharacteristicSpace through A.19, use C.16 for measurement and comparability, apply F.9 for bridge semantics, ask the C.28 causal-use question, restore work or source responsibility through A.15, or apply C.27 for temporal-use adequacy.
No-lens cheap output: name the ProblemStructureCue, choose the cheapest candidate lens family that makes it visible, test whether that lens changes the next lens-use action, and if no action changes, keep ordinary prose or collect more observations before using mathematical-lens wording.
First neighboring-pattern map:
Subject-pattern boundary: C.29 coordinates the declared mathematical-lens use across relation-precision structure, state spaces, characteristic spaces, measurement, dynamics, scale, bridge, causal, evidence, assurance, selector, and benchmark patterns. It does not replace any one of them.
- Find the claim-bearing phrase. Mark the mathematical phrase named by value that affects explanation, decision, prediction, comparison, publication, bridge, assurance-input, or reusable transfer.
- Choose the smallest output class that preserves honesty. The output-class decision happens before any full-card fields.
- Name the concrete mathematical object or structure. Family labels such as
category theory,field,graph,quantum,RG, orgeometryare entry prompts, not adequateCandidateMathObjectvalues for the stated use by themselves. - State the lens mapping mode. Use the least committing honest
C.29-local lens mapping mode: analogy-only prompt, representation, empirical fit, simulation, quotient, abstraction, coarse-graining, embedding, homomorphism, isomorphism, functor-like transfer, cross-context lens-transfer candidate, or accepted local theory. If cross-context meaning, substitution, CL, sense cells, or bridge or substitution use is being claimed,F.9governs that claim; the C.29 fields record only mathematical-lens use for the declared transfer. - State preserved structure and lost structure. This is the central repair action.
- State what becomes visible. Name the invariant, obstruction, fixed point, symmetry, conservation law, diagnostic boundary, lens-bounded distinction, model-selection consequence, or other payoff.
- State the declared lens use and stop or return condition. Say what the declared lens use now carries, name the next action, and identify the governing FPF pattern that defines or constrains any claim outside that use. Include a blocked overread only when it passes F.19's plausible-reader test.
- If the claim does not pass, repair rather than merely fail. Downgrade, narrow, switch to a principal rival lens, add
LensUseBoundaryValueor validation regime, split any non-lens claim to its governing FPF pattern, or remove the mathematical phrase from claim-bearing use.
Application output classes:
Micro-template examples:
Architecture and P2W first-use slice:
This filled slice is a C.29 first-use output. Declare a formal signature through [A.6.0](/generated/patterns/A.6.0) and complete P2W carry-through through [E.18.1](/generated/patterns/E.18.1) when those claims are being made. Use [A.15](/generated/patterns/A.15) for method/Work alignment, [A.15.2](/generated/patterns/A.15.2) for a work plan, [A.15.1](/generated/patterns/A.15.1) for performed Work, and [A.15.4](/generated/patterns/A.15.4) for work-relevant appearance-based reliance repair. Evidence, causal-use, and assurance claims use [A.10](/generated/patterns/A.10), [C.28](/generated/patterns/C.28), and [B.3](/generated/patterns/B.3), respectively.
For MathLensUse.OneLine, VisiblePayoff says what the lens makes visible, such as a bottleneck, invariant, obstruction, incompatibility, loss boundary, or diagnostic split. NextLensUseAction says the now-bounded user-facing action, such as compute a local quantity, compare only inside a declared structure, run a validation slice, apply a neighboring pattern, keep the phrase as local metaphor, or remove the phrase from claim-affecting use. ObservationOrReadoutNeeded? names the missing observable, readout, assignment, outcome, validation slice, or scale point needed before the repaired line makes the stated action usable. OrdinaryRivalOrFallback says what the reader would use without this mathematical lens: ordinary prose, accepted local domain theory, direct measurement, a causal model, a queueing model instead of a quantum-like metaphor, an [A.19](/generated/patterns/A.19) space declaration instead of [C.29](/generated/patterns/C.29), or an [F.9](/generated/patterns/F.9) bridge instead of category-like wording. If two mathematical lenses already change the next action at this cheap-output class, add one ordinary-language note about the disagreement and use MathLensUse.MiniCard or MathLensUse.FullCard before claiming a reusable rival-lens relation.
MathLensUse.LensCandidateNote is not evidence, assurance, a bridge, a decision record, a selector result, a literature survey, or a full lens-use card. It is a cheap first-candidate lens selection note. Its successful next outputs are NoMathLensUseNeededNote, MathLensUse.OneLine, or a named neighboring subject-pattern note.
Name guard for this note: ProblemStructureCue is a recognition cue, not a FPF signature; CandidateLensFamily is a family prompt, not a kind; NextLensUseAction is action guidance, not a work record; NextMathLensUseOutput is the next C.29 output class, not a new record family.
Do not use MathLensUse.OneLine with an empty CandidateMathObject. If the candidate object has not yet been named, use MathLensUse.LensCandidateNote first, keep ordinary prose, or write a NeighborGoverningPatternNote when a non-lens claim is being made.
Cheap stop: if the mathematical phrase does not affect any claim beyond orientation, do not use the full card. If the first honest output is NoMathLensUseNeededNote, that is a successful [C.29](/generated/patterns/C.29) result, not an underfilled card.
Output set and declared-use boundary
After applying C.29, the output is one of these:
Positive warning: a successful C.29 output makes the mathematical lens honest for its declared use. Any empirical truth, causal-use, bridge, assurance, release, decision, or benchmark claim still needs its governing FPF pattern.
LensMappingMode, LensUseBoundaryValue, and declared lens use are separate fields.
LensMappingMode names construction, not permission. Typical local values include representation, abstraction, quotient, coarse-graining, embedding, homomorphism, isomorphism, functor-like transfer, simulation, and learned or fitted representation. A broad family name such as graph, field, category, geometry, quantum-like, variational, or Bayesian is only a prompt until the concrete construction and preserved structure and lost structure are named.
LensUseBoundaryValue declares only a limited lens-use boundary:
State the declared lens use in declaredLensUse and its stopping or return boundary in StopCondition. Elegance, familiarity, source prestige, and mapping type supply no substitute for that declaration. Include blockedLensOverread? only when it passes F.19's plausible-reader test. Any empirical truth, causal-use, bridge, assurance, release, decision, or benchmark claim remains a separate neighboring-pattern claim.
From lens to local action
Local action change from a mathematical lens is limited to these cases unless a neighboring pattern defines or constrains the needed non-C.29 use:
- observe or measure a newly named variable or relation;
- compare only under a declared structure and loss boundary;
- diagnose a bottleneck, obstruction, mismatch, invariant, or failed transfer;
- choose or reject a principal rival lens for this local use;
- narrow, downgrade, or block a tempting overread;
- apply the governing FPF pattern when a claim being made exceeds the declared lens use.
Each item closes either as a local C.29 output or as a named neighboring-pattern application. If the needed result is a work plan, choice result, selector output, benchmark, or evidence record, publish that neighboring result in its subject pattern rather than from this list.
No-lens entry: choosing a first candidate lens
Use this when the next lens-use action can benefit from a mathematical lens but no adequate mathematical object has been named. The output is MathLensUse.LensCandidateNote, not MathLensUse.OneLine and not a full card. State the ProblemStructureCue, choose one cheap CandidateLensFamily, say what it could make visible, name the ObservableOrControllableCue? when available, state the NextLensUseAction, compare it with the OrdinaryRivalOrFallback, and stop if no action changes. If the cue is still pre-articulation and no stable ProblemStructureCue can be named, do not mathematize it; preserve cue plurality through C.2.LS, A.16, A.16.1, B.4.1, B.5.2.0, or the relevant language-state pattern before applying C.29.
Candidate guidance rows are examples for first recognition. Use the row that fits the working cue, or state a closer local cue using the same fields.
MathLensUse.LensCandidateNote is local first-candidate guidance. It does not replace G.2 SoTA synthesis, tradition mapping, or broad lens-family review. Use G.2 when the work being done is tradition-scale source synthesis; use C.29 when the local need is to choose one cheap candidate lens that changes the next lens-use action. The cheap observation and control check does not apply C.16 or A.10 by default; it only asks what the user can observe, read out, assign, vary, or validate now. Measurement construction, evidence relation, intervention-use claim, or validation is still governed by the subject pattern when that claim is being made.
First honest C.29 entry cases
For E.11-style first-entry recognition, distinguish the working entry case before choosing an output:
False-positive bank and entry stops
Do not use a C.29 output for these non-use cases unless a separate lens-transfer, publication, assurance, bridge, comparison, or reusable-explanation claim is being made:
- ordinary ODE inside accepted physics or local engineering model;
- Markov kernel inside accepted stochastic dynamics;
- Markov-blanket wording used only as a recognition cue for a physical interface, interface module, component, boundary description, or viability source after the subject pattern has recovered the claim;
- graph used as a local data structure;
- metric-space distance, topology, order, product, subspace, or embedding declared inside
A.19CharacteristicSpacewith no domain-transfer claim; - category-theoretic proof internal to a domain where that formalism is the local theory;
- one-off pedagogical metaphor not reused for decision, evidence, assurance, publication, bridge, comparison, or transfer.
False-negative bank: use C.29 even when no polished mathematical buzzword appears if the working problem has a structure that changes a next lens-use action and ordinary prose is currently hiding it.
Entry guidance states when C.29 is the first subject pattern and when another pattern is first:
C.29 entry stops are: no C.29 output needed, MathLensUse.OneLine used, or a neighboring subject pattern applied.
Subject-pattern boundary table
A C.29 application uses this subject-pattern discipline so mathematical-lens use stays in the C.29 discipline rather than becoming a second authority over neighboring claims.
Positive claim kind:
A C.29 application gives a pattern-local adequacy discipline for claims that use a mathematical object, formalism, learned representation, simulation object, or mathematical family as a mathematical lens for a stated use. The application asks for candidate mathematical object, lens mapping mode, preserved and lost structure, visible invariant or distinction,
LensUseBoundaryValueor validation regime, declared lens use, any justified blocked overread, and stop or return condition.
Boundary application rule: when the claim being made is a choice result, work plan, evidence relation, assurance tuple, explanation rendering, comparative review unit, representation shift, temporal claim, bridge, causal-use claim, measurement claim, scale-law claim, selector, or benchmark, the NeighborGoverningPatternNote names the governing FPF pattern and project-side record. A C.29 application can contribute a lens-bounded prediction, distinction, obstruction, diagnostic boundary, or rival-lens note that the governing record can cite; it does not create that neighboring record.
Mathematical object or learned representation read as world structure: if a model state, embedding, simulator, category, graph, tensor object, vector-store relation, or learned representation is being used as a mathematical lens for a phenomenon, C.29 records only the declared mathematical-lens use. The output must name TargetPhenomenon, CandidateMathObject, LensMappingMode, PreservedStructure, LostStructure, LensUseBoundaryValue or validation boundary, declared lens use, and StopCondition. Measurement, evidence, assurance, dynamics, causal-use, formal-substrate, characteristic-space, publication, benchmark, selector, work, gate, release, or decision claims remain with the subject pattern named in the table below.
MathLensUse.Card@Context shape
MathLensUse.Card@Context is a pattern-local card in C.29. It is not U.MathLensUseCard, U.LensUseRecord, or any universal U.* kind.
Namespace note: MathLensUse.Card@Context, MathLensUseOutputRef, MathLensUse.OneLine, MathLensUse.MiniCard, MathLensUse.FullCard, and CC-C29-* are C.29-local instruments unless they cite existing FPF kinds or refs. MathLensUseOutputRef references the applicable C.29 output for the stated use; it is not a demand for MathLensUse.FullCard. Do not mint generic suffixes such as SystemMathLensUse, MathLensUseQuality, or MathLensUseCompliance. Durable cross-pattern MathLensUse.* names, records, or refs require explicit minting or reuse plus naming, kind, and design-rationale decisions through F.8, F.18, C.3, and E.9; otherwise they remain pattern-local labels.
Read MathLensUse.Card@Context through three aspects:
Validity boundary: mathematical validity of the object under its assumptions is not the same as representational adequacy to the phenomenon; representational adequacy is not empirical validation for a use; empirical validation is not a causal-use verdict; a causal-use verdict is not assurance, release confidence, decision sufficiency, or benchmark superiority.
Conditional fields apply only when the corresponding neighboring claim, claim-bearing use, or publication use is being made:
Plain card gloss. A useful mathematical lens says: what phenomenon is being seen, through which mathematical object, by what mapping, what survives, what is lost, what becomes visible, what lens-use boundary value and validation boundary make this use bounded, the now-bounded user-facing action, the blocked user inference, and where the lens stops.
Conditional overlays
The base card stays light. These overlays are used only when their corresponding use is being made. Ordinary C.29 use does not fill this block; it escalates here only when the claim is already publication-facing, assurance-input, benchmark, bridge, model-selection, prediction, scientific or model, learned-lens, or causal-use facing.
Use the validation overlay when the lens is used for prediction, publication, assurance input, benchmark use, model selection, or scientific claim or model claim. LensUseBoundaryValue alone is then insufficient. Keep the neighboring notions separate: verification is proof or formal checking under stated assumptions; validation is fit for a declared use and regime; calibration aligns model parameters or readouts with observations; explanation states why the lens makes a distinction intelligible. The C.29 output does not let any one of these four labels silently stand in for the others.
Use the learned-lens overlay when the mathematical object is fitted, learned, latent, simulation-trained, data-derived, a neural operator, a surrogate solver, an embedding, or a world-model representation.
Use the following learned-lens stop variants when the declared use reaches the corresponding boundary. Include a separate guard only when it passes F.19's plausible-reader test:
This is not a first-class causal abstraction card. It is a lightweight check: when LensMappingMode is abstraction, quotient, coarse-graining, macro-model, or simulation, and declaredLensUse would include intervention, policy, counterfactual, or causal explanation, apply [C.28](/generated/patterns/C.28) for causal-use question and verdict.
Repair decision table
Field meanings
Neighboring-pattern boundaries
Neighboring patterns remain necessary and are not displaced. A retained neighboring-pattern application note answers the working question for the neighboring pattern being used: what does the reader do with the mathematical lens now? State the neighboring-pattern trigger and the first bounded lens-use action for that neighboring pattern. If a note only repeats that C.29 does not replace a neighbor, keep that boundary in the C.29 subject-pattern table instead of copying generic boundary prose into the neighboring pattern:
A.6.Phandles relation precision restoration.A.3.3handles dynamics semantics.A.19handles characteristic spaces, overlays, normalization, and comparability.F.9handles cross-context semantics and Bridge loss.C.18.1andC.19.1handle scale-law and BLP claims.C.26handles one specific quantum-like lens family.C.28handles causal-use question and verdict.A.10andB.3handle evidence and assurance.C.11,A.15,A.15.1,A.15.2, andA.15.4handle choice results, method and work separation, work plans, performed work, and work-relevant appearance-based reliance repair.E.17.EFP,E.17.ID.CR,A.6.3.RT, andA.6.3.CSChandle explanation-facing renderings, bounded comparative review units, same-EntityOfConcern representation-scheme transitions, and controlled semantic coarsening.C.27.TAhandles temporal aspects;C.27handles temporal-claim adequacy.
Use the C.29 discipline when the question under repair is: Is this mathematical lens adequate for this declared use, and where does it stop?
Naming, ontology, and epistemic precision-restoration account
Name
Name: C.29 — Mathematical Lens Use.
Local namespace: MathLensUse = Mathematical Lens Use. No prior temporary code is reused; the pattern-local card and reference namespace uses MathLensUse; checklist IDs use CC-C29-*.
The stable name is Mathematical Lens Use because C.29 governs a declared use and its use boundary, not intensity on an unnamed scale. Plain prose can still say that a useful mathematical lens compresses many cases while preserving declared distinctions; claim-bearing use is recovered through CandidateMathObject, LensMappingMode, PreservedStructure, LostStructure, LensUseBoundaryValue, and StopCondition.
C.29-local naming guard
MathLensUse.* instruments are C.29-local unless separately admitted. They are not U.* kinds, not durable FPF record families, and not substitutes for U.Kind, KindSignature, KindBridge, BridgeCard, EvidenceGraph, ChoiceResult, U.WorkPlan, U.Work, or assurance records.
Do not mint LensKind, MathLensKind, MathLensUseQuality, MathLensUseCompliance, or MathLensUseRecord from C.29 use.
When one C.29 application needs a mathematical-lens name to become reusable outside that application, use F.18 local-first naming; when it quantifies over a class of described entities, use C.3 Kind-CAL; when it creates or reuses a durable concept or record family, use F.8 minting or reuse and E.9 design-rationale discipline.
Tempting wrong names rejected
Ontology guard selected for FPF
A physical, organizational, or epistemic phenomenon is not directly identified with a mathematical object; it is represented through a mathematical object by an explicitly declared mapping that preserves some structures and loses others.
C.2.P recoveries applied
Archetypal Grounding
Worked micro-cases by failure mode:
Vanchurin-style universe-as-learning is not an ordinary first grounding archetype. Keep it in the validation harness and SoTA use as a candidate stress test: it can teach overclaim control and adapt-not-adopt discipline, but it does not ground accepted physics, assurance, quantitative law, or routine lens use.
Bias-Annotation
Conformance Checklist
C.29 checklist verifies the output-choice discipline without replacing the Solution. Candidate-lens guidance belongs in C.29:4.4.3 or worked grounding, not in this checklist; the checklist verifies only that the cheapest honest output and next lens-use action remain visible.
Common Anti-Patterns and How to Avoid Them
Consequences
Validation harness for stable-pattern review and material refresh
For stable-pattern review or material refresh of C.29, run a small C.29 validation harness. The harness is not a benchmark mandate and not a tool requirement. It is a repeatable validation check that the pattern yields correct first outputs, avoids false positives, preserves neighboring-pattern writing boundaries, and keeps the first useful lens-use action visible.
This subsection governs steward-side validation, not the ordinary C.29 user application. A working user applies the output-choice discipline and chooses the cheapest honest output; they do not run the harness merely to decide between ordinary prose, MathLensUse.OneLine, MathLensUse.MiniCard, or NeighborGoverningPatternNote.
C.29 output-change conditions:
Smallest source-return and output-change conditions:
AI-assisted thin-echo result rule:
C.29 edge-case boundary results:
Harness shape:
Minimum harness cases:
Reader-fit checks for stable-pattern review or material refresh:
Rationale
Why this improves FPF
The selected first-principles position in C.29 is operational, not metaphysical. It treats first-principles mathematical thinking as local construction discipline: declare the smallest structure, rule, invariant, resource condition, observation, or consistency boundary from which the next lens-use action follows or is blocked. In that sense, a C.29 application puts mathematical construction before adequacy control: the reader can introduce a queue, graph, state space, measure, topology, algebraic structure, variational quantity, simulation object, or learned representation when that structure improves the work, and then record the mapping, preserved structure, lost structure, lens-use boundary value, and stop condition.
First-principles mathematical structures can come from several families without turning any one family into an FPF-wide foundation: signatures, logics, axioms, type or abstraction distinctions, symmetries, invariants, compositional structure, local-global relations, scale relations, boundary conditions, variational principles, action, energy, free-energy, loss, or value functionals, constrained optimization structure, probability, information, typicality, algorithmic construction, resource bounds, implementation constraints, consistency boundaries, causal or intervention-preservation questions, operator or function-space mappings, and declared observation maps. Each use still needs declared mapping, preserved structure, lost structure, validation regime or lens-use boundary value, and stop condition.
This fits FPF because FPF already commits to state explicitness, bounded contexts, evidence and assurance, cross-context bridges, open-ended evolution, SoTA alignment, notational independence, and avoidance of ornamental formalism.
C.29 makes an existing discipline explicit: when FPF uses a CandidateMathObject, local formalism, learned representation, simulation object, or mathematical family as a mathematical lens for a stated use, the C.29 application declares what that use preserves, what it loses, what it makes visible, which rival lenses still change the next lens-use action, and where its declared lens use stops.
The compact Plain line remains useful because it points to a real heuristic: good mathematical lenses are not decoration; they are compact ways of seeing structures that survive transfer. The Plain line stays readable, while the card and checklist record the FPF commitments named by value.
Alternatives rejected
Pillar impact analysis
Principle-taxonomy balance
SoTA-Echoing
SoTA source use for C.29 is accepted only when it changes action guidance. A citation that only decorates the file does not establish C.29 use.
C.29 separates source-use relations from source-use disposition. Adopt, Adapt, Reject, and candidate-stress-test disposition say what FPF does with the source; SourceUseRelation says what work the source may perform inside a C.29 application.
Local SourceUseRelation slot discipline:
- source material reference or locator;
- declared C.29 output, lens-use boundary, or
LensUseBoundaryValueaffected by that source; - source-use disposition: adopt, adapt, reject, candidate stress test, recognition cue, source identity locator, checked source-text carrier, or historical background only;
- currentness, supersession, contradiction, narrowing, or demotion condition;
- output-change condition for the C.29 result;
- stop or return condition, and any blocked overread that passes F.19's plausible-reader test.
Sandberg Thread and Structural Sameness Examples
Adopt the Sandberg thread as a recognition cue, with two distinct source-use functions retained: the original X post is the source identity locator, while the Axis of Ordinary Math section is the checked text carrier used here.
The source examples are not a proof source and not an exhaustive taxonomy. They are a checked example carrier for InvariantsExposed: generalized Stokes and boundary-exterior derivative duality; de Rham, cohomology, and topological obstruction; CLT as RG or fixed-point viewpoint; Lawvere-style diagonal family; Noether and symmetry-conservation; and Legendre, potential-duality, and tropical-limit family.
Plain register: the thread illustrates mathematical compression that makes hidden structure visible. Tech register: every FPF use still needs CandidateMathObject, LensMappingMode, PreservedStructure, LostStructure, LensUseBoundaryValue, and StopCondition.
Do not adopt the thread as a proof source, peer-reviewed taxonomy, or authority for all mathematical details.
Vanchurin 2026 as candidate lens
Adopt and adapt the following as a candidate lens family:
learning dynamics → coarse-graining → effective geometry → gauge fields, metric-tensor fields, or distance-like structure → variational or thermodynamic optimality
Use this source as the case for why FPF needs a lens-use card: the source discusses many mathematical structures, but its claims are broad and speculative. The candidate-lens stress-test value comes through trainable variables, local update rules, Legendre transforms, thermodynamic potentials, gauge-field, metric-tensor-field, and distance-language claims, memory and processing trade-offs, and RG-like re-optimization of compressed representations.
The Plain lesson is “this is a useful candidate lens, not a new FPF cosmology.” Selected lens use:
Adoption stance: Adapt, not Adopt.
Adapt:
- learning dynamics as a general language of change,
- resource constraints as a possible source of effective laws,
- coarse-graining as a mechanism for simple macrodescriptions,
- thermodynamic or variational potentials as links between cost, memory, processing, and geometry,
- RG-like re-optimization as a scale-transition discipline.
Do not adopt as FPF norm:
- “the universe really is a neural network,”
- “physics has already been proven from learning,”
- “quantum, GR, or gauge theory reduce to a learning rule or learning dynamics” as established fact.
Known limitations from the checked source-use disposition remain material for mathematical-lens use: non-Abelian gauge fields are not treated as a landed FPF result; thermodynamic RG flow is not treated as a quantitative FPF law; quantitative predictions require explicit learning-algorithm specification.
Plural foundations source-use decision
Adopt the plural-foundations source-use decision: several structural families can be reusable across domains, and their adequacy depends on declared mapping, local use, mutual interpretability, and recoverable loss.
Source-use relation: Rodin supplies source material for the positive decision that several structurally useful families recur across domains. C.29 records this as local adequacy discipline: select the family that fits the declared use, state the mapping, and publish recoverable loss.
Rodin and P2W micro-slice:
Read the slice by the exact governed object and claim. [C.29](/generated/patterns/C.29) governs the CandidateMathObject designation, the selected mathematical representation and explicit correspondence, and the preserved and lost structure stated for that bounded mathematical-lens-use claim or note. It does not assert a world-side participation or direct use relation; such a relation requires a separate direct relation settlement with participant meanings, an obtaining predicate, applicability, and an identity rule. [A.6.0](/generated/patterns/A.6.0) governs the separate formal-declaration episteme when a U.Signature(profile=FormalSubstrate) declaration of vocabulary, laws, imports, and applicability must be written. [E.18.1](/generated/patterns/E.18.1) governs P2W carry-through of the accepted problem-side distinction into the next declared FPF use. If the claim becomes measurement, evidence, causal use, Bridge semantics, mechanism realization, or work, apply [C.16](/generated/patterns/C.16), [A.10](/generated/patterns/A.10), [C.28](/generated/patterns/C.28), [F.9](/generated/patterns/F.9), [A.6.1](/generated/patterns/A.6.1), or [A.15](/generated/patterns/A.15) to that claim being made. Use [A.15.5](/generated/patterns/A.15.5) when the needed result is work-entry readiness.
Applied category theory
Adopt applied category theory as one major organizer for cross-domain transfer, especially composition, interfaces, views, transformations, and bridges. Retain the concrete source examples: databases, electric circuits, and dynamical systems as application families; adjoint functors, enriched categories, and toposes as categorical structures that organize transfer.
In C.29, category-theoretic material is used through the same local adequacy fields as any other lens: stated use, named structure, preserved composition or interface, lost structure, failed transfer, and neighboring-pattern applications. It is especially useful when composition, interfaces, views, transformations, or bridges matter to the bounded lens-use action.
Obstructions to compositionality
Adapt the obstructions and failures-of-compositionality perspective into LostStructure and StopCondition: a lens can be useful precisely because it exposes where transfer fails, not only where it succeeds. In plain language, a good lens does not only say "this transfer holds"; it also names the boundary where transfer stops.
Source locators and source-use guard
SoTA materials are not nameless background. Decision grounds and governing inheritance remain recoverable by value, and SoTA rows shape action guidance rather than decorate the file. The source locators and the source-use relation of each external source are retained here.
Source locators and governing-use rows
Source locators and recoverability.
Source-use boundary notes
VAN-GEOM-LEARNING-2025/2026is a replayable candidate-lens source for geometric learning dynamics. Its useful FPF contribution is the metric-tensor, noise-covariance, and learning-dynamics lens family and the stress it puts onCandidateMathObject,LensMappingMode, preserved and lost structure, validation boundary, and stop condition.- Vanchurin-style physical or biological interpretations remain claims from the cited source unless a local C.29 output and neighboring evidence, causal-use, validation, or assurance pattern bound the use. C.29 does not promote those interpretations to FPF law.
SAND-THREAD-MATH-LINKS-2026-05-12is a recognition cue, not a mathematical proof source or FPF law.- CLT-as-RG or fixed-point wording is retained only as a structural modeling viewpoint. A safe formulation is: under the usual normalization, the Gaussian is an attractive fixed point for finite-variance distributions; other stable laws are other fixed points under suitable normalization.
- The intake correction from direct identification to structure-preserving representation is selected and becomes a central ontology guard.
Informative taxonomy seed
Use this recognition menu only to identify a possible lens family and likely neighboring-pattern applications. After selecting a row, state the local C.29 fields that make the lens adequate or stop the use.
Relations
-
Architecture lens boundary:
C.32.P2S,C.32.PAD, andC.32.ADAmay cite C.29 lens outputs for preserved structure, lost structure, structural information, epiplexity, scale mapping, residual mapping, or source-return. C.29 does not decide the architecture and does not supply evidence, assurance, gate, or quality authority. -
Structural-information adequacy boundary:
C.33,C.34, andC.35may cite C.29 outputs when mathematical-lens results expose captured structure, preserved structure, lost structure, or discovery adequacy. The C.29 output stays local to lens use; it is not architecture adequacy, candidate admission, measurement, eval, evidence, assurance, or project decision authority. -
Builds on:
A.1.1,A.6.P,A.6.RCD,A.3.3,A.19,A.10,A.15,B.3,C.16.P,C.16,E.17.EFP,E.17.ID.CR,A.6.3.RT,A.6.3.CSC,F.9. -
Constrained by:
E.8,E.10,F.19,C.2.P,E.19. -
Design-rationale input:
E.9design-rationale discipline and the source-use rows inC.29:13a. -
Contributes to:
E.2pillar-impact analysis when a pillar argument relies on mathematical first-principles structure; only declared mathematical-lens use is in scope, with no amendment to pillar content, priority, or constitutional authority. -
Coordinates with:
A.6.0,A.6.1,E.18.1,C.11,A.15.1,A.15.2,A.15.4,C.18.1,C.19.1,C.26,C.27.TA,C.27,C.28,C.31.ASAP,G.5,G.9,G.2,G.10. -
Specialization relation:
C.26is selected as a C.29-compatible specialization for quantum-like modeling, with affordability qualifications. -
Neighboring claims stay with their subject patterns. Use
F.9for bridges;C.28for causal use;A.3.3for dynamics semantics;A.19andC.16for characteristic-space and measurement construction;A.10andB.3for evidence and assurance;C.11for decision records;A.15for method/Work alignment,A.15.2for plans, andA.15.1for performed Work;A.15.4for reliance on a misleading appearance;E.17.*for explanation and comparative-review publication use;A.6.3.RTandA.6.3.CSCfor representation transition and coarsening;C.27.TA,C.27,C.18.1,C.19.1, andC.31.ASAPfor temporal-aspect, temporal-claim adequacy, scale-law, method scale-preference, and architecture scale-preference claims; and Part G for selector and benchmark work. C.29 records only the declared mathematical-lens use and the subject-pattern boundary for the claim being made.
C.29:End
Grounded Architecture and Selected-Structure Adequacy
Type: Architectural pattern Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when you need to decide what the architecture of one exact holon (U.Holon) is and what to do next. First distinguish actual relations and a selected structure from a candidate or expected structure, a claim about either, and a description or representation.
For a precise result, recover which subject relations actually obtain, which exact U.Structure is selected from them, whether the direct ArchitectureRelation obtains, what the C.2.1 claim says, the concern and admissible-use frame, and the next architecture move.
The first useful architecture move is small. In ordinary prose, name the holon; say whether the structure is actual, candidate, or expected; name the structure kind and architecture concern; state how any inspected material is being used; and give the next move. If one or two sentences make those values clear, stop.
For example: “For the payment system, the diagram shows a candidate module-interface structure, not an established architecture relation. Next recover the actual dependency relations before deciding whether to replace the fraud-scoring module.” This is already a usable result. Use the card below only when the result must be retained, compared, or handed on:
The card can stop before a durable claim. An actualRelationNamed result requires exact obtaining ArchitectureRelation occurrences and their A.22 structure participants. A candidate, planned, required, desired, expected, modeled, or diagrammed structure remains in candidateOrExpectedStructureRefs and makes no subject relation obtain.
architectureConcernCue is recognition wording only until it helps choose one selected structure kind and one architecture move. When a controlled cue is useful, use changeLocalization, substitutionOrReplacement, flowBottleneck, controlOrRateMismatch, dataCustodyOrStateResidence, physicalSeparationOrPlacement, evidenceReuseOrAssuranceReuse, scaleWindowOrCoarseningLoss, runtimeFailureMode, crossScopeResidual, descriptionViewLoss, or otherDeclared. Local phrases such as change localization failure, hidden crossing, source return, generated-view loss, or state-residence uncertainty may remain in sourcePhrase? or Plain prose. If the described holon, distinction between actual and candidate structure, architecture concern, and first move cannot yet be named, set questionDisposition to concernCueOnly or problemCardReady; wording alone promotes neither a claim nor an obtaining relation.
ArchitectureQuestionCard@Project is a triage aid for choosing one architecture move. questionDisposition records whether to keep a concern cue, prepare a separate ProblemCard, constitute an ArchitectureClaim, or name the pattern for a non-architecture claim. architectureRelationDisposition separately records whether an actual direct relation has been recovered or the content is candidate or expected only. claimPatternRefs contains PatternIDs whose content defines, constrains, or tests any separate claim; it does not identify a pattern-application occurrence. The card is not an evidence record, gate, decision, release record, quality score, risk rating, or publication-use authority claim.
Across C.30, @Project in a record name is a compatibility and retrieval cue only. It identifies neither a project entity nor a composite project U.Work, and it establishes no context, authority, viewpoint, or parthood. When the card is genuinely local to one actual project, projectWorkOccurrenceRef identifies the exact composite U.Work recovered under A.15.6. Include architectureQuestionProjectUseRelationRef only when a named pattern defines the relation by which this card use concerns that Work and an occurrence of that relation obtains. A Work reference alone does not establish project locality. If that locality matters but the relation is not yet defined, record missing-governor; if locality does not matter, omit both project-local fields. Description publication and other project-local uses follow the same rule. A described holon, architecture claim, or architecture relation does not become project Work by retrieval suffix.
Use a conditional ArchitectureDescription bridge only when durable architecture-description use is current: cross-team reuse, regulated or safety use, reusable design, comparison, source or lens reuse, or another named full-mode description use. Ordinary use stops at ArchitectureQuestionCard@Project when it makes one next architecture move clear. If the architecture description itself becomes the EntityOfConcern under repair, use [C.30.AD](/generated/patterns/C.30.AD).
What goes wrong if C.30 is missed: the practitioner reasons from a document, module diagram, transformation-flow graph description, mathematical lens, benchmark, maturity score, or decision record instead of recovering the described holon, selected structures, first architecture move, and non-architecture claim kind.
What C.30 buys in practice: the practitioner stops treating a document or diagram as architecture. They can distinguish actual relations and selected structure from the architecture relation, claim, description, view, representation, publication occurrence, publication form, carrier, and source relation, then choose one small next move.
Do not use C.30 when the question does not concern the architecture of one exact holon, an obtaining ArchitectureRelation, a selected architecture-relevant structure, an ArchitectureClaim, or the thin architecture-description bridge needed for one architecture move. Use the pattern that defines or tests the actual source, description, view, publication-use, or other non-architecture relation. If one piece remains an architecture claim, use C.30 only for that piece. Common non-architecture claim boundaries are summarized in [C.30:12](/generated/patterns/C.30#relations).
Thin precision-restoration pointer: if the issue under repair is still whether architecture, architecture description, structural view, module diagram, model, source material, functional architecture, or a source label such as layer, level, tier, stack, block, expert, cache, router, or gate names an architecture claim, description, view, representation, publication form, source relation, structure, or claim defined or tested by another pattern, use [C.30.P](/generated/patterns/C.30.P) or [C.30.STRAT](/generated/patterns/C.30.STRAT) as triggered before applying C.30 to the recovered architecture portion. If the recovered issue is mathematical-lens use, apply [C.29](/generated/patterns/C.29); when no mathematical-lens use changes the architecture work, keep ordinary prose or use NoMathLensUseNeededNote under C.29 rather than creating a C.30-local lens result. Keep trigger tables in those patterns; C.30 is applied only after an ArchitectureClaim, exact selected architecture-relevant structure, conditional ArchitectureDescription bridge use, [C.30.AD](/generated/patterns/C.30.AD) application, or other claim named by value is recoverable.
Problem
Engineering teams use "architecture" for several different things:
- the selected structure of a holon;
- a diagram, model, table, dashboard, generated relation graph, or document;
- a module layout;
- a selected transformation-flow structure, flow description, or mathematical graph description;
- a functional, control, information, deployment, logical, or physical structure view;
- an ADR-like publication;
- a project-side claim defined or tested by another FPF pattern.
These uses are all useful in ordinary engineering speech, but they cannot carry the same FPF claim. The core distinction is the one already used across FPF: actual subject-relation occurrences; the exact A.22 structure selected from them; the direct ArchitectureRelation that may obtain between that structure and one holon; a C.2.1 claim about the holon, relation, or structure; the Description episteme or view; the representation and publication objects; and any project decision about changing architecture are different objects.
The first-minute practitioner asks four questions:
- Are we recovering an actual architecture relation, considering a candidate structure, or only reading a representation?
- Which subject relations actually obtain, and which exact A.22 structure is selected from them?
- Which structure kind is in view—function, flow, control, module, Work, system-role-kind or assignment, enactor, information, data, placement, deployment, scale, or a declared logical structure—and which adjacent interface, evidence, or assurance relations matter?
- How is the inspected material being used: as claim content, description, view, representation, publication form, decision, source relation, or mathematical lens?
How can FPF describe architecture without:
- creating
U.Architectureas a new root kind; - treating a description, view, diagram, graph, ADR, dashboard, or generated relation graph as the architecture;
- reducing architecture to module structure or interface relation;
- letting E.18 transformation-flow structures, LCA structures, control structures, C.29 lenses, quality language, evidence, assurance, gates, work, or decisions silently become architecture ontology;
- making architecture descriptions so heavy that ordinary practitioners cannot get a first useful architecture move.
Forces
Solution
C.30 starts from one architecture move over one exact U.Holon. Recover separately: any actual subject-relation occurrences; the exact A.22 structures selected from them; any obtaining ArchitectureRelation; the claim episteme that states an affirmative, negative, unresolved, candidate, or expected architecture claim; the concern and admissible-use frame; and the exact use of inspected material as source, description, view, representation, publication form, decision input, or another use defined by its applicable pattern. Use a conditional architecture-description bridge when durable, reusable, multi-view, regulated, comparison, or reliance-bearing description is being made. If an ordinary sentence or ArchitectureQuestionCard@Project gives one usable next architecture move, stop there.
In C.30, the EntityOfConcern is one exact described holon, one exact ArchitectureRelation occurrence, one exact selected structure, or another exact subject object selected by the current claim. A claim episteme, description, diagram, or publication is not a proxy EntityOfConcern for a world-side relation or structure. Description hygiene supports this boundary but is not the center of C.30.
Architecture-description material in C.30 is deliberately minimal. C.30 itself is not the full architecture-description mechanism. It gives a thin bridge from the exact holon, architecture relation, or selected structure to a separately constituted architecture-description episteme only when durable description use changes the architecture move. C.30.AD carries the full general architecture-description EntityOfConcern: multi-view description sets, viewpoint-based views, correspondences, source return, freshness, specification use, and publication boundary. C.30.AD.BA carries built-asset architecture-description, asset-information, digital-twin, and reference-designation specialization. Generic episteme, view, viewpoint, publication, form, representation, and carrier machinery remains with C.2.1, E.17.0, E.17.1, E.17.2, E.17, E.24.PUB, and C.29. C.30.ASV carries the selected-structure-to-view branch; C.30.TFS-REL, C.30.LCA, and other named subpatterns carry their direct structure relations and claims.
C.30 does not mint U.Architecture and does not redefine U.Viewpoint. It defines ArchitectureRelation and the architecture claim form. It also supplies the question card and rules for using selected architecture-relevant A.22 structures in one architecture question, recovering structure kind, concern, admissible use, and inspected-material use, choosing the first move, routing characteristic claims, using small boundary notes, and opening the thin description bridge. It does not make descriptions or views conform merely by form and does not test every structure-specific view. Generic rules about publication, deontic permission, promise, evidence sufficiency, assurance, decision, gate passage, Work authorization, or release authorization remain in the patterns that define or test those claims.
Direct architecture relation and architecture claim
C.30 keeps one subject-side relation and one claim-bearing episteme distinct.
Direct relation kind. ArchitectureRelation is the direct dependent U.Relation defined here between exactly two actual participants:
architectureBearingHolonRef— the exactU.Holonwhose realized organization is at issue; andselectedArchitectureStructureRef— one exactU.Structureselected under A.22 from declared constituents, obtaining subject-relation occurrences, applied constraints and invariants, and an admissible-use frame.
The relation is applicable only when the structure's exact constituents and selected subject-relation occurrences are recoverable for that holon or its admitted constituents and the structure is being used as architecture-relevant organization of that holon. Its obtaining predicate is satisfied only when the selected structure is actually constituted under A.22, every selected subject relation required by that structure passes the obtaining test defined for it, and those constituents and relations organize the exact holon in the declared way. A planned, required, desired, expected, modeled, diagrammed, listed, or merely published structure does not satisfy this predicate.
Occurrence identity is the exact participant pair over one maximal continuous interval during which that predicate remains satisfied. A different holon, a differently identified A.22 structure, or cessation followed by later renewed obtaining yields another occurrence. A changed concern, claim scope, effective reference scheme, description, viewpoint, view, representation, publication, or carrier does not by itself reidentify or create the relation. Ordinary prose may state the readable relation and stop; use A.6.REL only when a later receiver must distinguish this occurrence from another one.
Architecture claim episteme. ArchitectureClaim is an ordinary C.2.1 U.Episteme, not the direct relation and not a new architecture kind:
The C.2.1 identity basis is the exact content, one exact entityOfConcernRef, and effective U.ReferenceScheme. claimScope qualifies what the claim covers. modelUseStructureRef appears only when one independently selected bounded-model-use structure changes structure interpretation or selection for this receiving use. empiricalGroundingRelationRef names a separately obtaining grounding relation; neither grounding nor the optional model-use structure is an ArchitectureRelation participant.
For an affirmative actual claim, every architectureRelationRef resolves to an obtaining occurrence whose participants and predicate satisfy the direct settlement above, and every selectedStructureRef is the exact structure participant of one of those occurrences. A negative, unresolved, candidate, required, desired, or expected claim can remain truthful claim content without an obtaining occurrence; it uses no invented positive reference. A description, diagram, graph, file, list, architecture decision, authoring act, or publication may state or carry the claim, but creates neither its truth nor the subject-side relation or structure.
Earlier consumers may still say “open the ArchitectureOf@Context form in the current C.30 edition.” In this edition that legacy retrieval instruction resolves to the ArchitectureClaim form plus the separate ArchitectureRelation settlement above. The suffix supplies no field, participant, scope, scheme, grounding, project identity, or relation fact, and new records use the current names.
EntityOfConcern bridge. C.30 may make the described holon, one exact ArchitectureRelation occurrence, or one exact selected structure the EntityOfConcern of a claim. A later architecture description independently chooses the exact holon, relation occurrence, or structure it describes under C.2.1; it does not use a claim record as a world-side proxy. Publication occurrences, forms, representations, and carriers remain separate.
Holonic architecture modes
Recover which holonic architecture mode is current before applying MHT, structure, description, or mathematical-lens language:
Evolutionary-engineering architecture candidate bridge
Use this bridge when an open-ended search, quality-diversity archive, current pool, front, or selected set contains possible architecture moves. The archive or front is not yet an actual architecture relation. It becomes C.30 material only when the current claim names the described holon, the existing or candidate structure and structure kind, the affected architecture characteristic, and the next architecture move.
ArchitectureCandidateMove is a thin claim note about a possible structural change. It records why a generated, retained, front-member, or selected-set variant can be considered as architecture material; it is not an obtaining ArchitectureRelation, work plan, local choice result, declared selected-set result, publication occurrence, decision, performed Work, or new kind. Candidate structure content remains modal until the exact structure is constituted and the direct architecture predicate obtains.
For common exits from this architecture question, use [C.18](/generated/patterns/C.18) for archive generation or front maintenance, [C.19](/generated/patterns/C.19) for current-pool treatment, [G.5](/generated/patterns/G.5) for selected-set result declaration, and [C.11](/generated/patterns/C.11) for local choice. If that result is made available to an audience, use [E.17](/generated/patterns/E.17) for a source-backed publication face and return to source, and [E.24.PUB](/generated/patterns/E.24.PUB) for the publication occurrence, form, carrier, audience, bounded use, and availability. Cite [E.11.PUR](/generated/patterns/E.11.PUR) for a recommended FPF pattern use. Use [A.15.2](/generated/patterns/A.15.2), [A.15.5](/generated/patterns/A.15.5), [A.21](/generated/patterns/A.21), or [A.15.1](/generated/patterns/A.15.1) when the move enters planning, work-entry readiness, a gate decision, or performed Work. Keep only the architecture claim here: which holon and current relation are at issue, which candidate structure matters, which characteristic may change, and which next use is admissible.
Architecture-move wording creates no root U.Move, structure, relation, WorkPlan, readiness relation, gate decision, performed work, decision, or source-use claim by itself. When source wording uses “move” outside this architecture-candidate use, restore the concern through [E.10.MOVE](/generated/patterns/E.10.MOVE) and name the pattern that defines or tests the recovered claim.
When the useful next work is synthesizing candidate architecture variants rather than judging or repairing one grounded actual relation, stop the C.30 question card after naming the described holon, the distinction between current and candidate structure, the structure kind, the concern, the admissible-use frame, and the next admissible use. Use [C.32](/generated/patterns/C.32) only to build the candidate architecture palette. When another claim becomes current, use the pattern that defines and tests it. For example, use [A.19.CPM](/generated/patterns/A.19.CPM) for comparison, [A.19.SelectorMechanism](/generated/patterns/A.19.SelectorMechanism) for selector-policy use, [G.5](/generated/patterns/G.5) for selected-set result declaration, [C.11](/generated/patterns/C.11) for final local choice, [C.32.PAD](/generated/patterns/C.32.PAD) for a project architecture decision, [A.10](/generated/patterns/A.10) for evidence, [B.3](/generated/patterns/B.3) for assurance, [A.20](/generated/patterns/A.20) or [A.21](/generated/patterns/A.21) for a gate or release, and [A.15](/generated/patterns/A.15) for Work. For audience publication, use [E.17](/generated/patterns/E.17) for the source-backed face and source return and [E.24.PUB](/generated/patterns/E.24.PUB) for the publication occurrence and audience availability.
Conditional architecture-description bridge
C.30 does not define a second local ArchitectureDescription record shape. C.30.AD:4.1 defines the architecture-use specialization of the canonical C.2.1 episteme. C.30 admits only a thin bridge when durable description use changes the first architecture move.
The minimum bridge recoverable in C.30 is:
This bridge does not mint another description definition, local view-membership relation, subject-side architecture relation, selected structure, or truth fact. It lets the C.30 reader say why an exact description episteme matters for the next architecture move, then applies [C.30.AD](/generated/patterns/C.30.AD) whenever the description itself becomes the EntityOfConcern under repair or the full mechanism is needed: multi-view description-set use, exact viewpoint conformance, correspondence, source return, freshness, specification-use boundary, representation and publication boundaries, or reusable architecture-description use.
An architecture-description freshness claim is canonical in C.30.AD:4.4. C.30 may point to it only to bound admissible use of the first architecture move; it is not empirical grounding, publication currentness, evidence sufficiency, or assurance.
Publication-use boundary
This subsection is the C.30 publication-use boundary. It says what an architecture description or its publication does not carry by itself, while the main Solution stays about the architecture claim, described holon, selected structures, structural views, and next architecture move. If a separate rule concerns deontic permission, promise, prescription, evidence sufficiency, assurance, decision, gate passage, work authorization, release authorization, source authority, or publication-use authority, keep it here, in C.30.AD, or in the description or publication pattern that defines or tests that claim rather than expanding C.30's thin bridge.
ArchitectureDescriptionPublication@Project is subordinate to E.17 and MVPK machinery. It publishes one source episteme or episteme-lane view reference. publicationViewpointRef? names the publication-side viewpoint only when MVPK needs one; it is not an architecture viewpoint and not a TEVB viewpoint. mvpkFaceRef is a publication-lane face reference, not an alternative source episteme, source view, or source relation. Publication does not establish non-publication claims; apply C.30:4.3 and the pattern that defines or tests any current evidence, gate, work, assurance, decision, or release claim.
Model cards, system cards, and evaluation harness reports enter C.30 through the same publication boundary or source-relation boundary. They may describe a model, deployed AI system, architecture claim, evaluation harness, or policy, but the architecture move still needs the actual or candidate structure distinction, an obtaining ArchitectureRelation only when its predicate is satisfied, a bounded ArchitectureClaim when claim content is needed, and the applicable pattern for any proof, release, or gate claim.
If the card or harness is used beyond transparency, recover the architecture structure kind being used first and then apply [A.10](/generated/patterns/A.10), [G.6](/generated/patterns/G.6), [B.3](/generated/patterns/B.3), [A.20](/generated/patterns/A.20), [A.21](/generated/patterns/A.21), [C.16](/generated/patterns/C.16), [C.28](/generated/patterns/C.28), or [C.11](/generated/patterns/C.11) for the non-architecture claim kind.
Architecture name formation
The word architecture is shorthand only after the described holon, selected structures, structure kind, architecture concern and admissible-use frame, and exact use of inspected material as source, description, view, representation, or publication form are recoverable. Without those qualifiers, it is a recovery trigger, not a stable FPF term.
Architecture characteristic assignment
C.30 recovers the exact bearer before any quality, fitness, measure, metric, score, modularity, or ility wording carries an architecture-adequacy claim. Those words are triggers, not stable architecture adequacy by themselves.
An ArchitectureClaim may state a characteristic claim, but the claim episteme is not automatically the characteristic bearer when its content names the holon, direct architecture relation, or selected structure. Select the exact bearer using the pattern that defines or tests that characteristic claim. Likewise, a diagram or publication cannot inherit the subject's quality by describing it.
C.30 keeps only a thin bridge from structural characteristics to Q-Bundle relevance. If the claim says architecture causes an outcome improvement, assign causal use to [C.28](/generated/patterns/C.28). If a structural characteristic is used as a mechanism, constraint, predictor, proxy, evidence relation, or causal hypothesis for a Q-Bundle slot, start with ArchitectureStructuralCharacteristicQBundleClaimLine rather than a formula such as low coupling = maintainability.
ArchitectureStructuralCharacteristicQBundleClaimLine is claim content for first contact, not a U.Relation occurrence or reusable relation declaration:
The line supports an inspectable next question without claiming measurement, modularity score, evidence sufficiency, assurance, gate passage, or causal proof. admittedRelationAndOccurrence is available only when the direct characteristic, evidence, or causal rule defines the relation kind or declaration, participant meanings, obtaining predicate, applicability, and occurrence identity and the referenced occurrences actually obtain. missingGovernor instead names the actual participants, proposed predicate, affected use, and missing definition need. If no defining rule exists for a needed reusable relation, use A.6.RCD; neither a local token, PatternID locator, nor this line admits one.
Minimal structural-characteristic claim-line examples:
ArchitectureCharacteristicQBundleClaim is the triggered full claim episteme. Use it only when publication, comparison, causal use, evidence reliance, assurance, gate, decision, or reusable cross-case reliance needs a durable bounded claim and the thin line cannot keep the content inspectable.
The full claim preserves the older branch's inspectable proposal detail: assertion polarity, the exact structural-characteristic and Q-Bundle-slot referents, scope or scale window, viewpoint when it changes interpretation, qualifiers, witness expectations, admissible semantic change classes, and bridge or loss boundary. These are claim-content fields. They neither declare a reusable relation kind nor make an occurrence obtain; a direct relation still needs an admitted kind, exact participants, a defining predicate and applicability rule, and occurrence identity.
Reusable product-quality vocabularies may supply candidate characteristic names, but they do not become architecture theory. Claim content may connect exact bearers and Q-Bundle slots. A direct relation obtains only when its participants and predicate pass the test defined for it. Use the applicable patterns for measurement, modularity scoring, reusable-structure accounting, bespoke-residue accounting, evidence, assurance, gate, causal, and scale-audit claims.
Relation to structural views
Use C.30.ASV to test structural-view adequacy for an exact architecture-description episteme about one selected structure. E.17.0 separately admits that same episteme as U.View through independently obtaining conformance to an exact viewpoint. C.30 defines direct ArchitectureRelation occurrences, bounded ArchitectureClaim content, and, only for durable description use, how its thin ArchitectureDescription bridge cites exact structural views. Hidden or lost structure, correspondence, source or reliance relations, and source-return boundaries stay explicit when they affect action. C.30.AD defines the full description mechanism.
A diagram, model, table, selected transformation-flow diagram, mathematical graph description, LCA diagram, C.29 lens output, ADR, dashboard, generated explanation, or other publication face may carry an architecture description or an architecture structural view. It does not become the architecture, and it does not become a conforming view only because it looks like a view.
Use AffectedArchitectureStructureNote when the next architecture move needs to name affected structures or view losses without using an architecture decision, ADR, gate, evidence, assurance, or release record:
This note only names affected architecture structure for the next architecture use. For a separate decision, ADR-publication, gate-passage, evidence-sufficiency, or release-authorization question, use the pattern that defines or tests that object or claim.
Minimal boundary notes
Use these notes when a common architecture phrase is close to a claim defined or tested by another pattern but full use of that pattern is not yet needed.
Use the thinnest claim or boundary form that preserves the next architecture move. Use a fuller claim or relation record only when the content or independently admitted relation being used cannot be inspected, compared, refreshed, or bounded without it. Typical thin forms are ArchitectureMathLensUseBoundary before C.29 Mini or Full, AffectedArchitectureStructureNote before an architecture decision record, and ArchitectureStructuralCharacteristicQBundleClaimLine before full measurement, causal, evidence, or reusable direct-relation records.
These notes are not substitutes for the module-and-interface repair pattern named by value, interface specifications, signature records, conformance evidence, or module-and-interface repair. An open or platform label is not substitutability proof, security proof, scale proof, assurance, or universal maturity evidence. A source label such as layer, stack, block, expert, cache, router, or gate enters this note only after [C.30.STRAT](/generated/patterns/C.30.STRAT) recovers a module-interface or adjacent architecture-relevant item. It becomes architecture-relevant only through local structure, interface, variation, substitution, migration, update, and hardening boundaries. Relation-heavy wording inside these notes remains a Plain cue until the relevant module or interface relation is identified, the relation establishing the asserted use is identified, or the pattern that defines or tests the non-architecture claim is named. The note keeps first use honest until that claim kind is recoverable by value.
Architecture mathematical-lens boundary
Architecture descriptions may use C.29 lenses, but the lens does not become architecture ontology.
Use the one-line boundary only when it is enough to keep the lens from being overread. Use a C.29 Mini or Full card when the lens choice, preserved structure, lost structure, relation class or admissible-use value, or stop condition changes the architecture move.
Lens use by architecture problem:
This table is not a C.29 replacement and does not make mathematics mandatory. It helps the practitioner see when a lens may add a useful architecture move; C.29 still carries lens-use result, preserved structure, lost structure, relation class or admissible-use value, and stop condition when those description or view uses are being made.
Epiplexity-like use remains a C.29 bounded-observer structural-information lens. It may help recover learnable structure from traces, but it is not an architecture quality, task relevance proof, causal proof, assurance, or selector authority.
Boundary and repair table
Currentness and smallest reopen. When a decisive input changes, reopen only the C.30 object and use conclusion that depend on it. A changed holon or obtaining subject relation reopens the affected selected structure and, if asserted, the direct ArchitectureRelation predicate; a changed selected structure or predicate result reopens that relation occurrence and any affirmative ArchitectureClaim reference; a changed claim scheme or ClaimScope reopens only that claim; and a changed description, view, source edition, admissible-use boundary, or definition of a directly used relation reopens its exact reference and dependent ArchitectureQuestionCard@Project disposition. Admissible results are to update the affected reference or claim mode, narrow use, re-run the direct predicate, or reopen the card when its next architecture move is no longer supported; unrelated structures, descriptions, and claims stay closed.
Worked slices
"We have the architecture in this diagram." The diagram is a representation or publication form. It creates neither architecture nor U.View; recover an exact ArchitectureDescription episteme and, when view use is claimed, its independently obtaining E.17.0 conformance relation.
"Low coupling gives maintainability." C.30 does not allow that formula to carry the claim by itself. The ordinary repair starts with the thin claim line:
Use ArchitectureCharacteristicQBundleClaim only when publication, comparison, causal use, evidence reliance, assurance, gate, decision, or reusable cross-case claim reliance needs the fuller bounded claim. If repeated use needs an independently admitted direct characteristic, evidence, or causal relation, apply the relation's defining pattern to identify its participants, obtaining predicate, applicability, and occurrence identity and to verify that the occurrence obtains. Do not accept the slogan as architecture truth.
"The backup-pump architecture is safe because the loop is redundant." C.30 starts with the plant holon, operating claim scope, effective reference scheme when local terms need it, and selected structures: control loop, material-flow structure, placement structure, module-interface relation, and maintenance-work relation. The redundancy phrase may motivate an architecture move, but use the applicable patterns for safety proof, causal proof, evidence sufficiency, gate passage, and work authorization. The C.30 output is the selected structure and next architecture move, not a safety case by slogan.
"We replaced the neural-network block, so the architecture improved." Treat block first as a source label and apply [C.30.STRAT](/generated/patterns/C.30.STRAT) unless the changed value is already recovered. The phrase is admissible architecture recognition only after the changed structure kind, transformation-flow relation, module or interface claim kind, preserved and lost structure, changed characteristic, source relation, and pattern for any decision or evidence claim are named. A block label, benchmark result, ablation, pruning mask, or distillation result is not an architecture decision, evidence sufficiency, gate passage, assurance, or architecture adequacy by itself.
Archetypal Grounding
Bias-Annotation
Lenses tested: Arch, Onto, Epist, Prag, Did, Gov. Scope: FPF architecture-description use over holons.
This checklist verifies the preceding guidance after the practitioner has chosen the selected architecture candidate use; it is not a required project control form and not a substitute for the card, note, view, relation, or repair use above.
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
Rationale
Architecture is most useful in FPF when it stays close to actual selected structure over a holon and far away from document-as-architecture, graph-as-architecture, model-as-architecture, and decision-as-architecture collapses. The direct ArchitectureRelation keeps the exact holon and actual selected structure together without minting U.Architecture; an ArchitectureClaim gives practitioners a claim-bearing handle for affirmative, negative, unresolved, candidate, or expected content without substituting that episteme for the relation.
C.30 and C.30.ASV establish an FPF architecture kernel: actual subject relations first; exact selected A.22 structure; direct ArchitectureRelation to the described holon; separately constituted claim, description, viewpoint, and view epistemes; structure-kind discipline; correspondence and source-return boundaries; and characteristic-claim applications. They do not by themselves provide full measurement, synthesis, decision, causal proof, safety proof, or assurance.
The small first move is deliberate. Architecture discussions often need one immediate result: name the holon, choose the structure kind under consideration, recover the exact use of inspected material, identify the pattern for any separate evidence or assurance claim, or stop. One or two ordinary sentences usually suffice. Keep the card only when the result must be retained, compared, or handed on. A full architecture description is useful only when durable publication, cross-team use, comparison, regulated use, source reuse, or reliance-relation reuse is being made.
Exact episteme identity and direct view conformance also preserve plurality. The same holon, architecture-relation occurrence, or selected structure may be described by several independently identified epistemes; one episteme may conform to several exact viewpoints through distinct occurrences; several publications may render one description. C.30 keeps those variants usable without turning any publication form into architecture or any bundle or list into view membership.
SoTA-Echoing
Deliberate exclusion. SysML v2 is not used as C.30 SoTA or useful lineage. Search prominence, a systems-oriented name, and a long-promoted model-and-diagram program are not evidence that it improves the C.30 practitioner questions. For this comparison it is a historical dead end, not a comparator. Reopen this exclusion only if concrete project evidence changes a C.30 rule, worked case, or practitioner action.
Relations
Builds on: A.1, A.22, E.24.PUB, C.30.P, C.2.1, A.6.3, A.7, E.10.D2, E.17.0, E.17.1, E.17, E.17.2, A.6.P, F.18, E.10, and C.2.P.
Coordinates with: C.30.STRAT, C.30.ASV, A.6.F, C.30.TFS-REL, C.30.LCA, C.30.ILC, E.18, C.29, C.16, C.25, C.28, A.10, G.6, B.3, A.20, A.21, A.15, C.11, G.5, E.17, C.32.P2S, C.32, C.32.PAD, C.32.ADR, C.32.ADA, C.33, C.34, and C.35 when problem-to-structure carry-through, candidate-set, architecture-decision, ADR-projection, decision-adequacy, structure-capture, preservation, or discovery-adequacy claim kinds are being made.
For neighboring claims, use A.1 for the described holon, A.22 for a selected-structure EntityOfConcern, C.30.STRAT for stratification-wording and source-label repair, C.30.ASV for structural-view adequacy, C.33 for captured and lost selected-structure adequacy plus source return, C.34 for preservation or correspondence adequacy, C.35 for generated or discovered carrier adequacy before C.32 admission, E.18 for selected transformation-flow structure, path, and crossing discipline, E.18.2 and C.29 for mathematical graph descriptions and mathematical-lens use, C.16 for characterization, C.25 for Q-Bundles, C.28 for causal use, A.10 and G.6 for evidence, B.3 for assurance, A.20 and A.21 for gate or release records, A.15.2 for a WorkPlan, A.15.5 for work-entry readiness, A.15.1 for performed Work, C.11 for decisions, E.11.PUR for pattern-use recommendation, E.10.MOVE for move-like wording outside C.30 architecture-candidate use, and C.32.P2S for the connected problem-to-structure architecturing flow. For publication, use E.17 for a source-backed face and return to source and E.24.PUB for the publication occurrence, form, carrier, audience, bounded use, and availability. Use C.30 to state and test actual ArchitectureRelation occurrences, bounded ArchitectureClaim content, selected structures, and the next admissible architecture candidate use.
C.30:End
Architecture Description Adequacy
Type: Architectural pattern Status: Stable Normativity: Normative unless explicitly marked informative
Plain-name. Architecture-description adequacy.
Intent. Keep an architecture description useful without letting the description, view, diagram, publication, or tool publication face become the architecture itself.
Builds on. C.30, C.30.ASV, A.1, A.22, E.24.PUB, A.7, A.6.3, E.17.0, E.17.1, E.17.2, E.17, C.2.P, E.10, E.10.ARCH, and E.10.D2.
Coordinates with. C.30.AD.BA, C.30.P, C.30.TFS-REL, C.30.LCA, C.30.ILC, C.32.P2S, C.32, C.32.MLAO, C.32.PAD, C.32.ADR, C.32.ADA, A.6.3.NAR, A.19.CPM, A.19.SelectorMechanism, C.18, C.19, G.5, A.6.F, A.6.M, C.29, C.16, C.16.P, A.10, B.3, A.20, A.21, A.15, A.15.5, C.11, C.28, E.8, E.10.MOVE, E.11.PUR, E.24.CD, and F.18.
Use this when
Use this pattern when work must create, inspect, compare, reuse, or rely on an architecture description, a set of such descriptions, a generated view of architecture relations, or a description used as a specification. First name what the description is about: one holon, one ArchitectureRelation occurrence that actually obtains, or one selected U.Structure.
Use it to answer:
- what architecture-side thing each description is about: a holon, an obtaining architecture-relation occurrence, or a selected structure;
- which architecture claim the description carries or lets the practitioner inspect, without confusing that claim with the thing described;
- which selected structures and structure kinds the description covers;
- whether a description really qualifies as
U.View: name the viewpoint and show that the E.17.0 conformance relation actually holds; - how views correspond, which sources enter the use, when a stronger use must return to a source, how fresh the description is, and whether specification use is allowed;
- what the description may guide, what it may not be used for, and what architecture move comes next.
What goes wrong if missed. A diagram, documentation set, generated relation graph, model card, ADR publication set, file, or architecture model is treated as architecture, selected structure, U.View, proof, gate, assurance, decision, work authorization, or release authorization merely because it presents those claims.
What this buys. A reader can tell what each description is about, how its views correspond, where reused material came from, how fresh it is, what it may be used for, and which other claims need their own patterns.
First useful description-use output. In one or two ordinary sentences, say which description is being used, what it describes, which reference scheme gives its terms meaning, why it is being used, which structure matters, what use is allowed, and what architecture move comes next. If you call it a U.View, also name the viewpoint and the conformance relation that actually holds. Stop if this answers the question. Keep ArchitectureDescriptionUseCard@Project only when the result must be retained, compared, or handed on:
@Project is only a retrieval cue. It creates no project, authority, context, viewpoint, parthood, or Work. When an actual project matters, projectWorkOccurrenceRef names the composite U.Work recovered under [A.15.6](/generated/patterns/A.15.6). Include architectureDescriptionProjectUseRelationRef only when a named pattern defines how this description use concerns that Work and the relation actually holds. A Work reference alone is not project locality. If locality matters but the relation is not defined, return missing-governor; otherwise omit both project-local fields.
The card is optional and does not identify the description. For its declared use, it retains the described thing, reference scheme, purpose, selected structures and their kinds, allowed and disallowed use, and the next architecture move or pattern needed for a separate claim. If it calls the description a U.View, it also retains the viewpoint and the conformance relation that actually holds. Use the fuller ArchitectureDescriptionUseAccount only when correspondence, source use or return, freshness, specification or regulated use, comparison, publication, representation, or project locality must remain inspectable. Keep any authority claim in its own pattern and relation.
Not this pattern when.
- If the current use is a grounded architecture claim, an obtaining
ArchitectureRelation, or one first architecture question, use[C.30](/generated/patterns/C.30). - If the current use is a selected structure or structural description outside architecture, use
[A.22](/generated/patterns/A.22). - If the current use is one architecture structural view and its viewpoint-conformance test, use
[C.30.ASV](/generated/patterns/C.30.ASV). - If the current use is built-asset architecture-description, BIM, IFC, asset-information, digital-twin, or reference-designation specialization, use
[C.30.AD.BA](/generated/patterns/C.30.AD.BA). - If architecture or structure wording is still ambiguous, use
[C.30.P](/generated/patterns/C.30.P). - If the current use is only a representation, publication occurrence, publication face or form, report, dashboard, file, carrier, source-expression relation, or publication-currentness relation, use
[C.2.P](/generated/patterns/C.2.P),[E.17](/generated/patterns/E.17),[E.24.PUB](/generated/patterns/E.24.PUB), or the pattern that defines or tests that representation, publication, or source-use claim. - If the description is being used as a pattern-use recommendation, work-entry readiness, evidence, assurance, gate passage, decision, work authorization, causal-use claim, release authorization, deontic permission, or mathematical-lens use, keep
[C.30.AD](/generated/patterns/C.30.AD)only for the description boundary and use the pattern that defines or tests the other claim.
Problem frame
Architecture practice needs descriptions that remain useful over time: multi-view documents, view models, generated relation graphs, transformation-flow views, control sketches, module or interface diagrams, deployment views, model cards, system cards, and architecture-decision description sets. Teams use them to compare, reuse, refresh, and inspect architecture claims. If a project also claims a system-role assignment, Work attribution, authority, or responsibility, keep that as a separate claim: use A.2.1 and F.6 for assignment and Work, and an admitted domain relation or an A.6.RCD missing governor for responsibility. VP.AllocationResponsibility is only a clue to the concern.
A description is not the architecture, an architecture relation that actually holds, or the selected structure. The same holon or relation occurrence can have several descriptions, and a description set can contain several separately identified epistemes. A description counts as U.View only while the E.17.0 conformance relation actually holds between that same episteme and one viewpoint episteme. Different views can hide, lose, coarsen, or emphasize different structures: for example functional, flow, control, module, interface, placement, information-custody, evidence-reuse, assurance, or scale structure.
The first-minute practitioner can ask:
- What holon, obtaining
ArchitectureRelationoccurrence, or selected structure is this description about? - Which ClaimGraph, EntityOfConcern, and reference scheme identify the description?
- Which structures and structure kinds does it describe?
- If it is called a
U.View, which viewpoint and which conformance relation make that true? - What claim or relation connects it to architecture claims and other views without pretending that proximity creates correspondence?
- Which sources, representations, or publications enter this use, by what path, and when must stronger use return to a source?
- After using the description, what architecture move remains admissible?
Problem
How can FPF keep architecture descriptions adequate without:
- treating a description, model, view, diagram, graph, card, table, dashboard, file, publication occurrence, publication form, carrier, or rendering as the architecture, an obtaining relation, or a selected structure;
- treating all architecture documentation as one generic description with no exact EntityOfConcern or selected-structure recovery;
- granting
U.Viewmembership because an episteme was authored, constructed, queried, selected, bundled, diagrammed, or published; - losing the link between one exact viewpoint episteme, the five-part conformance predicate, and the architecture structure kind being described;
- letting one attractive view hide lost structure, stale source, or missing correspondence;
- letting publication quality become empirical grounding, evidence sufficiency, assurance, gate passage, decision claim, work completion, or release authorization;
- making ordinary architecture triage too heavy for a first useful architecture move.
Forces
Solution
An ArchitectureDescription is the local name for a C.2.1 U.Episteme that describes one architecture-side EntityOfConcern: a holon, an obtaining ArchitectureRelation occurrence, or a selected U.Structure. Use the name only when its ClaimGraph makes that subject, the described structures, purpose, and use boundary recoverable. It remains an episteme identified by <ClaimGraph, EntityOfConcern, ReferenceScheme>; it is not a record or a new root kind. A cited ArchitectureClaim is content or trace, not automatically the thing described.
Keep ClaimScope, empirical grounding, concern, viewpoint, view membership, selected model-use structure, representation, publication occurrence, publication form, carrier, project Work, and project-use relation outside that identity triple. Add each only when it independently applies. modelUseStructureRef is optional and appears only when an actually selected DDD model-use structure changes interpretation or selection.
C.30.AD does not mint U.Architecture, redefine U.Viewpoint, or replace generic Description, view, representation, publication, or publication-form machinery. It defines their architecture-description use while keeping every selected architecture-relevant structure directly recoverable.
For built-asset architecture descriptions, BIM, IFC, asset information, digital twins, and ISO/IEC 81346 reference designation, use C.30.AD.BA. C.30.AD keeps the general architecture-description bridge and does not absorb that specialization.
Architecture-description use account
The account points to an already constituted episteme; it is not the episteme and does not add slots to it. Its first three references simply expose the ClaimGraph, EntityOfConcern, and reference scheme that identify the episteme. When the described thing is a relation occurrence or selected structure, the participant trace can still recover its holon. architectureClaimRefs carries relevant claim content or trace; selectedStructureRefs names the structures described, and structureKindRefs classifies them.
Minimum conformance for a retained ArchitectureDescriptionUseAccount:
- the account resolves to one exact architecture-description episteme and exposes its exact ClaimGraph, one exact EntityOfConcern, and effective
U.ReferenceScheme; - actual architecture-relation references identify independently obtaining
ArchitectureRelationoccurrences; required, desired, expected, candidate, unresolved, or negative architecture content stays claim content; selectedStructureRefsnames the architecture-relevant structures being described, andstructureKindRefsclassifies those selected structures;- any cited
ArchitectureStructuralViewis the same description episteme admitted asU.Viewonly by a separately obtaining E.17.0 conformance relation to one exact viewpoint episteme; - cross-view composition uses explicit description-set use claims, correspondence claims, or independently obtaining relations; source use names source-to-use paths; a source-return condition appears only when stronger use requires return to a named source or exact defining or constraining ClaimGraph;
- representation and publication fields identify their own objects and occurrences; they do not establish the description, architecture, selected structure, view membership, empirical grounding, or truth;
admissibleUseandnonAdmissibleUsesay what the description can and cannot carry.
Traceable architecture multi-view description chain
A full architecture description is traceable only when the reader can recover the chain that makes a view useful without turning the view into the architecture or letting a list create view membership. The chain is a trace requirement, not a prescribed method or work plan:
When allocation or responsibility is current, add the exact direct relation separately. A system-role kind or assignment can support the work context but does not establish responsibility; VP.AllocationResponsibility only helps recognize the concern. When a source episteme or source view is used, a source-to-use path joins it to the view or description. Representation adds its own representation relation or object. Publication adds a publication occurrence with its form and carrier kept distinct. Cross-view use adds a correspondence claim or a direct correspondence relation only when its exact predicate obtains. A source-return condition is added only when a stronger use must return from a derivative or reused expression to a named source or exact defining or constraining ClaimGraph.
[E.17.0](/generated/patterns/E.17.0) tests whether the description is a U.View; [C.30.ASV](/generated/patterns/C.30.ASV) tests whether it carries the right selected structure and structure kind. [C.30.AD](/generated/patterns/C.30.AD) records how the description is composed and used: what it describes, which views and correspondence it uses, where source material enters, when stronger use must return to a source, and what architecture move or separate claim remains.
If a needed link is absent, do not substitute a label, query result, bundle, diagram, file, or publication. Add the missing reference or relation that actually holds, narrow the allowed use, or use the pattern that defines how to recover it.
View membership, viewpoint, and structure-kind binding
An architecture description episteme is not a U.View because it is put in a multi-view set, authored under a viewpoint label, constructed by A.6.3, returned by a query, selected, bundled, diagrammed, rendered, or published. First identify the candidate episteme by its C.2.1 identity. Then identify one exact viewpoint episteme and test the fixed five-part E.17.0 predicate. Only a separately obtaining EpistemeViewpointConformanceRelation(candidateEpisteme, exactViewpoint) admits that same episteme as U.View.
When a receiving use needs one multi-view description set, recover an exact collection of independently identified description epistemes under C.13; set membership is ordinary collection membership. A shared file, bundle, heading, graph, publication, or query result neither identifies that collection nor grants U.View membership. The collection keeps no second episteme identity for its members.
C.30.AD can record use of already recoverable architecture structural views inside one description set without minting a local relation kind:
ArchitectureDescriptionViewUseClaim is a C.2.1 episteme about one description set. The block separates what the claim says from the objects that identify it; it does not add slots to the episteme. The claim cannot make anything a U.View or make a view, set, viewpoint, or structure obtain. Each referenced view must already satisfy E.17.0. Use [C.30.ASV](/generated/patterns/C.30.ASV) to check viewpoint conformance and selected structure, [A.22](/generated/patterns/A.22) for structure itself, and [C.30](/generated/patterns/C.30) for an obtaining architecture relation or grounded architecture claim. Use [C.30.AD](/generated/patterns/C.30.AD) only for description identity and use, cross-view correspondence, source use or return, freshness, specification or publication use, and the remaining architecture move.
Common architecture-description views:
Cross-view correspondence, source use, and return conditions
Before combining two views, establish whether they describe the same holon, the same architecture-relation occurrence, the same selected structure, related structures, or different subjects. State that correspondence as a claim or cite a direct relation that actually holds; merely placing views in one file, list, model, or publication creates no correspondence. When source material enters the current use, record its source-to-use path. Add a return condition only when stronger use must go back to a named source or defining or constraining ClaimGraph.
Coarse-graining check. A coarser description groups, omits, or summarizes distinctions found in another description or source. Before relying on it, name the described subject, the finer and coarser description structures, the mapping or correspondence between them, the distinctions kept and lost, and the intended use. These are facts about the descriptions and their use. They do not show that the subject itself has matching levels, parts, or relations. If the decision needs that subject-side claim, establish it separately through the pattern that defines or tests the subject relation; otherwise say only that the description was coarsened.
ArchitectureDescriptionCorrespondenceClaim is a C.2.1 episteme about one description set. The block separates claim content from its C.2.1 identity; it does not add slots or create a world-side relation. Cite a direct correspondence relation only when its predicate is defined, the facts satisfy it, and the relation actually holds. Correspondence helps a reader combine views without changing what each is about; it does not establish proof, grounding, assurance, gate passage, shared subject, or architecture identity.
Freshness and currentness boundary
Use a freshness claim only when the architecture description's admissible use depends on source edition, structure edition, model version, deployment state, or an external condition. Keep this bounded claim distinct from any publication-currentness relation:
ArchitectureDescriptionFreshnessClaim is a C.2.1 episteme about one architecture description. The block separates claim content from its C.2.1 identity. Add a source-return condition only when stronger use must go back to a named source or defining or constraining ClaimGraph. Freshness bounds current use; it does not make the description true, grounded, evidence-sufficient, or publication-current.
Specification-use and publication boundary
An architecture description can be used as a specification only when that use is declared. Specification use is not a new architecture kind; it is a bounded use of an exact description episteme or of one of its publications.
This account records how an existing description or publication is used as a specification. It is not an episteme, relation, MethodDescription, Method, pattern application, or Work occurrence. claimPatternRefs cites PatternIDs for separate claims. When project locality matters, name the composite U.Work and include the project-use relation only if a pattern defines it and it actually holds. If locality matters but the relation is undefined, return missing-governor; otherwise omit both project fields. A project label or this account creates neither Work nor relation.
If specification use is also claimed to be a pattern-use recommendation, work-entry readiness, evidence, assurance, gate passage, performed work, work authorization, decision, causal use, or release authorization, use the pattern that defines or tests that other claim. The description remains only the description boundary.
Keep the description episteme, its possible U.View membership, diagram or other representation, publication occurrence, publication form, and carrier distinct. Authoring, construction, querying, selection, bundling, rendering, filing, or publication creates none of the subject-side architecture relation, selected structure, description truth, empirical grounding, project Work, or project-use relation by itself.
Other claims and applicable patterns
Candidate, front, and selected-set description boundary
An architecture description may also carry a project architecture decision or selected structures cited by an ADR-like publication. Use C.32.PAD for the decision relation, C.32.ADR for its publication projection, and C.32.ADA for decision adequacy. C.30.AD retains only description identity, E.17.0 view conformance, description-set use, correspondence claims or relations that actually hold, source paths and applicable return conditions, freshness, representation, publication use, and specification use.
An architecture description may contain claims about an archive, front, selected set, candidate palette, local choice, or planned architecture move. That content does not turn the description into any of those things or establish recommendation, readiness, authorization, or permission. Use C.32.MLAO and C.32 for candidates, C.18 and C.19 for archives, fronts, and pools, G.5 for a selected-set result, C.11 for local choice, C.30 for the architecture move, C.30.ASV for the structural view, E.11.PUR for recommended pattern use, and A.15.5 or the A.15 family for readiness and Work. If the content is published, use E.17 for the source-backed face and source return, and E.24.PUB for the publication occurrence, form, carrier, audience, bounded use, and availability. C.30.AD still records only the architecture description and its publication use.
For an architecture-description claim, record its C.2.1 identity and only the view conformance, set use, viewpoint, correspondence, source path or return condition, freshness, representation, publication use, and specification use that actually apply. If a source only grounds the first architecture move, use C.30. If it synthesizes alternatives, use C.32 or C.32.MLAO. If it changes which variants are archived, pooled, compared, selected, published, locally chosen, or decided, use the pattern that defines or constrains that relation.
Archetypal Grounding (Worked Cases)
Bias-Annotation
Conformance checklist
Common Anti-Patterns and How to Avoid Them
Consequences
Positive consequences:
- Architecture descriptions become reusable without pretending to be the architecture, an obtaining relation, or selected structure.
- Multi-view work can keep each episteme identity, exact viewpoint conformance, selected structures, cross-view correspondence, source-to-use paths, applicable source-return conditions, freshness, representation, publication, and specification use inspectable.
- Keep description, view membership, representation, publication, empirical grounding, evidence, assurance, gate, decision, Work, project use, release, and mathematical-lens claims distinct, and use the pattern that defines or tests each non-description claim.
- C.30 can stay focused on architecture while C.30.AD carries the heavier description machinery.
Costs:
- A useful architecture document needs explicit links to exact description epistemes, EntitiesOfConcern, effective schemes, selected structures, and admissible use.
- A claimed view additionally needs the exact viewpoint episteme and independently obtaining E.17.0 conformance relation.
- Reused or regulated descriptions may need correspondence refs, source-to-use paths, source and structure editions, applicable source-return conditions, and freshness claims before they can be relied on.
- Familiar diagrams, files, and publication forms lose implicit authority; establish grounding, evidence, assurance, gate, decision, and release claims through their relevant patterns.
Rationale
Architecture work needs descriptions, but a good description is not necessarily a good architecture. A description can guide work only when the reader can identify it, tell what it describes, recover the selected structures and any view conformance, see how it corresponds to other descriptions and sources, and know what use is allowed.
The pattern therefore specializes generic Description and publication machinery for architecture use. It does not mint a new architecture kind, direct subject relation, local view-membership relation, or second meaning of U.View; it does not replace C.30; and it does not let diagrams or documentation formats establish non-description claims by presentation alone.
SoTA-Echoing
Deliberate exclusion. SysML v2 is not used here as SoTA or useful lineage. Search prominence, a systems-oriented name, and long-standing promotion do not show that it improves the practitioner questions above, and this pattern has no project evidence that it does. For C.30.AD it is a historical dead end. Reopen this boundary only if concrete project results change a rule, worked case, or practitioner action in this pattern.
Relations
- Use
C.2.1to identify every architecture-description episteme. - Use
C.30for obtaining architecture relations, selected structures, and bounded architecture claims. C.30.Pnormalizes overloaded architecture or structure wording before this pattern is used.- Use
C.30.ASVto test architecture structural-view adequacy; only E.17.0 conformance admits the same episteme asU.View. - Use
C.33to account for captured and lost structure when a description, generated relation graph, ADR-like record, or view set carries only part of the needed architecture content. - Use
C.34to test preservation or correspondence when comparing a description with another view, source model, generated output, candidate, or realized structure. - Use
C.29for a mathematical-lens or coarse-graining result,C.30.STRATfor level-word admission, andA.22orC.30for the separately supported subject structure or architecture relation. Description-side grouping establishes none of those subject claims by itself. - Use
A.6.3.NARfor a reader-facing narrative made from a description, view set, or decision route. C.30.AD tests description adequacy; A.6.3.NAR handles structure-to-sequence, source carry-through, lost structure, reader use, and return conditions. - Use
C.30.TFS-REL,C.30.LCA, andC.30.ILCfor their named architecture-relation subcases. - Use
C.32.P2Sfor a connected architecturing flow when the description carries only part of the selected structure, decision handoff, method expectation, source continuity, return condition, or feedback from actual structure. - Use
A.7,E.17.0,E.17.1,E.17.2,E.17, andE.24.PUBfor generic EntityOfConcern, view, viewpoint, representation, publication occurrence, form, carrier, and MVPK machinery. C.2.Pnormalizes source-expression, source-to-use, publication-form, and publication-currentness relation-set overreads.- Use
E.11.PURfor recommended FPF pattern use after reading a description; C.30.AD records only the description-use boundary. - Use
A.15.5for work-entry readiness and full-kit condition; use the A.15 family for Work and project-use relations. C.30.AD records only descriptions and their view conformance, set use, correspondence, source paths and returns, freshness, representation, publication use, and specification use. E.10.MOVErestores move-like wording when source prose about an architecture description does not mean a C.30 architecture move or a C.30.AD remaining architecture candidate use.
C.30.AD:End
Built-Asset Architecture Description and Reference Designation
Type: Architecture-description subpattern under
C.30.ADStatus: Stable Normativity: Normative for built-asset architecture-description, reference-designation, model-exchange, and digital-twin use
Builds on. C.30, C.30.AD, C.30.ASV, A.1, A.22, C.2.1, E.17.0, E.17, E.24.PUB, and A.7.
Coordinates with. A.6.P, A.6.RCD, A.6.REL, A.6.F, A.6.M, C.30.TFS-REL, C.30.LCA, C.29, C.16, C.27, C.27.TA, C.28, A.3.4, A.10, G.11, A.15, A.15.1, A.15.5, A.21, A.2.8.PER, A.2.9, B.3, and F.18.
Use this when. Use this pattern when a BIM or IFC publication, asset-information description, reference designation, cost, schedule, operation, maintenance, sustainability, or energy view, or digital-twin description is being used to say something about the architecture of one exact built asset.
What goes wrong if missed. A rich model is treated as the asset or its architecture; a file or multi-view bundle is allowed to select structure or grant U.View membership; or a designation and a live data feed are asked to carry identity, occurrence, truth, and currentness claims that their direct relations do not establish.
What this buys. An engineer can use current built-asset information systems while keeping the physical asset, actual subject relations, exact selected structures, any obtaining ArchitectureRelation, bounded architecture claims, each description episteme, exact viewpoint conformance, each representation and publication object, each designation or reference relation, and each currentness claim inspectably connected but distinct.
Not this pattern when. Use C.30 when the current object is the direct architecture relation or bounded architecture claim, C.30.AD when no built-asset specialization is needed, and C.30.ASV when one structural view is under repair. Use the direct designation/reference, evidence, currentness, Work, decision, transformation, or causal-use pattern when that relation rather than built-asset architecture-description use is current. When auxiliary-view, telemetry, simulation, maintenance, or digital-twin material is used to claim that an intervention caused an effect, route that causal use to C.28; C.27 remains the owner of temporal-claim adequacy. When a twin, dashboard, exchange result, or release screen looks like gate passage, use A.21 only if a current OperationalGate(profile) consumes declared GateCheckRefs and publishes GateDecision plus DecisionLogRef; otherwise keep the display as a cue and return its evidence, work-entry readiness, assurance, Work, or other claim to its own governor. Do not collapse release into gate passage: route a release action or other performed Work to the exact A.15.1 U.Work occurrence, work-entry readiness to A.15.5, a permission result or exercise to A.2.8.PER, an instituting or revoking grant act to A.2.9, and a claim that a subject was released to its named subject predicate and participants; if that predicate cannot be recovered, return A.6.RCD missing-governor. An authorization-looking label does not choose among these claims.
Problem Frame
Built-asset work joins descriptions made for design, fabrication, construction, commissioning, operation, maintenance, adaptation, and decommissioning. A hospital, bridge, plant, railway corridor, or campus can therefore have a geometry model, spatial decomposition, functional and flow descriptions, product and equipment structures, cost and schedule descriptions, operation and maintenance records, sustainability and energy views, asset registers, live telemetry, inspection histories, and several reference-designation schemes.
These are not interchangeable descriptions of one undifferentiated object. They select different structures of the same built asset, or sometimes describe different entities related to that asset. The architect needs to recover which exact EntityOfConcern each description has, which A.22 structure each claimed view describes, how the views correspond, which designation or reference relation makes an entity retrievable, and what currentness boundary permits the description to guide the next architecture move.
Problem
How can an engineer assemble a usable built-asset architecture description from model exchanges, designation systems, and operational information without making the exchange schema, designation code, dashboard, or digital-twin system stand in for the built asset, an obtaining architecture relation, a selected structure, or a conforming view?
Forces
Solution
Start with one intended architecture use, not with the available tool outputs. Name the exact built asset and recover the actual subject-relation occurrences and exact selected A.22 structures that matter. Cite an obtaining ArchitectureRelation only when its C.30 predicate holds; otherwise keep required, desired, expected, candidate, negative, or unresolved content in a bounded ArchitectureClaim.
Constitute each architecture description under C.2.1 about exactly one EntityOfConcern: the built asset, one obtaining ArchitectureRelation occurrence, or one exact selected structure. Keep its exact ClaimGraph and effective U.ReferenceScheme recoverable. The same episteme is a U.View only while a separately identified E.17.0 conformance relation to one exact viewpoint episteme obtains. Then recover reference designation, model exchange, source use, representation, publication, and currentness through their own objects and relations.
For a first controlled use, record only the references needed to make the next architecture move:
This is a project-side use record, not a description identity constructor or a new root kind. @Project is a compatibility and retrieval cue and establishes no project entity, Work occurrence, authority, context, viewpoint, parthood, or use relation. When the use is genuinely local to one actual project, projectWorkOccurrenceRef identifies the exact composite U.Work, and builtAssetDescriptionProjectUseRelationRef identifies the separately governed obtaining relation by which this description use concerns that Work. Otherwise both remain absent.
architectureDescriptionRef resolves to one exact C.2.1 episteme whose identity is the cited ClaimGraph, one exact descriptionEntityOfConcernRef, and effective reference scheme. If that EntityOfConcern is the built asset, it is exactly builtAssetRef. If it is an architecture-relation occurrence or selected structure, its exact participants or selection trace recover builtAssetRef without deriving identity from an optional architecture claim. architectureClaimRefs carry bounded claim content or trace only.
Every value in architectureStructuralViewRefs identifies an exact description episteme admitted as U.View only through an independently obtaining EpistemeViewpointConformanceRelation to one exact viewpoint. It can be the same episteme as architectureDescriptionRef only when that description's one EntityOfConcern is the selected structure required by C.30.ASV; otherwise it is a separately identified description episteme connected through an explicit description-set use or correspondence claim or independently obtaining relation. A multi-view use can cite several such description/view epistemes; the use record, collection, file, bundle, list order, or publication creates neither their identities nor their conformance.
claimScope, architecture concern, empirical grounding, and modelUseStructureRef remain neighboring qualifiers or relations. A DDD-style bounded-model-use structure appears only when that independently selected structure changes interpretation or selection for this use. It replaces none of the asset, relation, structure, description, scheme, scope, grounding, viewpoint, Work, or project-use objects and is absent from base identity.
Use sourceToUsePathRefs when a model publication, exchange, measurement description, or other named expression enters the present architecture use. Use a source-return condition only when stronger use of a derivative or reused description must return to that named source or governing pattern. Keep a diagram or model as representation, and keep publication occurrence, form, and carrier separate. Use [G.11](/generated/patterns/G.11) when description freshness, publication currentness, edition, telemetry freshness, model decay, or synchronization currentness is the claim; none establishes architecture adequacy or empirical grounding by itself.
When ISO 19650 discipline is invoked, cite the exact published part and edition rather than an unversioned series label. At the 2026-07-31 source check, ISO lists ISO 19650-1:2018, Edition 1, and ISO 19650-3:2020, Edition 1, as published editions last confirmed in 2024 and now to be revised, with draft successors under development. The current transfer is therefore exact and bounded: Part 1 contributes whole-life information-management discipline for exchanging, recording, versioning, and organizing information; Part 3 contributes the operational-phase management process and information exchanges. Record the exact standard source and edition in the source-to-use path, the used model or information edition, the reference date and validity window through the currentness loci, the refresh or source-return condition, and admissibleUse and nonAdmissibleUse. A draft or later edition does not silently replace the cited source. ISO 19650 practice contributes information-management discipline, not FPF ontology, subject-relation truth, architecture adequacy, evidence sufficiency, assurance, Work occurrence, or authority.
Recover the selected structures before combining views
For every included view, state the exact candidate description episteme, its selected-structure EntityOfConcern, the architecture concern for which it is used, the exact viewpoint episteme, and the obtaining E.17.0 conformance occurrence. A geometry or coordination model can expose several structures, but the file boundary does not select one structure or grant view membership on the engineer's behalf.
This last row is a distinct recognition-and-routing branch, not a new auxiliary-view kind and not a claim that every such description is an architecture structural view. Admit one as U.View only through the same exact selected-structure EntityOfConcern, viewpoint, and independently obtaining E.17.0 conformance required of every other view; return each embedded claim to the owner named in the row.
A single IFC publication may carry source descriptions for several rows. Conversely, one selected structure may be the EntityOfConcern of several descriptions and may be represented or published several times. C.30.AD.BA therefore keys each use to exact description identity, selected structure, view conformance, built-asset trace, and declared use rather than to a file, platform, package, or view count.
Recover a reference designation as a relation
A reference designation is useful because it makes information about an entity retrievable under an explicit structuring and designation scheme. First recover the exact designation or reference relation through its direct representation/reference/naming owner. C.30.AD.BA records only its built-asset architecture-description use; a code, field, repeated string, list row, or the record below neither admits a relation kind nor makes an occurrence obtain. If no current direct owner supplies the needed relation, keep the designation use as bounded C.2.1 claim content; apply A.6.RCD only when a named repeated receiving use genuinely needs a reusable predicate definition or admitted direct relation.
selectedAspectStructureRef names the exact structure in which the designation is interpreted, such as a functional, product, location, or declared local structure. It is not a free aspect label. designatedEntityRef names the entity designated in that structure. The direct relation ref is affirmative only when its own owner admits that kind and the occurrence independently obtains. If a design object and a realized component both need to be retrieved, name the two entities and a bounded correspondence claim or independently obtaining correspondence relation rather than letting one code silently collapse them.
The designation use permits retrieval and cross-description coordination. Part-whole, function, location, identity across aspects, and evidence claims still come from their direct relations or claim owners. Repeated appearance of the same designation expression is insufficient to merge referents when the scheme, selected structure, local sense, or qualification window differs.
Keep exchange checking distinct from architecture evaluation
An IFC exchange or another machine-readable model is a representation and publication of one or more epistemes. Its schema relations can preserve valuable source structure. Before using it as architecture-description content:
- identify every source episteme used, its representation, and the publication occurrence, form, and carrier;
- recover the exact actual subject-relation occurrences and A.22 selected structures represented by the relation data being used;
- record the source-to-use path into the exact architecture description or view episteme;
- state the admissible architecture use and any lost, inferred, unknown, stale, or unavailable relation content.
A computer-interpretable exchange specification can evaluate whether declared information is present and shaped as specified. That evaluation concerns the exchange description or publication. It does not make schema relation data obtain in the built asset, constitute a selected structure, grant U.View membership, establish description truth, or show that the selected architecture is adequate for the asset's functions, constraints, or architectural characteristics. Apply the architecture, characteristic-evaluation, evidence, and assurance patterns for those claims.
Keep a digital-twin description coupled without merging its objects
The phrase digital twin can cover a model episteme, software system, sensor systems, telemetry epistemes, simulation methods, operational Work, interfaces, representations, and publications. Recover each current object by its direct kind and relation. C.30.AD.BA uses only the exact descriptions and views that contribute to the built asset's architecture-description use.
When one declared architecture-description use crosses design-side and run-side material, fill the optional local carrier named by designRunSeparationUse:
This is a by-value classifier for one built-asset description use, not a new FPF kind, a generic tag, or a relation constructor. designSideDescriptionRefs cite exact epistemes used for intended, required, proposed, or design-state material; runSideDescriptionRefs cite exact as-built, observed, operating, inspection, or maintenance-state epistemes. The classification is local to the declared use, not intrinsic to an episteme. If one publication carries both, identify the exact description or ClaimGraph loci before classifying them; the publication boundary does not perform the split.
Every referenced object and relation keeps its direct owner. C.2.1 governs description identity; [A.15](/generated/patterns/A.15) governs each exact U.Work; [G.11](/generated/patterns/G.11) governs freshness, currentness, and decay; the exact source-use owner governs each source path; the direct correspondence or coupling owner governs an affirmative relation; and [A.10](/generated/patterns/A.10) or [B.3](/generated/patterns/B.3) governs reliance or assurance. [C.28](/generated/patterns/C.28) governs a causal use of telemetry, simulation, maintenance, or a claimed physical or energy change; [C.27](/generated/patterns/C.27) continues to govern the temporal adequacy of the change statement. A.3.4 governs an actual physical transformation only when the exact changed referent, boundary, conditions, before/during/after facts, and continuity or reidentification basis are complete. A required or desired effect, live value, simulation result, control-view row, or local design/run classification is not that actual transformation. The local carrier owns only which already identified references participate on each side of this one cross-lifecycle use. Its nested source and currentness refs must resolve to the same exact refs cited by the enclosing use record, not duplicate or replace them. When an exact side, source path, Work occurrence, currentness boundary, or required direct relation cannot be recovered, state that gap in blockedMerge and narrow or block the cross-lifecycle use.
The twin's coupling to the asset establishes neither parthood nor identity between the digital and physical objects. Connection, synchronization, rendering, bundling, and publication also establish neither architecture relation, selected structure, description truth, empirical grounding, view membership, evidence sufficiency, assurance, gate passage, Work, nor project-use relation.
A green twin, dashboard, exchange result, or release screen is therefore a cue, not gate passage. [A.21](/generated/patterns/A.21) becomes current only when an actual OperationalGate(profile) consumes declared GateCheckRefs and publishes GateDecision plus DecisionLogRef; if that relation is absent, keep the display as a cue and route any evidence, work-entry readiness, assurance, Work, or neighboring claim to [A.10](/generated/patterns/A.10), [A.15.5](/generated/patterns/A.15.5), [B.3](/generated/patterns/B.3), [A.15.1](/generated/patterns/A.15.1), or its exact direct governor. Even GateDecision=pass establishes neither release, readiness, permission, authorization, nor performed Work.
Recover the release-looking claim before routing it. An actual release action is one exact [A.15.1](/generated/patterns/A.15.1) U.Work occurrence; work-entry readiness is [A.15.5](/generated/patterns/A.15.5); a non-prohibition, granted permission, permission exercise, non-violation, or permission conflict is [A.2.8.PER](/generated/patterns/A.2.8.PER); an instituting or revoking grant act is [A.2.9](/generated/patterns/A.2.9). A further claim that a subject was released needs its named subject predicate and participants; if they cannot be recovered, keep the display as a cue and return [A.6.RCD](/generated/patterns/A.6.RCD) missing-governor. No current model, source, gate result, dashboard, or the word authorized supplies one of these relations by appearance.
Currentness and smallest reopen. When a decisive input changes, reopen only the built-asset description-use locus and conclusion that depend on it. A changed asset or selected structure reopens the dependent description identity, built-asset trace, or structural-view use; changed view conformance reopens that one view admission; a changed designation scheme, referent, or qualification window reopens only its BuiltAssetReferenceDesignationUse; a changed source, model, publication, or telemetry edition or freshness/fidelity boundary reopens its exact source-to-use or currentness locus; changed design/run classification, cited Work, source/currentness ref, correspondence, coupling, or transformation reopens only the affected BuiltAssetDesignRunSeparationUse and dependent admissible cross-lifecycle use; and a changed project-use relation or direct governor reopens only that exact relation reference and dependent admissible-use conclusion. Update the affected description, designation, design/run, or currentness locus; when the required input cannot be recovered, narrow or block only that use while unrelated views, descriptions, designations, and uses stay closed.
Worked Cases
Hospital ventilation and fire compartmentation
A hospital renovation uses an IFC publication, a fire-compartment view, a ventilation flow view, an equipment register, an energy-use view, and live air-handling telemetry. The immediate architecture concern is whether the changed ventilation arrangement preserves smoke-control functions across compartment boundaries. A second intended use is a bounded comparison of air-handling energy consumption; it does not share the smoke-control verdict.
The engineer names the hospital facility as builtAssetRef, recovers the actual subject relations and exact fire-compartment, ventilation-flow, equipment-module, and control structures, and cites an obtaining ArchitectureRelation only if its C.30 predicate holds. Required or proposed content remains in a bounded architecture claim. Each used architecture description has its exact ClaimGraph, one EntityOfConcern, and effective reference scheme; each claimed structural view additionally has an exact viewpoint and independently obtaining E.17.0 conformance relation.
The IFC publication supplies a source-to-use path for the spatial and equipment descriptions while its representation, publication occurrence, form, and carrier stay separate. The telemetry episteme has a currentness boundary and can support separately governed operating-state claims; it is not itself the control structure, an architecture relation, an actual physical transformation, or architecture evaluation.
For the energy use, one current C.16 measurement-result episteme attributes 112 kWh ± 4 kWh electrical-energy consumption to air-handling unit AHU-3 over a declared 24-hour commissioning window. It names the exact measurand, Characteristic, Scale and unit, method and model, calibration basis, dated measurement Work, time stance, and uncertainty. Its source-to-use path cites the meter telemetry and source edition; its G.11 currentness condition limits use to the named sensor, calibration, model editions, and validity window and reopens that use when one changes. If the engineer claims that the control revision will reduce the daily consumption rate, the action-guiding temporal claim enters C.27 with the intervention, window, resistance or cost, evidence or assumption relation, supported use, unsupported use, and reopen condition. If that same statement is used to say that the control revision causes the reduction, and causal support makes publication, choice, deployment, assurance, audit, benchmark, or support treatment admissible, C.28 additionally governs the causal-use class, support basis, supported use, unsupported use, and verdict. C.27 temporal adequacy does not establish a causal intervention effect, and C.28 does not replace the C.16 measurement result, C.27 temporal claim, or G.11 currentness boundary. A.10 and B.3 still govern material reliance and assurance. Neither the energy view nor the recent reading proves sustainability, smoke-control adequacy, or architecture adequacy.
An air-handling unit has a product-aspect designation and a location-aspect designation. Each designation use names its scheme, selected structure, designated entity, qualification window, and exact direct relation when one obtains. A bounded correspondence claim or obtaining correspondence relation lets the maintenance team retrieve both descriptions without making the product structure identical to the location structure.
The next architecture move is then concrete: evaluate the proposed flow and control structures against the smoke-control concern and carry the bounded energy-use comparison through its own characteristic and temporal owners. It is not “approve the BIM model.”
Bridge inspection twin
A bridge operator combines an as-maintained geometry model, structural-member view, inspection history, strain telemetry, and a simulation view. The bridge remains the built asset across model editions. The structural-member and sensor-placement structures are selected explicitly; each description keeps exact C.2.1 identity and each claimed view exact E.17.0 conformance. Inspection and telemetry claims retain their evidence, grounding, source-use, and currentness relations. A revised simulation model remains another episteme edition unless its claim graph, EntityOfConcern, and effective scheme are unchanged under C.2.1 and its declared lineage or continuity claims support the intended reuse.
When the operator compares an original design description with the as-maintained geometry, inspection history, and live telemetry, designRunSeparationUse cites the exact design-side description and design Work, the exact run-side descriptions and inspection or maintenance Work, their source-to-use and currentness refs, and any separately governed design-to-realization correspondence. actualTransformationRefs remains absent unless an exact repair or other physical change satisfies A.3.4. The architecture description can therefore support a decision to inspect or redesign a connection while retaining the route back to the geometry publication, measurement descriptions, and selected structures. It cannot treat a successful data-exchange check, recent sensor sample, simulation result, polished dashboard, or local design/run classification as proof that the bridge architecture is adequate or that design and realized objects are identical.
Conformance Checklist
Consequences
The pattern makes multi-view built-asset descriptions more work to assemble because a tool container no longer supplies ontology by appearance. That cost is local and reviewable: each description gains exact C.2.1 identity; each asserted view gains an exact selected structure, viewpoint, and conformance relation; each designation use gains an exact referent, scheme, aspect structure, qualification window, and direct-relation disposition; and each live description gains an explicit currentness boundary.
The gain is stronger reuse. A changed model edition, replacement sensor system, revised designation scheme, new representation, or new publication can be incorporated without changing the built asset's identity, inventing an architecture occurrence, or silently reidentifying a description. Architecture evaluation can use the description while remaining distinct from exchange checking, information currentness, evidence sufficiency, assurance, Work, and project locality.
Rationale
Built-asset practice is unusually exposed to semio-bias because one information environment often spans geometry, equipment, Work, sensor state, and maintenance history. The strongest repair is not a warning against models. It is a constructive chain from the physical asset and independently obtaining subject relations to exact selected A.22 structures, any actual ArchitectureRelation, bounded architecture claims, exact C.2.1 description epistemes, independently conforming views, and the source, representation, publication, designation, grounding, currentness, Work, and project-use relations that make those descriptions usable.
Reference designation demonstrates why this chain matters. Its engineering value is retrieval across heterogeneous descriptions. That value depends on the scheme, selected aspect structure, referent, qualification window, and exact direct-relation disposition being explicit. Treating the code as universal identity would remove precisely the aspect discipline that makes the designation useful.
SoTA-Echoing
Relations
- Specializes:
C.30.ADfor built-asset architecture-description use. - Uses architecture and structure patterns:
C.30,C.30.ASV,A.22,A.6.F,A.6.M,C.30.TFS-REL, andC.30.LCA. - Uses description, view, representation, and publication patterns:
C.2.1,A.7,E.17.0,E.17,E.24.PUB, andC.29. - Uses relation, naming, and currentness patterns: the exact direct designation/reference owner;
A.6.Pfor precision repair;A.6.RCDonly for a demonstrated missing reusable governor;A.6.RELonly after a direct owner admits a relation and occurrence identity matters;F.18; andG.11. - Uses lifecycle information-management source discipline from: exact published
ISO 19650-1:2018andISO 19650-3:2020editions through source-to-use, edition, currentness, source-return, and admissible-use boundaries, without ontology or authority import. - Lowers design/run separation through: one local
BuiltAssetDesignRunSeparationUseover exact C.2.1 descriptions,A.15Work, source-use paths,G.11currentness, directly governed correspondence or coupling, and A.3.4 transformation refs; the local classification admits no kind or relation. - Routes auxiliary-view claims to:
C.16for characteristic measurement,A.15for operation or maintenance Work,C.27.TAfor positive temporal aspects,C.27for action-guiding temporal-claim adequacy,C.28when an intervention, maintenance action, simulation, telemetry change, or claimed effect is used causally,A.10for evidence or material reliance,B.3for assurance, andG.11for currentness and reopen conditions. - Routes gate- and release-looking uses to:
A.21only for an actual gate-decision relation; otherwise the display remains a cue. Route a release action or other performed Work toA.15.1, work-entry readiness toA.15.5, a permission result or exercise toA.2.8.PER, an instituting or revoking grant act toA.2.9, and a subject-release claim to its named predicate and participants orA.6.RCD missing-governor; none of these claims entails another. - Returns other claims to:
A.3.4and the direct transformation, evaluation, evidence, assurance, Work, decision, acceptance, or project-use pattern named by the claim.
C.30.AD.BA:End
Architecture and Structure Precision Restoration
Type: Architectural pattern Status: Stable Normativity: Normative unless explicitly marked informative
Plain-name. Architecture-structure wording repair.
Intent.
Recover architecture or structure wording whose selected structure, architecture relation, architecture-description use, structural-view use, source-return relation, or named C.30 subcase is hidden before a reader applies A.22, C.30, C.30.ASV, or a named C.30.* pattern.
This pattern does not mint U.Architecture, does not fuse architecture and structure into one kind, and does not replace grounded architecture adequacy or structural-view adequacy. It repairs overloaded wording so the architecture, structure, description, view, publication, source, relation, characteristic, mathematical-lens, evidence, assurance, gate, work, decision, causal-use, release, or ordinary-prose use becomes recoverable by value.
Builds on. E.10, E.10.ARCH, A.22, C.30, C.30.ASV, C.2.P, A.6.P, A.6.F, C.29, C.16.P, C.16, C.25, E.17, and E.8.
Coordinates with. C.30.TFS-REL, C.30.LCA, C.30.ILC, named C.30.* structure and view patterns, A.10, B.3, A.20, A.21, C.11, C.28, A.15, E.11, and work, release, and publication patterns define or constraining those claims.
E.10.ARCH governing relation. When E.10 encounters architecture or structure wording whose selected structure, architecture relation, architecture-description use, structural-view use, source-return relation, source label, or neighboring claim is hidden, E.10.ARCH selects C.30.P only until the use under repair and subject pattern are recovered. C.30.P then stops applying; it does not become a registry of architecture topics or a substitute for A.22, C.30, C.30.AD, or named C.30.* patterns.
Use this when
Use this pattern when architecture or structure wording hides which use is being made and recoverable by value.
Typical triggers:
architecture,architecture description,architecture model,architecture diagram,architecture map,architecture dashboard,architecture score;structure,structural view,structural model,module layout,component structure,interface structure, or stratification wording or source-label wording such aslayer,level,tier,stack,ladder,rung,block,expert,cache,router, orgatethat must go toC.30.STRATbefore local architecture or structure assignment;graph,flow,transformation-flow graph expression,control sketch,LCA diagram,ADR,dashboard,benchmark,source, orviewbeing treated as architecture or structure by wording alone;- a function, module, interface, signature, flow, control, quality, score, evidence, assurance, gate, work, decision, causal-use, or release claim being smuggled under architecture or structure wording.
What goes wrong if missed. A diagram becomes the architecture, a graph becomes proof, a view becomes the selected structure, a source document becomes an architecture decision, a score becomes architecture adequacy, or a function, module, or interface claim becomes architecture by default.
What this buys. The reader can recover the architecture or structure use under repair, block the overread, and move to the subject pattern: selected structure under A.22, grounded architecture claim or conditional architecture description under C.30, architecture structural view under C.30.ASV, stratification-wording repair and source-label repair under C.30.STRAT, architecture transformation-flow relation under C.30.TFS-REL, control-structure view under C.30.LCA, mathematical lens under C.29, characteristic and scale repair under C.16.P, or a project-side evidence, assurance, gate, work, decision, causal-use, release, or publication pattern.
First useful move. Ask which selected structure, architecture relation, architecture-description use, structural-view use, source-return relation, or neighboring claim the architecture or structure wording is actually naming, then either apply the architecture or structure pattern named by value directly or use one architecture-structure repair note to assign the claim elsewhere.
Not this pattern when.
- If the use under repair is already a selected structure, use
A.22directly. - If the use under repair is already
ArchitectureOf@Context, useC.30directly. If the use under repair is the fullArchitectureDescription@Contextmechanism, useC.30.AD; useC.30only for the thin architecture-description bridge tied to one architecture move. - If the use under repair is already an architecture structural view, use
C.30.ASVor a namedC.30.*view pattern directly. - If the claim being made is evidence, assurance, gate, work, decision, causal-use, release, mathematical-lens use, characteristic and scale construction, quality characterization, source-use, or relation construction, use the subject pattern for that claim after any architecture or structure wording is demoted or assigned.
Problem frame
Working engineers often say "architecture" or "structure" while pointing at a useful artifact: a diagram, model, graph, table, dashboard, ADR, code-agent relation graph, neural-network architecture-operation diagram, benchmark result, or source document. Ordinary speech is acceptable; FPF-governed prose is not. If the artifact is named by a source label such as block, layer, expert, cache, router, or gate, use C.30.STRAT before assigning the recovered use locally.
The repair question is:
Which selected structure, architecture relation, architecture-description use, structural-view use, source-return relation, or neighboring claim does the wording name, and which FPF pattern defines or constrains that claim?
The architecture or structure use under repair may be:
- selected structure under
A.22; - an
ArchitectureOf@Contextclaim underC.30, a thin architecture-description bridge underC.30, or the full architecture-description mechanism underC.30.AD; - an
ArchitectureStructuralView@Contextor namedC.30.*subcase; - a publication, view, face,
PublicationUnit, carrier, dashboard, ADR, source document, or source-return relation underC.2.PorE.17; - a relation construction under
A.6.P; - a function or functionality-kind use under
A.6.F; - a mathematical-lens use claim under
C.29; - a characteristic, scale, score, coordinate, threshold, or quality-coordinate claim under
C.16.PorC.16; - a Q-bundle or quality-characterization claim under
C.16.Q,C.25, orE.21; - an evidence, assurance, gate, work, decision, causal-use, release, or method claim under its subject pattern;
- ordinary prose with no FPF-governed use being made.
Problem
How can FPF repair architecture or structure wording without:
-
creating
U.Architecture; -
treating architecture and structure as one fused kind;
-
treating a description, view, diagram, graph, dashboard, source, ADR, model, or publication as the architecture itself;
-
assigning all function, flow, module-interface, signature, control, evidence, assurance, gate, decision, work, quality, mathematical-lens, or source claims to architecture;
-
duplicating first-stage repair lists inside
A.22,C.30,C.30.ASV, and every namedC.30.*subpattern?
Forces
Solution
Repair architecture or structure wording by producing an architecture-structure repair note or an equivalent local rewrite.
Minimum fields:
Use the note only when the repair must remain inspectable. A direct local rewrite is enough when one sentence clearly names the selected-structure claim being made, architecture relation, architecture-description use, structural-view use, source-return relation, or subject pattern.
Recovery sequence
- Capture the trigger. Copy the architecture or structure wording and the sentence that uses it.
- Recover the encountered FPF kind or reference. Decide whether the text points to a selected structure, architecture claim, description, view, diagram, graph, model, dashboard, ADR, source document, carrier, publication, stratification-wording case or source-label case for
C.30.STRAT, function, module-interface relation, signature, flow, control, score, quality term, evidence, gate, work, decision, release, or ordinary prose. - Recover source-publication relations before architecture assignment. If the wording relies on a source, publication, view, face,
PublicationUnit, dashboard, ADR, file, carrier, or source-return relation, applyC.2.Pfor source-use, source-currentness, and publication relations before assigning the architecture or structure claim. - Choose the subject pattern for the architecture or structure use.
- selected structure ->
A.22; ArchitectureOf@Context, selected architecture-relevant structure, or thin conditionalArchitectureDescription@Contextbridge use ->C.30;- full
ArchitectureDescription@Contextmechanism ->C.30.AD; - architecture structural view ->
C.30.ASV; - architecture transformation-flow relation ->
C.30.TFS-REL; - control-structure view ->
C.30.LCA; - cross-scope conflict or frustration triage ->
C.30.ILC; - stratification wording or source-label wording such as
layer,level,tier,stack,ladder,rung,block,expert,cache,router, orgate->C.30.STRATbefore choosing the final subject pattern; - named C.30 subcase -> that subpattern.
- selected structure ->
- Assign non-architecture claims to their subject patterns. If the sentence uses architecture wording to carry relation, function or functionality, mathematical-lens, characteristic and scale, quality, evidence, assurance, gate, work, decision, causal-use, release, or method claim, apply the subject pattern for that claim and keep this pattern only for the architecture or structure wording repair.
- State admissible and non-admissible use. Say what the reader may do with the repaired wording and what non-admissible adjacent interpretation is blocked.
- Stop C.30.P after assignment. Stop after the subject pattern or ordinary-prose demotion is named.
Subject pattern assignments
Architecture-synthesis routing note:
- Use
C.32,C.32.MLAO,C.32.CONWAY, orC.32.FAILwhen the recovered claim is a candidate palette, residual-reducing multilevel frame, transformer and transformed correspondence frame, or architecture-synthesis repair cue. - Use
A.19.CPM,A.19.SelectorMechanism,C.11, orG.5when the recovered claim is comparison-policy use, selector-policy use, local choice, or selected-set result declaration. When publication is current, useE.17for a source-backed face and source return andE.24.PUBfor the publication occurrence and audience availability. - Use
C.18orC.19when the recovered claim is archive, front, or pool policy. - For transformation-flow, function, module, transformer, mathematical-lens, relation-signature, affordance, architecture-use, or move-like wording, recover that claim kind first and use its subject pattern by value.
Refresh and reopen conditions
Reopen or narrow C.30.P when the FPF pattern-language ecology changes the first architecture or structure entry:
- a named
C.30.*, structural-view, architecture transformation-flow, LCA or control, module-interface, mathematical-lens, characteristic, evidence, assurance, gate, work, decision, causal-use, release, or publication pattern now governs one row directly; - source-current architecture-description, view, model, decision-record, or architecture-documentation practice changes one adopted distinction in
C.30.P:7; - README, ToC,
E.11, retrieval, or local Problem-frame entry cues change the first practical entry for hidden architecture or structure wording; - a subject pattern starts copying first-stage architecture or structure trigger lists that belong here;
C.30.Pbegins to act as a registry of architecture topics rather than a wording-use repair pattern for hidden selected structure, architecture relation, architecture-description use, structural-view use, source-return relation, or named C.30 subcase.
The refresh action is to remove, narrow, or reassign the first-stage row. It is not to preserve old assignment wording as history.
Worked cases
Reduced SoTA row
Current architecture-description, model, view, and decision-record practice treats architecture as distinct from architecture descriptions, models, views, viewpoints, diagrams, and decision records. FPF adopts that line only where it changes action guidance: examples, non-use boundaries, subject-pattern assignments, source-return conditions, and conformance checks.
This row belongs in this pattern because it blocks diagram-as-architecture, graph-as-proof, view-as-structure-kind, publication-as-claim, and ADR-as-decision overreads. It does not import any external standard as FPF ontology.
Conformance checklist
Common anti-patterns
Related patterns
E.10catches architecture or structure wording and selects this pattern only when the selected structure, architecture relation, architecture-description use, structural-view use, source-return relation, or named C.30 subcase is hidden.E.10.ARCHdefines the shared wording-use recovery order and applicability row.A.22governs selected structure and structural views as structure.C.30governs groundedArchitectureOf@Contextadequacy and thin conditionalArchitectureDescription@Contextbridge use.C.30.ADgoverns the full architecture-description mechanism whenArchitectureDescription@Contextis the EntityOfConcern under repair.C.30.ASVgoverns architecture structural views.C.30.STRATgoverns stratification wording or source-label wording before C.30.P assigns any recovered architecture or structure portion.- Named
C.30.*patterns define or constrain their own structure adequacy or view adequacy questions. C.2.Precovers source, publication, view, face,PublicationUnit, carrier, and source-use disposition.A.6.Prepairs relation construction;A.6.Frepairs function and functionality wording;A.6.Mrepairs module-relation and interface-specification wording.C.16.Prepairs characteristic-and-scale wording, andC.16.Qrepairs quality-term or evaluative characterization wording before score or quality use.C.29governs mathematical-lens use and does not become architecture by analogy.
C.30.P:End
Stratification Wording Precision Restoration
Type: Architectural precision-restoration subpattern under
C.30Status: Stable Normativity: Normative unless explicitly marked informative
Plain-name. Stratification and architecture-operation source-label repair.
Intent. Help a reader decide what a source label such as layer, level, tier, stack, ladder, rung, block, expert, cache, router, or gate means in one current sentence. Keep useful local language, but recover the actual object, relation, or claim before relying on it. No use of this pattern mints U.Layer, U.Level, U.Tier, U.Stack, U.Ladder, U.Rung, U.Block, U.Expert, U.Cache, U.Router, U.Gate, or one universal U.Stratification.
Builds on. E.10, E.10.ARCH, E.8, F.19, F.18, C.30.P, A.22, and C.30.
Coordinates with. C.30.ASV, C.30.LCA, C.30.TFS-REL, C.30.ILC, A.6.M, A.6.F, E.18, C.16.P, C.16, A.19.SPR, C.2.P, E.17, C.29, C.28, A.10, G.6, B.3, A.20, A.21, A.15, A.2, G.5, and C.11.
Authoring boundary. C.30.STRAT supplies one reusable E.10.ARCH applicability row for this wording family. Its semanticArea* and ontologicalNeighborhood coordinates help pattern authors maintain that row; they are not a project object or a form for ordinary engineers. A practitioner receives the shortest sentence or note that names the recovered object, relation, or claim, the allowed use, the next action, and the stop or return condition. Include a blocked overread only when it passes F.19's plausible-reader test.
Use this when
Use this pattern when a source uses a compact architecture or stratification label and that word alone does not tell you what technical claim is being made.
Typical labels are layer, level, tier, stack, ladder, rung, and architecture-operation words such as block, expert, cache, router, and gate.
What goes wrong if missed. A useful local label starts acting as ontology. A layer is assumed to be a holon level, control layer, publication layer, scale window, or module boundary without deciding which. A stack becomes architecture by name; a block becomes a module; an expert becomes a system-role kind or performer; a cache becomes a state or memory relation; a router becomes a decision policy; a gate becomes a gate decision. Word shape establishes none of these.
What this buys. The reader can keep the source word while making its actual meaning and safe use explicit. Once the object, relation, or claim is clear, use the pattern that defines, constrains, or tests it.
First useful move. Copy the sentence and ask: “What does this label name here, what may I infer from it, and what must I do next?” If it is ordinary wording, keep it and stop. If the answer is already clear, use the applicable pattern directly. Otherwise write one line: label -> recovered meaning; allowed use; next pattern or blocker; stop or return condition. Do not fill an author-facing E.10.ARCH routing row during ordinary project work. Include a blocked overread only when it passes F.19's plausible-reader test.
Not this pattern when. Do not detour through C.30.STRAT when the object, relation, or claim is already clear. Do not use it merely because a familiar word appears. Ordinary source prose with no FPF claim remains ordinary prose or a quotation.
Problem frame
Architecture and engineering sources use compact labels because they work in local practice. Neural-network prose says block, expert, cache, or router; control architecture says layer; organizations say level or tier; documentation says section, stack, or view; scale prose says level, resolution, or coarse-graining step.
These words are good recognition cues but poor stand-alone kinds. The same label can point to a selected structure, module relation, control relation, transformation-flow element, characteristic or scale, publication grouping, state, evidence claim, decision, or nothing beyond ordinary prose.
The repair question is simple: what does the label name in this sentence, what use does the recovered claim support, and which existing pattern supplies the needed definition, constraint, or test?
Problem
How can FPF keep common stratification and architecture-operation language without turning the words into false root kinds, routing every structure-like phrase through C.30, copying the same trigger catalogue into many patterns, inferring technical claims from word shape, or deleting useful source language before its remaining reader use is clear?
Forces
Solution
Write the direct local repair first. For example: Here “gate” names the neural-network path selector; use E.18 to describe the selected path. That sentence can be the complete result.
When the repair must be compared, handed on, or revisited, retain a compact note:
groundedOverread? is an alias for the same optional blockedOverread? value, selected through F.19's plausible-reader test.
The note is neither the selected structure nor the relation, claim, publication, or pattern result it points to. Omit it when the direct sentence is enough.
Recovery sequence
- Copy the sentence and label. Keep enough source context to tell what the sentence is doing.
- Try the cheap exits. If the word carries no FPF claim, keep ordinary prose or quote it and stop. If the source already gives the technical term one clear local meaning, keep that term and use its rule directly. If one local rewrite makes the meaning clear, write it and stop. A controlled vocabulary or preferred-word list is not by itself a reason to replace useful domain language.
- Recover plausible meanings. Treat the label as a designation, not as the object, relation, or claim. If it belongs to a named model, viewpoint, standard, or local vocabulary, recover that source-local convention first. Then ask which object, relation, participants or bearer, claim, scope, time, and source use the sentence could be compressing. Include literal and metonymic readings when both are plausible.
- Choose by the recovered meaning. Use the first matching row in C.30.STRAT:4.2; never choose from the label alone. A standard or model may settle the label inside its declared use, but neither its status nor its popularity extends that meaning to another subject or source.
- Open only the needed rule. Name the actual participants, relation, structure, characteristic, state, publication, evidence, work, decision, or other object that makes the claim true or false. Do not copy every possible field into the result.
- Return to ordinary wording. Write the shortest sentence that preserves the recovered claim and names the next pattern only when its contribution matters.
- State the stop. Give the allowed use, the next action, and the condition for stopping or returning. Include a blocked overread only when it passes F.19's plausible-reader test. If no useful action survives, use quote-only, reduced-use, blocked, or incomplete-rewrite disposition.
Recovered meanings and patterns to use
When a level claim matters. When a later decision or design relies on a sentence such as “X is at level L” or “A is above B,” name the subject at stake (the EntityOfConcern), what is being ordered, compared, grouped, or mapped, the relation or scale mapping that gives the claim its meaning, when it applies, and whether the sentence asserts, proposes, assumes, or merely illustrates the claim. Apply the same test when layer, tier, band, scale, or stage carries the stronger claim. A named model or standard may provide this mapping within its declared use; its status does not extend the claim beyond that use. The source word may remain, but these facts—not the label—carry the claim. A list, diagram row, first-then order, carrier section, curriculum, scale label, stage sequence, or coarse-grained description does not establish a subject level by form. If the facts are missing, keep the wording local or illustrative and block reliance on the stronger level claim.
Same-sentence claim boundary
One sentence may use a source label while making several claims. Split them instead of adding a local catalogue of everything the label does not prove. C.30.STRAT repairs the label; the applicable pattern defines, constrains, or tests each separate claim. The table above lists common destinations, not a mandatory reading list.
Source-label cue table
Author-facing placement note
This subsection maintains the E.10.ARCH applicability row; it is not part of the ordinary project result.
semanticAreaBaseConceptis stratification wording and architecture-operation source labels.semanticAreais the Part-F row-set forlayer,level,tier,stack,ladder, andrung, plusblock,expert,cache,router, andgatewhen they appear before their technical meaning is known.semanticAreaSenseFamilyis source-label wording for stratification, ordering, aggregation, and architecture-operation recognition. It is not a topic, workstream, or pattern grouping.ontologicalNeighborhoodis the author-facing applicability family selected from C.30.STRAT:4.2. It is neither a second ontology nor a field that an engineer adds to the project object.
The pattern is placed under C.30.* because architecture and structure prose is the recurring entry. Placement does not decide the recovered meaning. After recovery, use the rule that defines, constrains, or tests the actual object or claim.
Worked cases
Filled repair note
For The cache proves the architecture scales, do not hide the split inside one formal record. Read it as three candidate claims:
cachemay name a state-bearing module, interface arrangement, flow buffer, or ordinary source label; the sentence does not yet decide which;provesrequires an actual evidence relation or assurance argument; otherwise lower that wording;scalesrequires a characteristic and bearer, comparison or scale construction, architecture scale-preference claim, or mathematical-lens use.
A retained note can remain compact:
The note preserves every live branch without requiring a project engineer to reproduce E.10.ARCH authoring coordinates.
Lowering and reopen conditions
A repair remains usable only while its source span, recovered meaning, applicable rule, allowed use, and next action remain clear. Reopen or narrow it when the label begins carrying another relation or claim, the actual object becomes clear and makes this detour unnecessary, the interpretation was chosen from word similarity rather than evidence, or the repair is precise but leaves no useful reader action.
Reopen the affected authoring row when E.10.ARCH changes its internal coordinates, C.30.P changes architecture-wording repair, F.19 changes the plain-language boundary, or another realization pattern now handles this wording family. Lower the result to ordinary wording, quotation, reduced-use cue, blocked use, or incomplete rewrite when the object, applicable rule, allowed use, next action, or stop or return condition cannot be stated. Include a blocked overread only when it passes F.19's plausible-reader test.
Archetypal Grounding
Bias-Annotation
Lenses tested: Arch, Onto and Epist, Prag, Did, and Gov. The pattern deliberately resists word-shape inference. Its counter-bias is equally important: ordinary prose stays ordinary, a known meaning uses its pattern directly, and the author-facing routing coordinates never become a project form.
Conformance checklist
Common Anti-Patterns and How to Avoid Them
Consequences
Rationale
Stratification words compress local practice. That compression is useful for recognition and unsafe as a substitute for an object, relation, or claim. C.30.STRAT therefore keeps the source word, recovers what it means in the current sentence, and returns the reader to the applicable technical rule.
The pattern sits under C.30 because architecture and structure prose is the usual entry. That placement is a navigation choice, not an ontological claim and not authority over every recovered case.
SoTA-Echoing
Standard status, publication date, and wide use show that an approach is maintained and consequential; they do not by themselves show that it moves the relevant Pareto front. The comparison below adopts only contributions that recover a technical claim more reliably without making ordinary project language harder to use. The compact combination in this pattern—cheap exit, source-local meaning, recovered claim, next useful rule, stop or return condition, and any justified blocked overread—is FPF synthesis.
Reopen only the affected cue, worked case, check, or pointer when a source changes. Reopen the wider pattern when a current approach demonstrates a meaning-recovery method that is more reliable at comparable reader effort, or when repeated use shows that the present cue table either misses consequential readings or sends clear ordinary language through unnecessary formal repair.
Relations
- E.10 catches the wording trigger; E.10.ARCH supplies the author-facing recovery architecture and anti-fanout rule.
- C.30.P is the broader architecture and structure wording repair; C.30.STRAT is the narrow recurring source-label case.
- Use A.22, C.30, C.30.ASV, C.30.LCA, C.30.TFS-REL, or C.30.ILC only for the selected structure, architecture relation, view, control, flow, or conflict question each pattern defines or tests.
- Use A.6.M for recovered module and interface relations; A.6.F for recovered function claims; E.18 for graph, path, crossing, and transformation-flow claims; C.16.P, C.16, C.29, C.31, or C.31.RSA for recovered characteristic, scale, mathematical-lens, reusable-locus, bespoke-residue, or report-only-share claims.
- Use C.2.P and E.17 for source and publication relations; A.19.SPR, A.3.3, C.27.TA, and C.27 for state, dynamics, temporal, and rate claims; C.28 for causal use; A.10 and G.6 for evidence; B.3 for assurance; A.20 and A.21 for constraint validity and gates; A.15 for Work; A.2 for system-role kinds; G.5 and C.11 for selection and decision.
- C.33, C.34, and C.35 handle captured, lost, preserved, generated-carrier, or discovered-carrier structure when those claims are current.
- A recovered level claim returns to the pattern that defines or tests its subject relation or mapping. C.30.STRAT establishes no level by itself.
Stop after repairing the source label and naming the next useful action. Use the defining or testing pattern for each recovered object or claim, and keep its rules there.
C.30.STRAT:End
Architecture Structural View Adequacy (ASV)
Type: Architectural pattern Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when you have a structural description of one selected architecture-relevant U.Structure and need to decide whether that same description is also a U.View under one exact viewpoint.
The first useful move is small. In ordinary prose, name the described holon or actual ArchitectureRelation when known, the selected structure, the smallest useful structure-kind set, any qualifier that changes interpretation, and the next architecture move. If one or two sentences make those values clear, stop.
For example: “The failover diagram describes runtime-interaction and control structures, but it hides the actual failover relation. Recover that relation before relying on the diagram as a view.” This is already a usable triage result. Use ArchitectureStructureKindTriage@Project only when the result must be retained, compared, or handed on.
@Project is a compatibility and retrieval cue for a project-side use record. It supplies no project identity, authority, context, viewpoint, parthood, or Work occurrence. When one actual project matters to this triage, projectWorkOccurrenceRef identifies the composite U.Work recovered under [A.15.6](/generated/patterns/A.15.6). Include architectureStructuralViewProjectUseRelationRef only when a named pattern defines the relation by which this use concerns that Work and an occurrence of the relation obtains. A Work reference alone does not establish project locality. If locality matters but that relation is not yet defined, use A.6.RCD before filling the field; otherwise omit both project-local fields. claimPatternRefs points only to patterns that define or test separate claims; it does not identify a pattern-application occurrence.
Start with [C.30](/generated/patterns/C.30) when the actual architecture relation, exact selected structure, or architecture claim is unclear. Use C.30.ASV only when a structural description over selected architecture-relevant structure changes the next architecture use. Use the full ArchitectureStructuralView record only when one exact description episteme passes E.17.0 conformance to an exact viewpoint and the view changes action, selected reliance relation, correspondence, source return, publication, comparison, or another non-ASV claim or use.
What goes wrong if C.30.ASV is missed: one favored diagram, module view, TEVB viewpoint, generated relation graph, control sketch, or neural-network block diagram is treated as the architecture, selected structure, U.View, or proof without naming the exact description episteme, selected structure kind, viewpoint-conformance occurrence, hidden or lost structure, correspondence, and next architecture use.
What C.30.ASV buys in practice: the practitioner can distinguish description identity, selected structure and structure kind, exact viewpoint conformance, representation, and publication before relying on a view. Construction history, hidden or lost structure, correspondence, source return, and admissible use remain separately inspectable.
Do not use C.30.ASV when the question is only about a general architecture claim, subject-side ArchitectureRelation, structure as such, selected transformation-flow relation, mathematical graph description, transformation-flow path relation, or crossing relation. Use [C.30](/generated/patterns/C.30), [A.22](/generated/patterns/A.22), [E.18](/generated/patterns/E.18), [E.18.2](/generated/patterns/E.18.2), [C.29](/generated/patterns/C.29), or C.30.TFS-REL as appropriate. If the view is used for another claim, use the applicable pattern for that claim and keep C.30.ASV only for the view portion.
Thin precision-restoration pointer: if the issue under repair is still whether view, architecture view, architecture structural view, diagram, model, graph, layer, or functional architecture names a structural description, a U.View, an architecture description, a representation, a publication occurrence, a publication form, a source relation, or another claim or relation named by value, use [C.30.P](/generated/patterns/C.30.P) first. Do not copy the [C.30.P](/generated/patterns/C.30.P) trigger table here; apply C.30.ASV only after the architecture structural-view claim or non-ASV claim named by value is recoverable.
Problem
Architecture structural-view work is selected-structure triage: which architecture-relevant structure is described, which structure kind is under consideration, which exact viewpoint's fixed rules the description satisfies, and what relation, constraint, invariant, operation, dynamics description, hidden or lost structure, correspondence, source-to-use path or work-reliance relation, and source-return condition changes the next architecture move. The candidate is first one C.2.1 description episteme. That same episteme is a U.View only while an exact EpistemeViewpointConformanceRelation to an independently identified U.Viewpoint episteme obtains. Diagram, representation, publication occurrence, form, carrier, and rendering remain separate.
Without this pattern:
- a module-interface view is treated as all architecture;
- a selected transformation-flow structure, mathematical graph description, or control diagram is treated as proof;
- a structure kind is treated as a
U.Viewpoint; - a viewpoint label, query, authoring route, family-declaration membership, diagram, or publication is treated as enough for
U.View; - E.17.2's TEVB template or a project-local TEVB declaration is treated as a global bundle and mutated to carry architecture-specific structure kinds;
- a diagram, table, dashboard, generated relation graph, or ADR is treated as the view episteme itself;
- functional architecture is treated as a peer ontology rather than a structure-kind interpretation under C.30;
- cross-view consistency is asserted by prose instead of correspondence claims or independently obtaining relations;
- omitted structure is relied on in subsequent work without a source-return condition.
Forces
Solution
For an architecture structural view, first identify one candidate description episteme, its exact selected U.Structure EntityOfConcern, effective U.ReferenceScheme, structure kind, exact viewpoint episteme, and the direct conformance occurrence. Then add construction history, correspondence, hidden or lost structure, source-to-use path or work-reliance relation when current, source-return condition when needed, admissible use, and next architecture move. Use ArchitectureStructuralView only for the same episteme whose E.17.0 conformance actually obtains.
A conforming ArchitectureStructuralView is not a second individual beside its description. The candidate retains one C.2.1 identity <exact ClaimGraph, one exact selected-structure EntityOfConcern, effective U.ReferenceScheme>. The exact viewpoint and EpistemeViewpointConformanceRelation qualify that same episteme as U.View; they do not enter its C.2.1 identity.
C.30.ASV is the selected-structure structural-view adequacy pattern for architecture work. It explains how descriptions of different selected structure kinds may satisfy declared viewpoints and concerns. It is not a complete architecture-description pattern; C.30.AD composes separately identified descriptions, view-use claims, and correspondence only when that broader description use is being made.
C.30.ASV does not extend any TEVB family by implication. It defines architecture structure kinds and architecture-specific bindings to exact viewpoint epistemes. A project reuses a TEVB or architecture viewpoint only through an exact U.ViewpointRef resolved from a materialized local declaration in one exact E.17.1 catalogue; E.17.2 and C.30.ASV otherwise provide templates, not current family values. Source-to-use, work-reliance, project-use, representation, and publication relations remain separate from viewpoint conformance.
Architecture structural view record
StructuralAspectDescription describes one selected structural aspect under A.22. It is not an ArchitectureStructureKindRef or U.View by itself. ArchitectureStructuralView names the same architecture-description episteme only after exact E.17.0 conformance obtains.
recordPatternLocator identifies the pattern whose record form is being used. It is a locator, not an actor or a substitute for any rule needed by a current claim.
The selected U.Structure is the one EntityOfConcern. Before that field can be filled, A.22 identifies the structure from exact constituents, selected independently obtaining relation occurrences, applied constraint claims, and one exact receiving-use frame. A description, query, diagram, family declaration, file, representation, or publication creates none of those discriminators. relatedStructureRefs may name structures needed to interpret correspondence, allocation, or crossing, but they do not create a union-valued EntityOfConcern. When another selected structure becomes primary, identify another description episteme or use exact C.2.1 edition or retargeting semantics; do not overwrite identity through a view field.
The direct conformance occurrence has exactly two participants: viewEpistemeRef as candidate E and viewpointRef as exact P. Its fixed E.17.0 predicate requires: (1) independently identified E and admitted P; (2) exact EntityOfConcern(E) recovered; (3) P's fixed EntityOfConcern-kind criterion succeeds for that exact object; (4) E has an independently admitted episteme kind accepted by P without circular U.View use; and (5) E's fixed claim content under its effective scheme satisfies P's concern-coverage, semantic-form, completeness, and admitted-omission rules. The occurrence is participant-determined by <E,P>.
An architecture claim can carry positive, negative, unresolved, required, desired, expected, or candidate content. architectureRelationOccurrenceRefs is affirmative only for independently obtaining direct ArchitectureRelation occurrences. describedHolonRef and participant traces keep the subject recoverable; neither an optional claim nor a diagram derives the subject-side occurrence.
ClaimScope, concern, model-use structure, and empirical grounding remain optional neighboring qualifiers or relations. modelUseStructureRef appears only when an independently selected DDD-style bounded-model-use structure changes interpretation or selection for this use. None enters base episteme or selected-structure identity.
viewConstruction records provenance only. Direct authoring, A.6.3 construction, projection, query, extraction, selection, bundle inclusion, diagramming, rendering, publication, evaluation, or current use neither satisfies the conformance predicate nor creates selected structure. Representation, publication occurrence, form, and carrier likewise retain their own identities.
structureKnowledgeState? states how the selected structure is known when partial knowledge matters: declared, observed, inferred, generated, simulated, extracted, hypothesized, or with an unknown region present. Unknown or inferred structure may guide inspection or source return; it cannot by itself supply architecture truth, assurance, gate, release, causal proof, or architecture decision.
Architecture structure-kind classifier
ArchitectureStructureKindRef is a C.30-local DiscriminatorToken enumeration over exact architecture-relevant U.Structure references selected under A.22 and used by C.30. It is not U.Kind, U.Viewpoint, U.ViewpointBundle, StructuralAspectDescription, ArchitectureStructuralView, or a root U.* kind. An ArchitectureStructuralView uses structureKindRef to state which kind of selected structure its claim graph describes; that token neither identifies the structure nor grants U.View membership.
The first group is the seed classifier set for ordinary architecture structural-view use. SecurityTrustBoundaryStructure, WorkMethodStructure, AllocationResponsibilityStructure, EvidenceAssuranceStructure, and ScaleEvolutionStructure are classifier values over selected U.Structure references, not new root kinds. ASV may use them to name the selected architecture-relevant structure, but their full semantics stay in the named security, work and method, allocation-responsibility, evidence and assurance, scale, characterization, or mathematical-lens patterns.
Do not enumerate structure kinds by default. Choose the smallest useful structure-kind set that changes the next architecture move. If no structure kind changes action, keep the phrase as ordinary recognition wording or a source note. This does not weaken kind discipline; it prevents ArchitectureStructureKindRef from becoming an audit checklist.
Inside C.30.ASV, OtherDeclaredStructureKind is always an architecture-structure-kind classifier value over U.Structure; it does not mint a general FPF root kind.
OtherDeclaredStructureKind is admissible only when the local text names:
declaredStructureKindName;declaredStructureKindDefinition;- allowed relation families;
- locally triggered overreads;
- applicable patterns for non-ASV claims;
- a selected-structure admission test, plus the effective
U.ReferenceSchemewhen the local classifier name depends on one.
Each structure kind needs a short definition, allowed relation families, locally triggered overreads, applicable patterns for its non-ASV claims, and example architecture structural-view records. This is not a new root-kind set; it is a controlled classifier set over exact U.Structure values.
Small triage output
Use ArchitectureStructureKindTriage@Project before a full view record when the practitioner only needs to identify the structure kind under consideration and next architecture move.
architectureConcernCue? and sourcePhrase? are recognition wording. claimPatternRefs? names only patterns that define or test separate claims; it does not assert that a pattern-application occurrence exists. inspectedDescriptionOrViewRef? and candidateViewEpistemeRef? name actual epistemes only when identified under C.2.1. None creates an ArchitectureStructureKindRef, selected structure, architecture relation, or U.View. Fill exactViewpointRef and viewpointConformanceRelationRef only when the same candidate episteme actually qualifies as a view.
When architectureClaimRef is absent, describedHolonRef, architectureRelationOccurrenceRef, or at least one exact candidate selected structure must keep the subject recoverable for the intended triage. claimScope, effectiveReferenceScheme, and modelUseStructureRef are present only when they change this use. The card publishes no architecture claim and creates no subject relation. A full ArchitectureStructuralView requires the candidate episteme's exact C.2.1 identity plus obtaining E.17.0 conformance; it does not require an architecture-claim record when the exact selected-structure EntityOfConcern and subject trace are otherwise recoverable.
Practitioner prompt labels are first-entry cues, not ArchitectureStructureKindRef values. When the triage is retained as a record, use the technical values below:
Evolutionary-engineering candidate structural view
Use this branch when a retained variant, front member, selected set, or architecture-candidate palette needs structural-description triage. The claim is not "this archive is architecture" and not "this record is already a U.View." It is "this candidate makes an exact selected structure or structure kind current for an architecture claim or possible architecture move."
If the candidate cannot name an exact selected structure or structure kind, keep it in [C.18](/generated/patterns/C.18), [C.19](/generated/patterns/C.19), or [G.5](/generated/patterns/G.5). If the description only publishes, compares, or explains the candidate, use [C.30.AD](/generated/patterns/C.30.AD), the comparison pattern, or the publication-use pattern named by value. It is an ArchitectureStructuralView only when the same candidate description episteme independently conforms to the exact viewpoint under E.17.0.
Project-local architecture viewpoint-family template and binding rows
C.30.ASV ships no exact architecture viewpoint catalogue, family value, reference, or viewpoint episteme edition. VF.ARCH.STRUCTURE, VF.TEVB.ENG, and VP.Architecture* in predecessor material are therefore not current global values. A project may use similarly spelled ordinary designators only after it constitutes exact catalogue episteme L and binds exact local references.
Architecture structural views can reuse a materialized local family without turning structure kinds into viewpoints. The project first:
- constitutes exact L through obtaining
EpistemeConstitutionRelation(G_L, K_L, R_L); - places one local declaration claim block inside exact
G_L, retrieved by ordinaryfamilyDesignator = f_archunderR_L; - states the exact target-kind compatibility condition and a finite non-empty set of exact
U.ViewpointRefmembers; - resolves every retained reference under
R_Lto one exact P already admitted under E.17.0; and - preserves exact catalogue and member provenance for any imported project-local TEVB reference rather than importing a family label.
Until those bindings exist, use this only as an authoring template:
Every r_*, P_*, d_*, L, and f_arch above is a variable until one project supplies the exact binding. A d_* value is only P's ordinary designator; it is neither a reference nor P. Another project with matching spellings has not reused this family unless it resolves the same exact L, declaration, and members.
Project-local TEVB reuse follows the same rule. A project may retain one or more exact references from a materialized local TEVB declaration when their exact P rules fit. It preserves each <editionDesignator(L_source), sourceFamilyDesignator, sourceViewpointRef> tuple and any omission decision. It does not expand a global TEVB core, infer a cross-family import relation from labels, or claim that E.17.2's four-position template is a materialized family.
candidateViewRecordSetRef names an exact C.13 collection of permitted description or specification-use record forms for one structure-kind binding. The binding and family declaration may help retrieve candidate E and resolve exact P, but neither makes the fixed E.17.0 predicate true, identifies an EpistemeViewpointConformanceRelation occurrence, grants U.View membership, or creates the selected structure. The collection is not a publication face or package grouping, and it neither supplies a ViewFamilyId nor adds a viewpoint; publication forms, carriers, catalogue locators, and family designators remain separate.
Structural-view publication-use boundary
This is the C.30.ASV structural-view publication-use boundary. C.30.ASV covers the description episteme's identity, selected architecture-relevant structure, structure kind, E.17.0 viewpoint conformance, construction history, correspondence, hidden and lost structure, source return, and the next architecture move. When a view, diagram, graph, card, benchmark, probe output, model publication, or architecture note is used for evidence sufficiency, safety assurance, gate passage, release permission, work record, or decision authority, use the applicable pattern for that claim; keep only the structural-view record and next architecture move in C.30.ASV.
Initial architecture structure kinds and view records
The initial set is a seed for first architecture moves, not an atlas. Use the table to choose one structure kind under consideration and the applicable pattern for any non-ASV claim.
Classifier values defined outside C.30.ASV remain admissible when they are the architecture-relevant structure under consideration, but C.30.ASV does not define their full record families:
Minimum useful seed examples:
SecurityTrustBoundaryStructure carries adversarial-boundary interpretation: which protected assets or effects are under consideration, who or what is trusted, where untrusted input crosses, what authority or privilege is exposed, which adversarial paths and attack exposures matter, which data-flow or control-flow security boundaries matter, and where secure defaults, hardening, update or supply-chain channels, detection, or response boundaries change the next architecture move.
Apply evidence, assurance, gate, or compliance patterns only when the architecture move relies on evidence sufficiency, assurance verdict, gate passage, regulatory acceptance, or release authority. If the selected move is structural, first recover the structure: trust boundary, loss-control relation, control relation, evidence reuse structure, or affected structure or affected view.
Use a SafetyLossControlStructureNote when a safety-architecture concern first needs the architecture-side loss-control structure rather than a safety-case verdict:
The note gives a positive first architecture move: find the loss-control structure, controlled process or plant, constraint, foreseeable misuse, operational design scope, and action-relevant boundary. It does not replace evidence, assurance, gate, causal, dynamics, or temporal claims.
Functional structure view boundary
A FunctionalStructureView under C.30.ASV does not mint U.Function, U.Transformation, or a bearer relation. It is the same ArchitectureStructuralView episteme whose EntityOfConcern is one selected functional U.Structure and whose exact viewpoint conformance obtains. It may carry FunctionalElementClaim epistemes when the claim graph relates that selected functional structure to required or desired behavior or effect content and to a bearer or candidate-bearer locus. The claim is not identical with any actual behavior occurrence, bearer, capability, port, allocation, or relation.
Keep three branches explicit:
- required or desired behavior or effect: a C.2.1 claim; use the applicable requirement, architecture, capability, method, or functional-view pattern for that claim;
- actual transformation: an independently identified
U.Transformationonly after A.3.4 recovers the changed referent, extent or boundary, boundary conditions, actual before, during, and after facts, and continuity or reidentification basis; - compound flow organization: an exact selected
TransformationFlowStructureunder E.18, whose constituents and selected obtaining relations are independently identified; the structure is not itself an actual transformation.
FunctionalElementClaim has ordinary C.2.1 identity <exact ClaimGraph, one exact EntityOfConcern, effective U.ReferenceScheme>. For this use its EntityOfConcern is the selected functional structure. Its claim content may name:
- one or more required or desired behavior or effect claim refs;
- actual transformation refs only when the complete A.3.4 basis independently obtains;
- selected transformation-flow structure refs for compound flow organization;
- a bearer or candidate-bearer locus, normally a
U.Systemor candidate system for a separately established transformer system-role-kind claim; - capability, input and output condition, functional-port, dependency, allocation, and correspondence refs only when the applicable pattern defines or tests that relation or claim.
If no bearer or candidate allocation is current, do not claim a filled functional element. Record a required-behavior gap, required-effect gap, capability gap, functional-behavior slot, or candidate allocation question. This preserves the practical architecture move without pretending that a module, component, diagram row, function word, requirement, or selected flow structure has already supplied the bearer or actual change.
Required cooling effect followed by actual cooling. Requirement episteme RequiredCoolingEffect-1 says that Rack 7 should be brought below 30 °C during declared operation. Before the rack or cooling loop has changed, that is required effect claim content: there is no actual U.Transformation, even if a functional-view row, flow diagram, or selected TransformationFlowStructure cites it. Later, Rack7CoolingTransformation-42 may be identified under A.3.4 when the exact changed referent and boundary are fixed, operating and ambient boundary conditions are stated, actual before facts show 38 °C, actual during facts recover heat removal, actual after facts show 27 °C, and continuity or reidentification keeps the same referent recoverable. A separate satisfaction or realization predicate is still needed before claiming that the later transformation satisfies RequiredCoolingEffect-1; temporal succession or matching labels alone is insufficient.
A selected transformation-flow structure, mathematical graph description, transformation-flow path slice, crossing, or flow valuation is not a functional element or actual transformation by default. When a transformation-flow relation is being used, connect the functional view to the exact TransformationFlowStructure through C.30.TFS-REL. When a mathematical graph description is being used, connect it through [E.18.2](/generated/patterns/E.18.2); when math-lens use is being claimed, connect it through [C.29](/generated/patterns/C.29). When module allocation is being claimed, use [A.6.M](/generated/patterns/A.6.M) to repair the module claim and identify the admitted allocation or interface relation separately rather than treating function and module as one kind. Functional ports and module interfaces can both use U.Signature discipline, but functional ports specify behavior input and output slots while module interfaces specify substitution, compatibility, boundary, and change-policy claims.
Composability and quality compositionality are separate claims. If the view says parts can be assembled, keep that as a structure claim or use claim. If it says a quality of the whole follows from parts, assign the quality-composition claim to [C.25](/generated/patterns/C.25) and C.16-backed measurement or quality claim.
Compositional formalisms may express explicit composition structures, view relations, and model relations. They do not make required behavior actual, create transformations, or make safety, latency, reliability, or another quality propagate automatically.
Correspondence and source return
Use correspondence records when the view relates functional, flow, control, module-interface, information, runtime, placement, work, evidence, scale, or logical structures. Do not assert cross-view consistency by prose alone.
Correspondence examples:
Use SourceReturnCondition when compression, extraction, coarsening, evidence reuse, ML evaluation, bounded exception, many-to-many allocation, publication, or decision claim hides a distinction needed for action, assurance, causal use, law-domain review, regulatory review, comparison, or reopening.
If viewConstruction is query, extraction, coarsening, correspondenceSlice, or sourceReturnSlice, and omitted structure changes action, assurance, causal use, law-domain or regulatory review, or subsequent decision reopening, SourceReturnCondition is needed.
When the view is used to name affected structures for a next architecture use but no decision record is being used, use C.30 AffectedArchitectureStructureNote: affected structure kinds, affected structure refs when known, affected ASV refs, accepted or suspected view loss, source-return condition, and the next admissible use. The note is not an architecture decision, ADR, gate passage, evidence sufficiency, or release authority.
Use the thinnest source or reliance relation that preserves the next architecture move. Use fuller source, evidence, assurance, or claim-kind relation only when the source or reliance relation being used cannot be inspected, used, compared, refreshed, or bounded without it. A ControlStructureViewNote may precede full C.30.LCA use or use of the applicable proof or assurance pattern when one control relation and its boundary are enough for the architecture move being made.
Treat source return as a user action, not only a metadata field:
Do not make source return mandatory for ordinary local recognition when no hidden distinction is being used for action. Do not omit source return when a hidden distinction carries a selected reliance relation, assurance, law-domain, comparison, causal, gate, or decision commitment. The condition is needed only when the repaired text still relies on the hidden source-side distinction.
Model cards, system cards, and evaluation harness reports may publish or substantiate an architecture structural view only when the structural-view claim is recoverable. The view must name the relevant structure kind, such as RuntimeInteractionStructure, InformationDataStructure, SecurityTrustBoundaryStructure, EvidenceAssuranceStructure, ModuleInterfaceStructure, or another declared structure kind; it must also state intended-use scope, evaluation scope and known loss when evaluation is used, deployment-context mismatch when that mismatch is being claimed, and the applicable evidence or assurance pattern when the publication is used beyond transparency. A card or harness is not architecture adequacy, safety proof, or release claim or gate claim by publication alone.
Currentness and smallest reopen. When a decisive input changes, reopen only the ArchitectureStructuralView locus and use conclusions that depend on it. A changed selected structure or structure kind reopens its exact structure fields and, when another structure becomes the EntityOfConcern, requires a separately identified description episteme; a changed description identity reopens only that episteme's view admission; a changed viewpoint or conformance occurrence reopens only the E.17.0 predicate; changed construction or knowledge state, correspondence, source edition or lost structure reopens the matching provenance, correspondence, source-to-use, hidden or lost structure, or source-return locus; and a changed admissible-use boundary or applicable rule reopens only its dependent use or claim. Update that locus, demote the episteme to a structural description or ArchitectureStructureKindTriage@Project, narrow use, return to the named source, or stop; unrelated structures, views, and claims stay closed.
Worked slices
Runtime degradation. A team says, "The architecture is fine, but incidents happen when failover starts." The first architecture move is to recover runtime interaction, control relation, failover relation, placement, and evidence-assurance structures before turning a dashboard or deployment diagram into proof:
Use [C.24](/generated/patterns/C.24) only when tool-use, call planning, call graph, work execution, or budgeted agentic tool-use is the claim being made. Do not absorb those claims into architecture structure.
CPS or plant architecture. A plant drawing, P&ID-like publication form, LCA sketch, or safety-case view is not the plant architecture by itself. First recovery can require:
Chiplet or device architecture. A packaging diagram or interconnect sketch may involve several structure kinds:
Organization or operating-model architecture. An org chart or Work-Method diagram can be architecture-relevant only after Systems, local system-role kinds, separate System-classification judgments, assignments, enactor relations, complete actual-Work bases, direct responsibility relations, concern or affected-party relations, information, and evidence are separated:
Evidence reuse across product variants. A certification or test package reused across module variants may be architecture-relevant as an evidence-and-assurance structure view, but it is not an assurance verdict:
Organization service architecture. A service organization sketch that shows teams, handoffs, escalation points, and dashboards is not the organization architecture by itself. First recovery can require:
AI agent diagram. A "planner-memory-tools" diagram is not the agent's architecture by itself. It may start first recovery as a structure-kind set, without minting an AI-domain ontology:
Structural AI-agent security is architecture structure when these structure kinds change the next architecture move. When the claim is instead about latent representation, decoding, or effect adequacy, keep the phrase as a reduced-use source cue and use the applicable representation, decoding, or effect-adequacy pattern.
Generated code-agent relation graph. A probe JSON or code-agent architecture relation graph can be an architecture structural view publication only after observed, inferred, or unknown observation value, evidence pointers or source pointers, unexplored regions, typed relation semantics, and source-return conditions are present. Use the applicable proof and assurance patterns for the separate belief-state and downstream-change-safety claims.
Neural-network block replacement. Replacing attention, FFN, convolution, SSM, recurrent, memory block or cache block, MoE expert-selection, pruning, distillation, or another block is an architecture move only when the changed structure kind, flow relation, module-interface claim kind, preserved and lost structure, affected characteristic, source relation, and applicable decision or evidence pattern are named.
Archetypal Grounding
Bias-Annotation
Lenses tested: Arch, Onto, Epist, Prag, Did, Gov. Scope: architecture structural-view claims over holons.
This checklist verifies the preceding guidance after the practitioner has chosen the selected repair action; it is not a required project control form and not a substitute for the card, note, description, direct conformance relation, or repair guidance above.
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
Rationale
C.30.ASV exists because architecture descriptions are commonly multi-view, but FPF cannot let "view" absorb every architecture claim. A structure kind and a viewpoint are different. A structure kind says what kind of selected structure is described; a viewpoint is one exact episteme whose fixed rules the candidate description must satisfy. The direct conformance occurrence, not a label or bundle, makes the same episteme a U.View.
The pattern keeps first use light by providing ArchitectureStructureKindTriage@Project. If triage identifies the structure kind under consideration and the next admissible architecture move, no full view record is needed. The full record is used when exact conformance obtains and a view changes action, correspondence, publication, source return, source or reliance use, or non-view claim kind.
The TEVB decision is conservative. E.17.2 supplies a four-position project-local authoring template, not a current family or importable bundle. Architecture may reuse only exact U.ViewpointRef values resolved from a materialized local declaration, with catalogue and member provenance preserved. Architecture-specific structure kinds and candidate-record bindings are defined beside those exact local references rather than mutating their resolved viewpoint epistemes or treating declaration membership as conformance.
SoTA-Echoing
SysML v2 is intentionally excluded from C.30.ASV's SoTA basis. This pattern treats it as a historical dead end rather than a source or lineage and derives no rule from it.
Relations
Builds on: C.30.P, C.30, A.1, A.22, C.2.1, E.24.PUB, A.6.3, E.17.0, E.17.1, E.17.2, A.7, E.10.D2, E.10, C.2.P, and F.18.
Coordinates with: A.6.F, A.6.M, C.30.TFS-REL, C.30.LCA, C.30.ILC, E.18, C.29, C.16, C.25, C.28, A.10, G.6, B.3, A.20, A.21, A.15, C.11, C.32.P2S, C.32, C.32.PAD, C.32.ADR, C.32.ADA, C.33, C.34, and C.35 when problem-to-structure carry-through, candidate-set, architecture-decision, ADR-projection, decision-adequacy, capture, preservation, or generated-carrier claim kinds are being made. Use A.6.M when a module-interface claim is being made, and separately identify the admitted module or allocation relation required by that claim.
Use these patterns for the other claims: C.30 for direct architecture relations, bounded architecture claims, and selected-structure adequacy; A.1 for the exact described holon; A.22 for selected-structure identity; C.2.1 for description episteme identity; E.17.0 for exact viewpoint conformance; E.24.PUB for publication occurrence, form, and carrier; C.29 for representation and mathematical-lens use; C.33 for captured and lost selected structure in a view; C.34 for preservation or correspondence between a view and another structure-bearing object; C.35 for generated or discovered carriers before candidate admission; E.18 for selected transformation-flow structure, transformation-flow path, and crossing discipline; E.18.2 for mathematical graph descriptions; C.16 for characterization; C.25 for Q-Bundles; C.28 for causal use; A.10 and G.6 for evidence; B.3 for assurance; A.20 and A.21 for gate or release records; A.15 for Work and project-use relations; C.11 for decisions; and C.32.P2S for problem-to-structure carry-through when the view is one captured or lost-structure stage. C.30.ASV covers structural-view adequacy for the selected structure being viewed.
C.30.ASV:End
Control Structure View Adequacy (LCA)
Type: Architectural subpattern under
C.30Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when a control diagram, control-language source, or selected control structure changes the next architecture move. Start with an ordinary question: what actually controls what, through which observation, command, reference, supervision, or feedback relation? A label such as controller, plant, observer, planner, supervisor, or policy loop is only a cue; identify the relation and what each participant does in it before relying on the diagram.
A participating System, local system-role kind, System-classification judgment, assignment, Method, or Work is a separate fact. Add it only when it independently obtains and changes the use of the control-structure result.
The first useful result can be one sentence: “Supervisor S sends allowed-mode commands to controller C and receives status feedback; this diagram does not yet establish stability or safety.” The small note below retains that result and the next action. If the source says only layer, level, tier, or stack without a control-specific relation, use C.30.STRAT first.
What goes wrong if C.30.LCA is missed: a control diagram becomes the control structure, U.View, or proof; stratification labels bypass C.30.STRAT and carry undeclared scope; and B.2.5, E.18 transformation-flow prose, or Layered Control Architecture prose is overread as control adequacy.
What C.30.LCA buys in practice: the practitioner can keep useful controller, plant, observer, regulator, supervisor, feedback, rate, and control-layer language while recovering a selected control structure, one description episteme, its possible E.17.0 view conformance, and the pattern used to state or test each proof or claim.
Not this pattern when the issue under repair is generic stratification or source-label repair, only an E.18 transformation-flow path slice, function description, module boundary, measurement head, causal intervention, or safety case. Use C.30.STRAT, C.30.TFS-REL, A.6.F, A.6.M, C.16, C.28, or the applicable assurance or evidence pattern to state or test the current claim.
The primary EntityOfConcern for a full C.30.LCA description or view is one exact selected control U.Structure. The description, selected structure, controlled holon, architecture relation, architecture claim, viewpoint, conformance occurrence, control relations and their participants, any participating Systems, classifications, assignments, Methods or Work, diagram, representation, proof claims, and publication remain separate. Start with the smallest useful note:
Use either selectedControlStructureRef or an honest structureGap. A positive control claim also names at least one obtaining control relation and its participants. This note is enough when those values make the next action clear; its fields do not turn it into a C.2.1 episteme or U.View.
Add a described holon, an architecture-relation occurrence or claim, rate bands, control-layer relations, boundaries, view and viewpoint-conformance facts, source return, representation, or publication only when they change the intended use. Add participating Systems, local classifications, assignments, Methods, Work, and F.6 attribution only when those neighboring facts are independently current.
When either form includes actual control Work, each Work ref names an occurrence independently admitted under A.15.1 after every exact actual performer is recovered through A.13. assignmentRows and actualControlWorkAttributionRefs remain optional: include them only when the note, view, or receiving use expressly represents precise assignment-bound attribution. Any present attribution ref resolves through F.6 to the same obtaining A.13 assignment; absence or failure of that relation leaves the Work ref intact. The note or view creates none of these facts.
Use full ControlStructureView only when an independently identified architecture-description episteme about the selected control structure satisfies the fixed E.17.0 predicate for one viewpoint. Full use is justified when control-participant meanings, direct relations, rates, recovered control-layer labels, boundary refs, source return, representation or publication, or the patterns used for particular claims matter beyond the note.
Problem
Control diagrams are persuasive because they look operational: arrows imply feedback, boxes imply responsibility, and recovered control-layer labels imply separation. In practice that is often enough for orientation, but not enough to identify selected structure, make direct relations obtain, admit the description as U.View, or establish architecture adequacy. A control-stack description can quietly overclaim stability, safety, evidence sufficiency, gate validity, assurance, or causality; a non-control layer, level, tier, or stack label belongs first to C.30.STRAT.
FPF needs a pattern that preserves useful recognition without letting the cue become structure, relation, or proof. Direct control relations, their participant meanings, feedback relations, externality boundaries, and rate separations can enter an architecture structural description. The same episteme is a view only through viewpoint conformance. Systems, local kinds, separate System-classification judgments, assignments, Methods, and Work are optional neighboring facts; use the relevant patterns to state or test authority, responsibility, safety, stability, gates, evidence, assurance, and causal effects.
Forces
- Control talk is useful and current engineering practice uses it, so deleting it would make architecture prose less usable.
- The same source labels can name different things. C.30.LCA applies after an exact direct control relation, rate-band relation, control-layer relation, or
B.2.5supervisor-subholon relation is recovered. An assignment is neither required nor sufficient for control; include it only when it independently obtains. A model-use structure is cited only when that independently selected structure changes interpretation. - Layered and multi-rate control descriptions often need timing and dynamics claims before they can carry stability or safety claims.
B.2.5already gives FPF a supervisor-subholon feedback relation, but it does not turn every feedback or loop diagram into that occurrence, selected structure, or proof.- E.18
TransformationFlowStructurevalues and their mathematical graph descriptions can describe flow, path, crossing, or transformation-flow relations that participate in control, but the selected flow structure, graph expression, and control structure remain distinct. - Practitioners need one small first output; exact viewpoint conformance, dynamics, C.29, evidence, assurance, and gate records are used only when the question calls for them.
Solution
Treat LCA-like source descriptions as possible inputs to a control-structure description under C.30. Recover one described holon, any actual architecture relation, one selected control structure, the controlled holon, independently obtaining observation, actuation, reference, supervision, and feedback relations, and the participant meaning in each relation.
Add participating Systems, local kinds, separate System-classification judgments, assignment species and obtaining occurrences, Methods, and actual Work only when each independently obtains. Use A.22 to identify the selected structure from its constituents, selected obtaining relation occurrences, applied constraint claims, and receiving-use frame; a note, diagram, list, description, kind, or assignment creates none of them. If a source label is not yet control-specific, apply C.30.STRAT first. Then state admissible use and the next pattern to use.
When the result must retain boundary, admissible-use, or handoff detail, expand the same ControlStructureViewNote:
Use rateBandRef?, controlLayerRelationRef?, and externalityBoundaryRef? only when that object or relation changes the control-structure use. Otherwise the note may stop after one actual control relation, feedback-closure state, and the next pattern to use. Generic stratification labels stay with [C.30.STRAT](/generated/patterns/C.30.STRAT) until a control-specific relation is recovered.
When a recovered control-layer relation is used to justify decomposition, substitution, or design reliance, recover the inter-layer assumption-guarantee relation or mark the control-layer relation as orientation only. interLayerControlRelationRefs? is used only when the relation is already control-specific and is used for decomposition, substitution, design reliance, safety, or stability claims.
Use this note only when a recovered control-layer relation is used for decomposition, substitution, a safety or stability claim, or an architecture decision. It is not proof and does not make the relation obtain. Otherwise keep C.30.LCA at the small note or ordinary description form, or use [C.30.STRAT](/generated/patterns/C.30.STRAT) to recover the source label.
The full view is the same C.2.1 episteme identified by its exact claim graph, selected-control-structure EntityOfConcern, and effective scheme. Its direct E.17.0 conformance occurrence has exactly that candidate episteme and one exact viewpoint episteme as participants. It obtains only when the fixed five-part predicate is true, and those participants determine its identity. Authoring, A.6.3 construction, a viewpointRef, query, selection, bundle membership, diagramming, rendering, publication, or current use does not make it obtain.
controlledHolonRef names the holon whose state is observed or changed by independently obtaining control relations and may be the described holon or one of its exact parts. Architecture claims, ClaimScope, model-use structure, concern, and empirical grounding remain optional neighboring objects or relations. modelUseStructureRef appears only when an independently selected DDD-style bounded-model-use structure changes interpretation or selection.
For every positive control-relation reference, identify the actual occurrence and use the relevant pattern to recover what its participants mean. Any participating System, local classification, assignment, Method, Work, or F.6 attribution also identifies its own independently admitted fact. A classification or assignment establishes neither control nor action.
The description, control note, view record, and diagram create none of these occurrences and do not act. Representation, publication occurrence, form, and carrier likewise remain separate from the selected structure and view episteme.
Safety-loss control-structure note
Use a SafetyLossControlStructureNote only when safety wording is being used for a loss-control claim and the practitioner first needs the architecture-side loss-control structure, not a safety-case verdict:
The note gives a positive safety-triggered architecture move: find the loss-control structure, controlled process or plant, constraint, foreseeable misuse, operational design scope, and action-relevant boundary. It does not replace the generic control-structure view and does not replace evidence, assurance, gate, causal, dynamics, or temporal claims.
Control-participant interpretation.
Control-specific stratification gate. Layer, level, tier, and stack enter C.30.LCA only after [C.30.STRAT](/generated/patterns/C.30.STRAT) or the local sentence recovers a direct control relation, inter-layer control relation, rate band, or [B.2.5](/generated/patterns/B.2.5) supervisor-subholon relation. An assignment alone is insufficient, and the label by itself establishes neither control structure nor separation.
B.2.5 boundary. Use [B.2.5](/generated/patterns/B.2.5) for the supervisor-subholon feedback relation. A [C.30.LCA](/generated/patterns/C.30.LCA) use may cite that relation as part of the selected control structure, but use the relevant patterns for stability, safety, causality, evidence, gate, and assurance claims. If action involving an episteme is claimed, recover the exact performing System through A.13 and admit the dated Work and enacted Method independently through A.15.1. Add an assignment occurrence and F.6 only when the account expressly consumes precise assignment-bound attribution; keep publication, source-to-use, and work-reliance relations separate. An episteme does not sense, decide, plan, adapt, or act.
Transformation-flow boundary. An [E.18](/generated/patterns/E.18) transformation-flow path slice may supply flow-structure, path, crossing, or transformation-flow-structure input to the control view when that relation is being used. The transformation-flow graph expression remains a mathematical description or view of transformation-flow structure. It does not become the functional architecture, the control structure, or proof of control adequacy.
C.29 boundary. An LCA can be a model used for one selected control structure, or it can be used as a transferable mathematical lens. Open [C.29](/generated/patterns/C.29) only when transfer, prediction, reusable cross-domain explanation, or mathematical-lens use is being claimed. Dynamics, rate bands, authored temporal-claim adequacy, and causal claims remain with [A.3.3](/generated/patterns/A.3.3), [C.27.TA](/generated/patterns/C.27.TA), [C.27](/generated/patterns/C.27), and [C.28](/generated/patterns/C.28).
Nesting and scale rule. If a control-structure view nests without a local depth limit, the record uses scaleAuditRef? when the nesting affects latency, stability, observability, accountability, or assurance.
Worked slice A - LCA diagram used as proof. A safety note says: The Layered Control Architecture proves the plant is safe because the supervisor monitors the lower controller. A conforming repair keeps the control-structure view and names planner, controller, plant, and supervisor relations, observation and actuation boundaries, and any rate bands. Use [B.3](/generated/patterns/B.3) for safety and assurance, [A.10](/generated/patterns/A.10) or [G.6](/generated/patterns/G.6) for evidence, [C.27.TA](/generated/patterns/C.27.TA) for temporal aspects and rate bands, [C.27](/generated/patterns/C.27) for authored temporal-claim adequacy, and [A.3.3](/generated/patterns/A.3.3) or the applicable dynamics pattern for dynamics or stability.
Worked slice B - multi-rate controller. A source says a control stack has a slow planner, a faster regulator, and an observer with a different update period. Apply [C.30.LCA](/generated/patterns/C.30.LCA) only after the stack label has been recovered as exact reference-provision, regulation, observation, or other control relations with their participant meanings and rate bands; otherwise use [C.30.STRAT](/generated/patterns/C.30.STRAT) first. Systems, classifications, assignments, Methods, and Work are added only where independently current. A C.30.LCA description establishes no rate adequacy. If the rate relation matters for oscillation, latency, stability, or safety, next use [C.27.TA](/generated/patterns/C.27.TA) for temporal aspect or rate-band structure, [C.27](/generated/patterns/C.27) when an authored temporal-claim adequacy question is under repair, and the dynamics or assurance pattern named by value when that claim kind is being made.
Worked slice C - supervisor-subholon loop. A subsystem is supervised by an external controller System. The C.30.LCA note records the supervisor-subholon relation and may reference [B.2.5](/generated/patterns/B.2.5). If that System performs mode-change Work, recover it through A.13 and admit the Work and enacted Method independently through A.15.1. Add an assignment occurrence and F.6 only when this slice also expressly represents precise assignment-bound attribution; missing or failed F.6 leaves the mode-change Work intact. Authority, responsibility, gate passage, safety, stability, and policy-constraint results remain separate claims under their own patterns; the supervisor relation establishes none of them.
Currentness and smallest reopen. When a decisive input changes, reopen only the control-structure locus and the use conclusions that depend on it. A changed selected control structure or controlled holon reopens the affected ControlStructureViewNote or full description and view; a changed direct control relation or participant meaning reopens that occurrence and its dependent structure selection; a changed classification, assignment, Method, Work, or F.6 attribution reopens only that neighboring fact and any view use that relied on it. Changed feedback, rate, or control-layer relations reopen only their matching relation or boundary fields; changed view conformance reopens only the E.17.0 admission; and a changed source edition reopens its source-to-use and source-return locus. A changed authority, responsibility, safety, proof, evidence, assurance, or gate claim reopens only that neighboring claim unless a control-structure input also changed. Update the affected locus, demote full view use to a note or orientation, narrow use, or reopen the control-structure question; unrelated structures and claims stay closed.
Archetypal Grounding
Bias-Annotation
- Diagram authority bias. A neat feedback diagram can look more persuasive than the structure, source-to-use path, work-reliance relation, or claim it actually supports. Repair by naming each object or relation and the pattern used to state or test the claim.
- Stratification-label bias. A
layer,level,tier, orstacklabel can hide whether it names a control relation, rate band, aggregation, scale, organization, Work scope, evidence scope, deployment, or publication section. Repair withC.30.STRAT; C.30.LCA applies only to the recovered control-specific case. - Supervisor anthropomorphism. A supervisor label can make an episteme, policy, assignment, or dashboard sound agentive. Repair by recovering the supervision relation first. If action is claimed, recover the exact performer System through A.13 and admit the dated Work and enacted Method independently through A.15.1. Add assignment and F.6 only for an expressly consumed precise assignment-bound attribution; recover authority, responsibility, gate, safety, and evidence separately.
- Transformation-flow and LCA conflation. A transformation-flow graph expression and a control description or view can inform each other, but neither replaces the other. Repair by naming the EntityOfConcern, structure kind, and direct relations for each.
This checklist verifies the preceding guidance after the practitioner has chosen the selected repair action; it is not a required project control form and not a substitute for the note, description episteme, conformance occurrence, direct control relation, or repair guidance above.
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
The gain is a small, usable control-structure output that preserves common architecture language while blocking structure, view, and proof overread. Practitioners can still say controller, plant, supervisor, feedback, and control layer, but the record shows the selected structure, the boundary between description and view, and the direct relations those words carry; generic stratification labels use C.30.STRAT first.
The cost is an extra relation or conformance note before downstream reliance. When the claim is only recognition, that cost is small. When it is view membership, safety, stability, evidence, assurance, or gate passage, the cost is appropriate because none was carried by the diagram alone.
Rationale
Control architecture is too important to leave to diagram authority and too useful to remove from architecture language. The FPF move is to keep the practice cue and recover control-structure content first: selected structure, controlled holon, actual architecture relation when current, direct control relations and participant meanings, recovered rate or control-layer labels, observation and actuation boundaries, externality boundaries, and next admissible move. Systems, classifications, assignments, Methods, Work, and F.6 attribution are added independently; use their own patterns for authority, responsibility, gate, safety, stability, and evidence. The full record is one description episteme and, only through E.17.0 conformance, the same episteme as U.View. It can cite C.30.STRAT, B.2.5, E.18 transformation-flow structure, dynamics, C.27.TA, C.27, C.28, evidence, assurance, gates, and C.29, but does not absorb their claim kinds.
This protects subject, structure, episteme, View, representation, and publication boundaries. Several descriptions may have the same selected control structure as EntityOfConcern, and one description may be published repeatedly without changing identity, creating the structure, granting view membership, or making direct relations obtain.
SoTA-Echoing
Relations
- Builds on
C.30for direct architecture relations and selected-structure adequacy,C.30.ADfor description identity and use,E.17.0for direct viewpoint conformance, andC.30.ASVfor structural-view adequacy. - Uses
A.22for exact structure identity and structure-kind discipline. - Coordinates with
C.30.STRATwhen layer, level, tier, stack, ladder, rung, block, expert, cache, router, gate, or similar source labels must be recovered before control-specific use. - Coordinates with
B.2.5for supervisor-subholon feedback relation recognition. - Coordinates with E.18 and C.30.TFS-REL when transformation-flow path slices supply structure input to the control view.
- For neighboring claims, use
A.3.3for dynamics or stability,C.27.TAfor temporal-aspect or rate-band structure,C.27for authored temporal-claim adequacy,C.28for causal use, A.10 or G.6 for evidence, B.3 for assurance, A.20 or A.21 for constraint validity or gates, A.15 for Work or project use, E.24.PUB for publication, and C.29 for representation or transferable mathematical-lens use.
For neighboring claims, use C.30.STRAT for stratification or source-label repair; C.30 for actual architecture relations and selected structures; C.30.AD for description; E.17.0 or C.30.ASV for view conformance and adequacy; B.2.5 for supervisor-subholon feedback; E.18 for graph, path, or crossing structure; A.3.3 for dynamics; C.27.TA or C.27 for temporal claims; C.28 for causal use; A.10 or G.6 for evidence; B.3 for assurance; A.20 or A.21 for gate and constraint-validity records; A.15 for Work; E.24.PUB for publication; and C.29 for representation or lens use. Use C.30.LCA only for the control-structure description or view-adequacy question at issue.
C.30.LCA:End
Cross-Scope Architecture Residual Triage
Type: Architectural subpattern under C.30 Status: Stable Normativity: Normative for FPF pattern, companion-text, and project-description use that claims architecture-specific residuals across declared scopes.
Problem frame
Use this pattern when a project situation contains a cross-scope architecture residual for a described holon, often described in project speech as:
First-minute use slice. A robotics team says a local controller upgrade made each arm faster, but cell-level stoppages and audit exceptions grew. Before drawing another architecture view, C.30.ILC records: described holon = assembly cell; declared levels and scopes = arm controller, cell control, evidence scope; level-bearing selected structure = control and evidence-reuse structure; residual-bearing locus = control-rate conflict plus evidence-reuse failure; local repair already attempted = retuned each arm controller; first architecture move = add or change mediator relation or control-layer relation and apply [C.30.ASV](/generated/patterns/C.30.ASV) for the selected structural view.
The first useful move is CrossScopeArchitectureResidualTriageRecord@Context: name the affected declared holon levels or declared scopes, the selected structure in which those levels or scopes are recoverable, residual-bearing locus, local repair already attempted, why local repair is insufficient, and the first admissible architecture move or subject-pattern application.
The primary EntityOfConcern is the cross-scope or interlevel architecture residual in the described holon or holon family for a named architecture concern and intended use. The described holon may be an admitted system, organization-as-system, episteme, work occurrence, discipline, or another admitted holon kind. Publication-family material uses the episteme and publication patterns. A MethodDescription is an episteme; a Method uses [A.3.1](/generated/patterns/A.3.1) and the relations claimed for it. A phrase in a description, a diagram label, or a mathematical-lens output may make the residual visible, but it is not the residual itself and does not become the center of this pattern.
InterlevelConflict@Context applies when two or more declared holon levels, declared scopes, or level-bearing structure relations of the same described holon or holon family impose incompatible or tensioned constraints, objectives, admissibility conditions, tempos, resource allocations, information-transfer relations, or assurance requirements. Examples include declared system levels, declared episteme levels, aggregation scopes, typed control layers, declared organizational scopes, work scopes, evidence scopes, system scopes, environment scopes, description-use scopes, publication-use scopes, or other declared scopes. A selected structure matters here only when it carries, separates, or relates the declared levels or scopes. A conflict between structures belongs in C.30.ILC only when those structures are assigned to different declared holon levels, declared scopes, scale windows, or coarse-graining steps; a same-level, same-scope, or unassigned conflict between structures belongs elsewhere until a level, scope, scale-window, or coarse-graining assignment is recovered.
FrustrationResidual applies when a persistent cross-scope or interlevel residual remains after local repairs have been attempted or deemed insufficient: local optimization in one declared holon level or declared scope improves local fit while degrading, blocking, or destabilizing another declared holon level, declared scope, or level-bearing structure relation.
ComplexityGrowthPressure is admitted only as conditional architecture pressure: reducing an interlevel residual may require adding, splitting, mediating, or stabilizing a declared holon level, declared scope, aggregation scope, interface grammar, control loop, evidence scope, work-method scope, abstraction scope, source-return scope, or declared system level when that special case is being claimed. It is not a claim that complexity is good or that complexity necessarily grows.
Entry condition: if declared holon levels or declared scopes, the selected structure or architecture structure kind that carries them, one residual-bearing locus, and one first admissible architecture move cannot be named for the described holon in context, keep the issue at ordinary problem framing or ProblemCard@Context; do not claim CrossScopeArchitectureResidualTriageRecord@Context yet.
What goes wrong if C.30.ILC is missed: a local improvement, control layer, scale label, interface grammar, or evidence reuse is treated as whole-holon architecture adequacy while the residual moves into another declared holon level or declared scope.
What this buys: the practitioner can name the residual-bearing locus, the declared levels or scopes, the local repair already attempted, and one first architecture move without turning multilevel frustration, scale, ethics, evidence, or mathematical-lens use into this pattern's object.
What C.30.ILC buys in practice: the practitioner can keep useful conflict or frustration language as an entry label while governing the architecture residual itself: affected holon levels or scopes, the selected structure that carries them, residual-bearing locus, and one admissible architecture move or subject-pattern application.
Interlevel conflict and frustration may appear in ordinary project descriptions, but the conforming record governs the residual through declared holon levels or declared scopes, the selected structure that carries them, and a residual-bearing locus. The pattern does not create a generic level scale or U.Frustration. It asks which declared holon level, declared scope, aggregation scope, control layer, organizational scope, work scope, evidence scope, system scope, environment scope, scale window, interface grammar, allocation boundary, publication section, or source-return condition bears the residual. A system level or episteme level is a special case of a declared holon level.
Not this pattern when the issue under repair is only ethical value framing, interlevel ethical conflict structure, ethical mediation or decision use, measurement, scale relation, coarse-graining relation, mathematical-lens validation, candidate generation, residual-reducing candidate-set work, final selection, causal outcome, evidence, or assurance. Use the subject pattern and keep C.30.ILC only to the architecture residual-bearing locus.
Problem
Architecture work often starts from a residual: a local fix works in one declared holon level or declared scope and fails in another. Component optimization increases whole-holon or product-line integration cost. A new module boundary reduces local complexity and increases exceptions at the product-line scope. A control layer improves local safety and creates accountability or latency claims elsewhere. A reusable evidence set reduces repeated work and hides a new source-return condition.
The useful architecture intuition is narrower than a new Frustration kind: local optimization at one declared holon level or declared scope can create a persistent residual in another declared holon level, declared scope, or level-bearing structure relation. When a recoverable multilevel, scale, or coarse-graining mapping is claimed, use C.29 to state and test that lens use. When the claim compares architecture alternatives over a declared scale window, use C.31.ASAP. Use C.32.MLAO and C.32 for residual-reducing candidate work, and use G.5 only to declare a selected-set result. If that result is made available to an audience, use E.17 for a source-backed publication face and return to source and E.24.PUB for the publication occurrence, form, carrier, audience, bounded use, and availability. An ordinary conflict between structures is not enough for the RG lens or frustration mathematical lens, but a conflict between structures assigned to different declared holon levels or scale windows may be enough when the mapping, preserved-structure line, and lost-structure line are recoverable. The first C.30.ILC output is only the grounded triage record.
Without a pattern, teams either discuss the residual as vague complexity, treat it as an ordinary negotiation problem, jump into measurement, use mathematical frustration language as proof, or jump to candidate generation too early. C.30.ILC keeps the first move small: identify whether the residual is architecture-shaping and name the first admissible architecture move or subject-pattern application.
The practical work is often not to draw another view. It is to assign the residual to the locus named by value that can bear it: declared holon level, declared scope, level-bearing selected structure, structure kind, constraint, characteristic or Q-bundle, evidence-reuse boundary, source-return condition, or non-architecture claim kind.
Forces
- Local optimization can be real and still be harmful at another declared holon level or declared scope.
Level,layer,scope,scale,abstraction,organization,system, andenvironmentlabels can sound precise while naming different project-side entities, relations, scopes, or claim kinds.- Frustration language can be useful because it points to incompatible constraints or fitness contributions, but it can also smuggle a physics, biology, psychology, or global-optimizer ontology into architecture prose.
- Measurement is tempting because the residual feels numeric, but a measure before declared-scope and structure-kind recovery can hide the real conflict.
- Ethical conflict or mediation may be present, but not every cross-scope residual is an ethical conflict or mediation problem.
- Architecture synthesis may be needed, but a small triage output often identifies a narrower move: split scope, add mediator, add interface grammar, change allocation, expose coupling, add evidence scope, accept bounded exception, or return to source.
- The pattern is not a prescribed sequence of moves; architecture work is often case-managed through loops, checks, and dead ends.
Solution
Create a CrossScopeArchitectureResidualTriageRecord@Context when an architecture concern is carried by residuals across declared holon levels, declared scopes, or level-bearing structure relations.
Layer, level, tier, stack, and declared-scope labels. Declared holon level is the general level-bearing recovery field for this pattern; system level and episteme level are special cases when the described holon or selected structure makes them relevant to the claim. System level may remain as ordinary recognition language when a practitioner would naturally use it, but the record recovers the project-side scope references through declaredHolonLevelRefs or declaredScopeRefs; a system level is not the default architecture level. When the source says layer, level, tier, or stack, recover exactly one or more of: declaredHolonLevelRef, controlLayerRef, declaredSystemLevelRef, aggregationScopeRef, rateBandRef, organizationLevelRef, workEvidenceScopeRef, scaleWindowRef, or publicationSectionRef when the wording only names a document layer. A move such as splitDeclaredHolonLevel, splitDeclaredScope, or, in the special system-level case, splitDeclaredSystemLevel is admissible only when the affected declared holon level, declared scope, selected structure, declared system level, aggregation scope, control layer, organization scope, work scope, evidence scope, system scope, environment scope, rate band, scale window, publication section, or source-return condition is named. A layer label is not a structure kind, not a system level, not a rate band, and not evidence of separation by itself.
Interlevel conflict, frustration residual, and complexity-growth recovery. A conflict is architecture-shaping only when the record names the declared holon levels or declared scopes, the selected structure or structure kind that carries them, and the conflict carrier: constraint, objective, admissibility condition, tempo, resource allocation, information-transfer relation, or assurance requirement. A frustration residual is architecture-shaping only when local repair or local optimization leaves a persistent residual in another declared holon level, declared scope, or level-bearing structure relation. Complexity-growth pressure is only a candidate reason to add, split, mediate, or stabilize structure when that change is expected to reduce the residual enough to justify the new cost and its own residue.
crossScopeResidualDescription is not enough by itself. A residual becomes architecture-shaping only when its residual-bearing locus is declared: hidden coupling, interface exception, control-rate conflict, scale-window loss, evidence-reuse failure, regulatory bespoke residue, work-method exception, data-semantics drift, placement or jurisdiction conflict, security trust-boundary break, or another declared locus.
Multilevel optimization boundary. First establish whether local optimization in one declared holon level or scope degrades another declared holon level or scope. This triage neither optimizes the architecture nor proves that one global function exists. Use [C.29](/generated/patterns/C.29) with MLU.Description@MultilevelLearningFrustration only when the mathematical representation supplies a recoverable mapping between declared levels, scopes, scale windows, or coarse-graining steps and states what structure is preserved and lost. Conflicting structures can enter this lens only when each structure is assigned to a declared holon level, scope, scale window, or coarse-graining step and the mapping shows why the conflict is interlevel. If scale window, RG relation, coarse-graining relation, preserved structure, lost structure, or conflict residual slope becomes an architecture scale-preference claim, use [C.31.ASAP](/generated/patterns/C.31.ASAP) and keep any mathematical-lens claim in [C.29](/generated/patterns/C.29). If the practitioner needs to generate or compare residual-reducing candidate architecture moves, apply [C.32.MLAO](/generated/patterns/C.32.MLAO) for the residual-reducing multilevel candidate frame and [C.32](/generated/patterns/C.32) for the candidate palette. Use [G.5](/generated/patterns/G.5) only when selected-set result declaration is current and [C.11](/generated/patterns/C.11) when final local choice is current. For audience publication, use [E.17](/generated/patterns/E.17) for a source-backed face and return to source and [E.24.PUB](/generated/patterns/E.24.PUB) for the publication occurrence and audience availability. Use [C.32.PAD](/generated/patterns/C.32.PAD) when a project architecture decision is current. Stop the C.30.ILC use at the residual and first admissible move. If the case is only a conflict between two selected structures with no declared multilevel or scale mapping, keep it in [C.30](/generated/patterns/C.30), [C.30.ASV](/generated/patterns/C.30.ASV), [D.3](/generated/patterns/D.3), [D.4](/generated/patterns/D.4), [C.28](/generated/patterns/C.28), evidence, assurance, or decision patterns as applicable.
Anti-collapse rule: no generic frustration score, no risk-matrix residual, no ethical-mediation takeover, no physics or biology ontology transfer, no global-optimizer proof, no causal proof, and no assurance proof. A frustration or risk label does not govern the case until declared holon levels or declared scopes, the selected structure or structure kind that carries them, residual-bearing locus, and first architecture move are recoverable; [D.3](/generated/patterns/D.3) applies only when an interlevel ethical conflict needs an inspectable description; [D.4](/generated/patterns/D.4) applies only when mediation or decision use of that D.3 description is current.
Stop condition. Stop after CrossScopeArchitectureResidualTriageRecord@Context when it names the residual and the first admissible architecture move. It does not measure scale preference, generate candidate architectures, mediate ethical conflict, or select a decision. Apply a subject pattern only when a claim kind being made exists:
D.3 and D.4 boundary. A D.3 use identifies an interlevel ethical conflict-description episteme: it connects each ethical claim to the affected entity, declared level relation or scope, value-frame edition, expected consequence, horizon, and evidence use or uncertainty when current, then states the tension among the sides. A D.4 use takes that description into mediation, refusal, evidence demand, causal return, assurance return, architecture return, accepted residual, or bounded decision use. [C.30.ILC](/generated/patterns/C.30.ILC) handles architecture-specific recognition: whether the conflict or residual is borne by declared holon levels or declared scopes inside a selected structure such as structural views, allocation, interfaces, control rates, work reuse, evidence reuse, scale windows, or coarse-graining loss. It is a triage and architecture-move pattern, not an ethical mediation pattern.
Architecture-move examples.
Worked slice A - clean module layout, bad flow. A product team redraws modules so each component has an explicit responsibility relation or enactor relation, but order-to-cash flow now crosses more work transfers and exceptions rise. [C.30.ILC](/generated/patterns/C.30.ILC) names the module structure, transformation-flow structure, affected work scope, cross-scope residual, and first move: expose hidden coupling or apply C.30.TFS-REL. It does not turn the exception count into a modularity measure until [C.16](/generated/patterns/C.16) or the characteristic pattern governing the characteristic under evaluation is applied.
Worked slice B - AI agent control conflict. A local agent optimizes its local objective and violates a supervisor's allowed-mode constraint. [C.30.ILC](/generated/patterns/C.30.ILC) names the agent scope, supervisor scope or control scope, control relation, local optimization claim, residual-bearing locus, and local repair attempted. The first move may be add control layer, change allocation, or apply [C.30.LCA](/generated/patterns/C.30.LCA). Safety, causality, and gate claims use their subject patterns.
Worked slice C - evidence scope residue. A reusable certification evidence set removes repeated evidence work for several product variants, but one variant has a hidden environment difference. [C.30.ILC](/generated/patterns/C.30.ILC) names the work scope or evidence scope and source-return condition. The practitioner applies [A.10](/generated/patterns/A.10) or [G.6](/generated/patterns/G.6) when an evidence-validity claim is being made.
Worked slice D - frustration residual before synthesis. Several decompositions reduce local module work but each creates a different integration, control-rate, or evidence-reuse residual in another declared scope. [C.30.ILC](/generated/patterns/C.30.ILC) records the residuals and first architecture moves. If the team needs a residual-reducing candidate palette, stop the C.30.ILC use and apply [C.32.MLAO](/generated/patterns/C.32.MLAO) for the residual-reducing frame and [C.32](/generated/patterns/C.32) for the candidate palette. Use [G.5](/generated/patterns/G.5) only when the palette or retained set must become a public selected-set result. If the team claims a multilevel-learning lens or frustration lens, [C.29](/generated/patterns/C.29) carries the lens-use fields and stop condition only after the level mapping, scope mapping, scale-window mapping, or coarse-graining mapping and preserved structure and lost structure are recoverable.
Archetypal Grounding
Bias-Annotation
- Local-success bias. A local improvement is treated as whole-architecture improvement. Repair by naming the wider declared holon level or declared scope and the residual.
- Pseudo-level bias.
Level,layer, orscopesounds precise but no declared holon level or declared scope exists. Repair throughdeclaredHolonLevelRefsordeclaredScopeRefs. - Generic-structure-conflict bias. A conflict between selected structures is treated as interlevel conflict even though no declared holon level, scale window, or coarse-graining relation is recoverable. Repair by keeping the case in
C.30,C.30.ASV, or the subject pattern unless the structures are assigned to different declared holon levels or scale windows. - Frustration-ontology bias. A useful conflict or frustration entry label becomes a new first-order architecture kind, physics ontology, biology ontology, or psychology claim. Repair by recovering declared holon levels or declared scopes, the level-bearing structure, conflict carriers, residual-bearing locus, and the subject pattern for any lens, proof, evidence, mediation, or synthesis claim.
- Global-optimizer bias. Local optimization in one declared holon level or declared scope is used as if the architecture literally optimizes one global function. Repair by keeping the local optimization claim as a triage input unless
C.29supplies an admissible mathematical-lens use with recoverable level mapping or scale mapping and the candidate-set or decision pattern carries any synthesis or selection claim. - Measurement-first bias. A residual is measured before its level-bearing structure and scope grounding are declared. Repair by applying
C.16or the characteristic pattern governing the characteristic under evaluation only after triage names the affected characteristic or measurement relation. - Mediation-default bias. Every conflict is treated as ethical mediation or negotiation. Repair by checking whether the use under repair is architecture structure, allocation, interface grammar, control, work or evidence scope, source-return, or another declared level-bearing architecture relation.
- Synthesis-jump bias. A local residual immediately triggers candidate generation. Repair by identifying the first admissible architecture move before applying
C.32.MLAOandC.32; useG.5only when selected-set result declaration is current.
This checklist verifies the preceding guidance after the practitioner has chosen the selected repair action; it is not a required project control form and not a substitute for the card, note, view, relation, or repair guidance above.
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
The gain is an early architecture move that is small and precise. The practitioner can preserve useful problem language such as conflict, frustration, level, layer, or local optimization while recovering the FPF fields that keep the claim reviewable.
The cost is that C.30.ILC refuses to solve the whole problem. It identifies the first architecture move or subject-pattern application. Measurement, scale relation, RG relation, coarse-graining relation, mathematical lens use, ethical mediation, candidate generation, evidence, assurance, and final choice remain outside until those claims are being made.
This makes multilevel optimization usable rather than decorative. Use C.30.ILC to identify the residual that makes optimization relevant, C.29 for an admissible mathematical-lens use only when level or scale mapping and preserved and lost structure are recoverable, C.32.MLAO and C.32 for residual-reducing candidate frames and palettes, G.5 for selected-set result declaration, and C.32.PAD for a project architecture decision. For publication, use E.17 for a source-backed face and source return and E.24.PUB for the publication occurrence and audience availability.
Rationale
Interlevel conflict and frustration are useful Plain entry labels because they point to a recurrent architecture failure: local repair in one declared holon level or declared scope leaves a residual in another. They are dangerous as generic labels because they can hide which level, scope, level-bearing structure, relation, conflict carrier, or source-return condition bears the residual.
A local optimum or successful local repair is therefore not treated as whole-architecture adequacy. It becomes architecture-relevant only when the residual-bearing locus is recoverable and the next architecture use can be named.
C.30.ILC keeps the entry label but recovers the architecture relation or structure claim. It treats conflict or frustration as architecture-shaping only when declared holon levels or declared scopes, the level-bearing structure, conflict carriers, and residual-bearing loci are named. This lets FPF preserve the practical intuition without introducing a second ontology of levels, a hidden measurement pattern, a physics or biology transfer, a global optimizer proof, or a prescribed architecture work order.
SoTA-Echoing
Relations
- Builds on
C.30andC.30.ASVfor grounded architecture, selected-structure, and structural-view adequacy. - Uses
A.22for structure and structural-view discipline. - Coordinates with
C.30.TFS-REL,C.30.LCA,A.6.F, andA.6.Mwhen the residual concerns flow, control, function, allocation, module, or interface structure. - Applies
C.16or the characteristic pattern that defines or constrains the characteristic under evaluation for measurement or characteristic claims. - Applies
C.29withMLU.Description@MultilevelLearningFrustrationonly when multilevel learning or frustration is used as a mathematical lens with recoverable level mapping or scale mapping and preserved structure and lost structure; appliesC.31.ASAPfor architecture scale-preference claims andC.29for mathematical-lens claims when scale, RG, coarse-graining, preserved structure, lost structure, or scale-window adequacy is being claimed. - Applies
C.32.P2Swhen residual triage must continue through problem-to-structure architecturing; appliesC.32.MLAOfor residual-reducing multilevel candidate frames andC.32for candidate palettes; appliesG.5only when selected-set result declaration is current. - Applies
C.11for final local choice,C.28for causal outcome claims,A.10,B.3, orG.6for evidence or assurance,D.3for the interlevel ethical conflict description, andD.4for mediation and decision use of that description.
For neighboring claims, use C.30 for grounded architecture and selected-structure adequacy, C.30.ASV for structural-view adequacy, A.22 for structure and structural-view discipline, C.30.TFS-REL for an architecture-to-transformation-flow relation, C.30.LCA for a control-structure view relation, A.6.F for function use, A.6.M for a module-interface relation, C.16 or the applicable characteristic pattern for evaluation, C.29 for mathematical-lens use, C.31.ASAP for architecture scale preference, C.32.P2S for problem-to-structure carry-through after residual triage, C.32.MLAO and C.32 for residual-reducing candidate work and candidate palettes, G.5 for selected-set result declaration, C.11 for final local choice, C.28 for causal use, A.10, B.3, or G.6 for evidence or assurance, D.3 for the interlevel ethical conflict description, and D.4 for mediation and decision use of that description. When audience availability is current, use E.17 for a source-backed face and return to source and E.24.PUB for the publication occurrence, form, carrier, audience, bounded use, and availability. Use C.30.ILC only to triage a cross-scope architecture residual.
C.30.ILC:End
C.30.TFS-REL - Architecture Transformation-Flow Structure Relation
Type: Architectural pattern Status: Stable Normativity: Normative unless explicitly marked informative Tech-name:
ArchitectureTransformationFlowStructureRelation(relation record) Plain-name: architecture transformation-flow structure relation Governed object: the bounded architecture-use record connecting an actualArchitectureRelation, exact selected architecture structure, exact structural-view or description episteme, or bounded architecture claim to one selectedTransformationFlowStructureunderE.18or one selectedTransformationFlowStructureNetworkunderE.18.NET; the record does not itself instantiate a direct relation.
C.30.TFS-REL:1 - Problem frame
Use this pattern when an architecture discussion depends on one exact selected TransformationFlowStructure, one selected TransformationFlowStructureNetwork, or a current path, path slice, crossing, flow valuation, edition pin, plane pin, context pin, no-hidden-scalarization claim, or mathematical description of the selected flow structure.
The first useful move is small. ArchitectureTransformationFlowStructureRelation is a bounded architecture-use record connecting one exact architecture locus to the selected E.18 TFS or E.18.NET network used in the question. The locus can be an actual ArchitectureRelation occurrence, exact selected architecture structure, exact architecture-description or structural-view episteme, or bounded architecture claim. When a network is selected, the record also says whether one named containing holon or several explicitly named holons supply the architecture side.
This is a use/trace record, not a universal direct U.Relation declaration and not an obtaining-condition shortcut. Establish each positive architectureRelationOccurrenceRef, flow relation, cross-member relation, correspondence relation, empirical-grounding relation, publication occurrence, or project/work relation under its direct pattern before asserting it. Keep a bounded claim or description separate from an obtaining relation occurrence. groundedNonAdmissibleUse? is an alias for the optional nonAdmissibleUse? value, included only when it passes F.19's plausible-reader test.
Ordinary minimum: name at least one exact architecture-side reference (architectureRelationOccurrenceRefs, selectedArchitectureStructureRefs, architectureStructuralViewRefs, architectureDescriptionRefs, or a bounded architectureClaimRefs entry) and at least one flow-structure reference (transformationFlowStructureRef, transformationFlowStructureNetworkRef, transformationFlowUnfoldingStructureRef, selectedPathOrSliceRefs, crossingBundleRefs, or flowValuationRefs), the admissible use, and one stop or governing-pattern application. A network use also selects exactly one network architecture-use branch and supplies its required exact holon and relation/claim refs. Use remaining fields other than optional nonAdmissibleUse only when they change the next architecture move; otherwise mark them not used. Include that explanatory guard only under the full F.19:4 test. An unused guard may be omitted without an absence entry unless a concrete receiving use needs to distinguish absence from missing information.
Use this record only when an actual architecture relation, selected architecture-relevant structure, exact structural-view episteme, functional-structure view, transformation-flow-structure claim, or conditional architecture-description use depends on an E.18 TFS, an E.18.NET network, or one of the selected TFS's paths, crossings, or valuations. Stop when that architecture-to-flow-structure use and its stop or return condition are clear. If another claim is being made, apply its governing pattern and keep this record to the architecture/flow boundary.
What goes wrong if this pattern is missed: a transformation-flow diagram, graph-shaped mathematical description, path slice, flow valuation, requirement, or functional-view row becomes functional architecture, whole architecture ontology, actual U.Transformation, performed Work, work-result record, evidence, gate passage, or project decision by appearance.
What this buys in practice: the practitioner can use E.18 for one TFS or E.18.NET for one network while C.30 remains the direct architecture-relation and selected-structure adequacy locus and C.30.ASV remains the architecture-structural-view locus.
Not this pattern when the question is only the TFS or network, a mathematical description, path, crossing, or flow valuation and no architecture use is being made. Use E.18 for one TFS, E.18.NET for one network, E.18.2 for its mathematical description, and C.29 when mathematical-lens use is current. Use C.30 for a direct architecture relation or architecture claim without this flow-structure use; use C.30.AD for a durable architecture description and C.30.ASV/A.6.F for a functional view without it. Apply any other claim's governing pattern and keep C.30.TFS-REL only to the architecture/flow relation.
C.30.TFS-REL:2 - Problem
Actual architecture relations, selected architecture-relevant structures, exact architecture structural views, and conditional architecture descriptions often need E.18 TFS objects or one E.18.NET network when they discuss transformation-flow structure, required functional dependencies, actual change, data movement, control paths, evidence-flow descriptions, neural-network dataflow, or code-agent relation graphs.
C.30.TFS-REL prevents collapse by requiring the exact architecture-side reference before any E.18 TFS, E.18.NET network, path, slice, crossing, or valuation receives architecture use. It also keeps required or desired behavior/effect claims distinct from actual A.3.4 transformations. A network additionally needs the named containing-holon or explicit inter-holon branch; its graph, description, publication, or record cannot supply that branch.
C.30.TFS-REL:3 - Forces
C.30.TFS-REL:4 - Solution
C.30.TFS-REL is the C.30 entry record to E.18 and E.18.NET when an actual architecture relation, selected architecture-relevant structure, exact architecture structural view, or conditional architecture description uses one selected TransformationFlowStructure, one selected TransformationFlowStructureNetwork, or a current path, crossing, or flow valuation.
It supplies only the architecture-to-transformation-flow use boundary. Use the full field set shown in section 1; no filled field makes a direct relation obtain.
At least one architecture-side field and at least one E.18 or E.18.NET field must be named by value. Network branch fields obey C.30.TFS-REL:4.4a; other optional trace fields stay not used unless they change inspection, correspondence, hidden relation-structure return, governing-pattern application, or stop. The explanatory nonAdmissibleUse guard follows the full F.19:4 test and needs no absence entry unless a concrete receiving use requires that distinction.
C.30.TFS-REL:4.1 - Use trigger
Use this pattern only when an actual ArchitectureRelation occurrence, selected architecture-relevant structure, exact architecture structural view, functional-structure view, transformation-flow-structure claim, or conditional ArchitectureDescription use depends on one or more E.18 or E.18.NET objects:
TransformationFlowStructureRef;TransformationFlowStructureNetworkRef, when architecture use selects an E.18.NET-conforming network;PathIdorPathSliceId;CrossingBundleRef;- flow valuation over the
U.Transferrelation; - edition, plane, or context pin;
- no-hidden-scalarization or set-return discipline;
- a correspondence claim or independently governed relation between functional structure and transformation-flow structure;
- a generated or extracted relation graph used as candidate input for the architecture-to-transformation-flow use.
If the sentence only says that Work occurred, use A.15 or the governing Work pattern. If it says that an actual referent changed, use A.3.4 before citing a U.Transformation. If it only says that one selected TFS exists, use E.18; if it only says that one independently identified E.18.NET-conforming TFS network is selected, use E.18.NET. If the sentence uses a graph-shaped expression as mathematical description, use E.18.2. If it relies on a mathematical lens, use C.29.
Use transformationFlowUnfoldingStructureRef? only when the architecture use depends on one A.22-selected CGUS qualified under E.18.3. The ref names that selected CGUS; its E.18.3 account separately names one independently identified E.18 substrate branch and the exact positions, bindings, and already-obtaining occurrences the CGUS uses. Architecture, decision, work, feedback, narrative, or refresh values connect only through exact already-obtaining supporting relations, with predicate-definition content and current facts when the claim needs them; the pattern reference adds no connection relation. Generic architecture use of a constraint-governed unfolding structure belongs in C.32.P2S or the direct C.30 architecture governing pattern; this pattern keeps only the architecture-to-transformation-flow trace.
C.30.TFS-REL:4.2 - Relation to functional structure
A FunctionalStructureView under C.30.ASV may cite ArchitectureTransformationFlowStructureRelation when a transformation-flow use is current. That record does not make the selected E.18 structure a functional element or actual transformation, and does not make a functional-element claim identical with the system, module, method, bearer, or flow. It states a bounded claim or trace that exact functional-view content corresponds to, is declared relative to, or positively co-refers with one exact E.18 selected structure, member-local path, crossing, or valuation.
Keep the same three branches used by C.30.ASV:
functionalBehaviorClaimRefsandrequiredOrDesiredEffectClaimRefsremain C.2.1 claim content under their requirement, architecture, capability, method, functional-view, or other direct owner;actualTransformationRefscite only independently identified A.3.4 occurrences with exact changed referent, boundary or extent, boundary conditions, actual before/during/after facts, and continuity or reidentification basis;selectedTransformationFlowStructureRefscite exact E.18 structures, which may organize several independently identified transformations and transfers but are not themselves required effects or actual transformations.
A FunctionalElementClaim is a bounded C.2.1 claim about one exact selected functional structure. Its bearer or candidate-bearer locus, capability, port, allocation, transformation, and correspondence refs retain their direct owners. A graph-shaped expression, path, valuation, required-effect statement, or flow packet is therefore not the functional element by default.
Required-cooling-effect / later-actual-cooling countercase. RequiredCoolingEffect-1 can require exact Rack 7 to be below 30 °C and can correspond to a selected cooling-flow structure before any change occurs. In that first use, fill requiredOrDesiredEffectClaimRefs and the selected TFS fields; leave actualTransformationRefs empty. A later Rack7CoolingTransformation-42 is actual only when A.3.4 fixes Rack 7 as the changed referent, its thermal boundary and operating/ambient conditions, actual 38 °C before facts, actual heat-removal during facts, actual 27 °C after facts, and continuity or reidentification of Rack 7. Even then, a separate satisfaction or realization predicate is needed before claiming that the actual transformation satisfies the earlier requirement.
Use this note when the practitioner needs to see whether the function-to-transformation-flow relation changes inspection, split, relation-making, downgrade, claim-governance assignment named by value, candidate generation, or stop. Use C.30.ASV for the functional structure view, A.6.F for function-like wording recovery, A.3.4 for an actual transformation, A.6.M for module-claim repair and the direct allocation/interface owner, and E.18 for selected transformation-flow structure.
FunctionTransformationFlowRelationNote is the one-TFS form. When architecture use selects a network, use the top-level ArchitectureTransformationFlowStructureRelation and the branch in C.30.TFS-REL:4.4a. Name a member TFS in this note only when the function correspondence is actually to that member; membership in the selected network alone does not create a function correspondence.
When several transformation-flow variants are kept or compared as candidate architecture inputs, keep each selected transformation-flow structure, path, crossing, valuation, graph-shaped expression, or mathematical description under [E.18](/generated/patterns/E.18), [E.18.2](/generated/patterns/E.18.2), and this record. Apply [C.32](/generated/patterns/C.32) only to the architecture candidate palette that uses those selected structures. The graph, path, and flow description does not become architecture adequacy, evidence, assurance, gate passage, selected-set result declaration, publication occurrence, or decision by serving as a candidate input.
C.30.TFS-REL:4.3 - Claim-kind applications named by value
This table is the single boundary for generic non-flow claims. Apply F.19's plausible-reader test before adding a local guard. Relevant candidates include structure-as-architecture, graph-description-as-architecture, flow-as-work-log, crossing-as-gate, valuation-as-score, generated relation-graph proof, and prompt-data-tool flow as authority proof.
C.30.TFS-REL:4.4 - E.18 selected-structure boundary statement
For an E.18-governed selected TransformationFlowStructure used by an actual ArchitectureRelation occurrence, exact selected architecture structure, ArchitectureStructuralView episteme, or conditional ArchitectureDescription episteme, the architecture-use record may cite that exact E.18 structure plus MVPK faces and correspondence claims or independently governed relations.
Grounded architecture adequacy and bounded architecture claims are governed by C.30; description identity by C.30.AD; view conformance by E.17.0 and C.30.ASV. E.18 supplies selected transformation-flow structures and relations; it does not define all architecture structure kinds, create an architecture relation, or turn required flow content into actual change.
This is the named E.18 selected-structure boundary statement for this pattern. It is not a second E.18 source of truth and does not depend on a section number staying stable.
C.30.TFS-REL:4.4a - Architecture use of a transformation-flow structure network
First ask whether one exact named containing holon has an independently obtaining ArchitectureRelation whose exact selected structure is the same transformationFlowStructureNetworkRef. If not, ask whether the architecture question instead spans several exact named holons while no containing holon has been grounded. Select exactly one branch; a connected diagram, network record, list, or common claim label does not answer either question.
- Named containing-holon use. Set
networkArchitectureUseBranch=namedContainingHolon. Name exactly onecontainingHolonRefand one actualcontainingArchitectureRelationRefwhose selected structure is the same exact network.containingArchitectureClaimRefis optional claim/trace content. Keep all participating arrays andnoNetworkBearerHolonAssertedabsent. Member TFS values and their Work, valuations, boundaries, actual transformations, and direct relations remain independently governed. - Explicit inter-holon use. Set
networkArchitectureUseBranch=explicitInterHolon. Put at least two exact distinct holons inparticipatingHolonRefs[]. Add exactly the actualparticipatingArchitectureRelationRefs[]and boundedparticipatingArchitectureClaimRefs[]on which this question relies; a network member whose architecture is not used by the question stays outside those arrays. Keep all containing fields absent and setnoNetworkBearerHolonAsserted=true. This states one architecture-use question spanning named holons; it does not invent a containing holon, architecture relation, or characteristic bearer whose identity is the network.
Every other populated architecture-side reference must agree with the selected branch. In namedContainingHolon, each value in selectedArchitectureStructureRefs belongs to the containing architecture relation's selected structure route, and each structural view, architecture description, functional structure view, or architecture claim used by this record traces to the same exact containing holon and relation. In explicitInterHolon, each such reference traces to one named participating holon and, when actual, its exact architecture relation; a singular reference names only that participant and does not imply a containing architecture. If a reference depends on another holon or architecture relation, add it only when the current question actually relies on it, or use a separate record.
The branches are mutually exclusive. When transformationFlowStructureNetworkRef is absent, networkCrossFlowRelationRowRefs[] and all network branch fields are absent. A network ref without one complete branch is not ready for architecture use. When the record also names a path, slice, crossing, valuation, required effect, or actual transformation, bind it to the exact member TFS and the local positions, participants, or bindings that identify that value. When it names a network-aware unfolding, the E.18.3 substrate branch must name the same exact network and preserve its admitted position mappings, while selectedCGUSRef continues to name the separate A.22-selected CGUS. The network ref does not lift member-local values into network-global state.
Use networkCrossFlowRelationRowRefs[] only for E.18.NET-owned composite locators. Each locator's current containing record must describe the same exact selected network, and the direct occurrence plus complete ordered endpoint-binding identity must resolve exactly one nested row. Zero matches, several matches, or a record for a different network stop this architecture use. The locator identifies the row; it neither creates the relation occurrence nor changes its direct governor.
For every maintainability, capability, responsibility, production, safety, or other architecture-characteristic claim made or used by this record, name the exact holon, actual architecture relation, selected structure, description/view episteme, bounded claim, or other bearer governed by C.30 or the characteristic's direct owner. A network may have selected structural facts—members, relations, recursion, or exposed positions—but those facts do not make an unnamed network the bearer of holon characteristics, agency, Work, production, required effects, or actual transformations.
A network diagram, member graph, mathematical description, publication, or TransformationFlowStructureNetworkRecord is neither branch and does not enter architecture identity. It may represent, describe, or publish the selected network only under its direct representation, description, or publication pattern.
Named containing-holon case. Exact holon ManufacturingPlatform-7 has one obtaining architecture relation whose selected structure includes the product-development/production-system-change network. C.30.TFS-REL may use that network to localize an architecture change while each member TFS, production relation, Work occurrence, and actual transformation keeps its own owner.
Explicit inter-holon case. Exact supplier holon and exact plant holon use one selected E.18.NET-conforming supply-linked TFS network to inspect a cross-company dependency. Both appear in participatingHolonRefs[], with only the actual architecture relations and claims the question uses in their corresponding arrays. No containing supply-chain holon has been grounded, so noNetworkBearerHolonAsserted=true. The network is not called the architecture of an unnamed enterprise.
C.30.TFS-REL:4.5 - Worked slices
Functional architecture with a transformation-flow relation being claimed. A team says, "The functional architecture is this flow diagram." The repair is:
Filled use record:
Cooling countercase: a selected cooling-flow TFS and RequiredCoolingEffect-1 may fill the required-effect and correspondence fields while actualTransformationRefs stays empty. Only a later A.3.4 occurrence with Rack 7 as exact changed referent, fixed thermal boundary and conditions, actual 38 °C before / heat-removal during / 27 °C after facts, and Rack 7 continuity can fill that field. A separate realization predicate is still needed to relate the actual cooling to the requirement.
Near miss: if the selected transformation-flow structure has no exact C.30-side architecture reference named by value, the case stays in [E.18](/generated/patterns/E.18). If the same sentence is a mathematical description, use [E.18.2](/generated/patterns/E.18.2); if it is a math-lens-use claim, use [C.29](/generated/patterns/C.29). If it is a Work log, evidence claim, gate decision, or benchmark result, that non-flow claim is governed by its governing pattern and this record keeps only the architecture-to-transformation-flow use.
Pump-station flow relation. A plant team says, "the safety architecture is the bypass flow." C.30.TFS-REL applies only if the exact plant holon, its actual architecture relation or bounded architecture claim as current, selected control or material-flow structure, and E.18 selected bypass-flow structure are named. The bypass path may be architecture-relevant, but it is not an actual cooling/pumping transformation, safety proof, performed maintenance Work, gate passage, or release permission. The record names the plant architecture locus, selected E.18 path or crossing, hidden relation-structure return condition, and the one architecture move changed by the bypass relation.
Supply-chain transformation-flow relation. A logistics architecture view may use an E.18 selected flow structure for supplier handoff, transport crossing, freshness window, and valuation. The exact subject holons, actual architecture relations when claimed, and selected supply-chain structures remain named; Work occurrences, contractual commitments, evidence, and gate decisions stay with their governing patterns.
Neural-network dataflow change. Source labels such as attention block, SSM block, convolution block, memory mechanism, cache mechanism, and MoE expert-selection go through [C.30.STRAT](/generated/patterns/C.30.STRAT) unless the changed value is already recovered. C.30.TFS-REL applies only when the exact changed structure kind and transformation-flow relation are named. A benchmark, ablation, or pruning result may bear on a non-architecture claim named by value, but it does not make the flow relation an architecture decision, actual transformation, or evidence sufficiency by itself.
Code-agent relation graph. A code-agent relation graph with IMPORTS, CALLS_API, REGISTRY_WIRES, or DATA_FLOWS_TO edges can be used for an architecture-to-transformation-flow relation only with the source publication or codebase edition, extraction or probe locus, relation observation class selected from {observed, inferred, unknown}, typed relation semantics, unexplored regions, and hidden relation-structure return condition when subsequent action relies on hidden distinctions. The graph, representation, file, and publication occurrence remain distinct from both the selected TFS and every direct relation occurrence.
C.30.TFS-REL:4.6 - Lowering and currentness conditions
Lower, narrow, or reopen the relation at the smallest changed locus when:
- E.18 one-TFS structure, path, crossing, or flow-valuation semantics change;
- E.18.NET network identity, direct membership, exposed positions, exact cross-member relations, or nested-row locator resolution changes;
- the selected network architecture branch or any containing or participating architecture claim used by that branch changes;
- edition, plane, context pin, set-return, or no-hidden-scalarization discipline changes;
- source publication or graph edition, path slice, relation observation class, edition or context pin, unexplored region, or hidden relation-structure return condition changes;
- the C.30 architecture locus, selected architecture-relevant structure, architecture structural view, conditional architecture description, or C.30.ASV relation changes;
- functional-to-transformation-flow correspondence changes;
- a non-flow claim is being made and is governed by
C.30.TFS-REL:4.3rather than by this relation; - C.29, C.16, C.28, A.10, G.6, B.3, A.20, A.21, A.15, C.30, C.30.ASV, A.6.F, C.30.STRAT, E.18, or E.18.NET changes the governing boundary used by the relation.
Admissible repair results are: update the affected TFS or network reference, network branch, or row locator; add or change correspondence or the hidden relation-structure return condition; narrow admissible use; keep the one-TFS claim inside E.18 and the network claim inside E.18.NET; keep the mathematical-description claim inside E.18.2; keep the math-lens-use claim inside C.29; apply the governing pattern to a non-flow claim; lower to quote-only or reduced-use cue; or block the architecture-to-transformation-flow use.
C.30.TFS-REL:5 - Archetypal Grounding
C.30.TFS-REL:6 - Bias-Annotation
Lenses tested: Arch, Onto, Epist, Prag, Did, Gov. Scope: architecture-to-transformation-flow uses of E.18 TFS or E.18.NET network objects.
This checklist verifies the preceding guidance after the practitioner has chosen the selected repair action; it is not a required project control form and not a substitute for the card, note, use record, direct relations, or repair guidance above.
C.30.TFS-REL:7 - Conformance Checklist
C.30.TFS-REL:8 - Common Anti-Patterns and How to Avoid Them
C.30.TFS-REL:9 - Consequences
C.30.TFS-REL:10 - Rationale
E.18 governs one selected TFS, its paths, crossings, valuations, and pins; E.18.NET governs one selected network and its exact cross-member relations. Architecture needs to use either object without taking over its ontology or inventing an unnamed architecture bearer. The smallest stable result is therefore one C.30-side use record pointing to exact objects and stating the named-containing-holon or explicit inter-holon branch when a network is selected.
This pattern also protects functional architecture and actual-change semantics. A functional structure may correspond to a transformation-flow structure, and in some cases both views may designate the same selected U.Structure; that identity is not automatic. Required or desired effect remains claim content, while an actual U.Transformation requires the independent A.3.4 basis.
C.30.TFS-REL:11 - SoTA-Echoing
Currentness boundary. Inputs are E.18 TFS semantics and pins; E.18.NET network identity, cross-member relations, and row-locator resolution when selected; the chosen network architecture branch and exact containing or participating holons/relations/claims; C.30/C.30.AD/C.30.ASV architecture-side rules; observation class; required-versus-actual status; and non-flow governors named in C.30.TFS-REL:4.3. When one changes, the record changes only at the affected reference, branch, row locator, correspondence, hidden relation-structure return condition, admissible-use boundary, or governing-pattern assignment.
C.30.TFS-REL:12 - Relations
Builds on: C.30, C.30.AD, C.30.ASV, A.22, A.6.F, A.3.4, E.18 for one TFS, E.18.NET for one selected conforming network and exact obtaining cross-member relations, E.17.0, E.24.PUB, A.7, E.10, C.2.P, and F.18.
Coordinates with: C.30.STRAT, C.32.P2S when architecture-to-transformation-flow grounding is one stage of problem-to-structure architecturing, C.32 when selected transformation-flow variants become candidate architecture inputs, C.33 when transformation-flow relation descriptions capture or lose selected architecture structure, C.34 when transformation-flow claims must be preserved across a mapping, model, generated output, or realization, C.35 when a generated or discovered carrier may seed synthesis, A.15, A.20, A.21, A.10, G.6, B.3, C.28, C.29, C.16, admitted measurement, selection, or candidate-set governors, A.6.M module-claim repair and direct interface owner, A.6.5 slot discipline, and A.6.0 when a signature declaration is being made.
Related claims stay with their governing patterns: C.30.STRAT for stratification wording and source-label repair; E.18 for one selected TFS, path, crossing, and flow valuation; E.18.NET for network identity and exact cross-member relations; E.18.2/C.29 for mathematical descriptions, representations, and lens use; C.30 for direct architecture relations and selected-structure adequacy; C.30.AD for description identity/use; E.17.0/C.30.ASV for structural-view conformance and adequacy; A.3.4 for actual transformations; C.32.P2S for connected problem-to-structure carry-through; A.6.F for function-use repair; and the non-flow governors named in section 4.3. C.30.TFS-REL governs only the bounded architecture use of the selected TFS or TFS network.
C.30.TFS-REL:End
Modularity and Reusable Structure Characteristics
Type: Characterization pattern Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when modularity or reusable-structure language is doing work in an architecture discussion and the practitioner needs to know which few characteristics matter, what repair follows, and whether any measurement or comparison is admissible.
The first useful move is deliberately small:
Start with recognition, at most three characteristics under evaluation, the observed problem, and a repair direction. A report-only proxy is an admissible stop when no beyond-local-repair use is being made.
Claim-use boundary: comparison, publication, evidence, assurance, gate, decision, benchmark, causal-use, cross-case reuse, selection, procurement, and architecture scale-preference are beyond-local-repair uses in C.31. Add their fields only when that use is being made and recoverable by value and the subject pattern can be named.
What goes wrong if C.31 is missed: "modular" becomes a binary label; a single modularity score hides incompatible characteristics; interface publication is confused with substitutability; internal cohesion is improved while evidence reuse gets worse; bespoke residue moves from templates into work or assurance; and complexity language becomes a commensurable score without a declared characteristic, scale, measurement basis, comparison basis, or admissible-use boundary.
What C.31 buys in practice: the practitioner can see which modularity characteristic changes the next architecture use, which false use is blocked, which repair is plausible, and which exact subject assertion and defining or constraining ClaimGraph are needed for measurement, evidence, causal, scale, selection, or accounting claims.
Not this pattern when the question under repair is only source-label recovery, module-interface relation repair, reusable-structure accounting, general measurement admissibility, quality-family claim, architecture scale-preference claim, mathematical-lens use, candidate architecture synthesis, or selection. Use [C.30.STRAT](/generated/patterns/C.30.STRAT), [A.6.M](/generated/patterns/A.6.M), [C.31.RSA](/generated/patterns/C.31.RSA), [C.16](/generated/patterns/C.16), [C.25](/generated/patterns/C.25), [C.31.ASAP](/generated/patterns/C.31.ASAP), [C.29](/generated/patterns/C.29), [G.5](/generated/patterns/G.5), or [C.11](/generated/patterns/C.11) as appropriate; do not treat C.31 as the synthesis or selector pattern.
Problem
Architecture work often asks for more modularity, better reuse, lower coupling, more explicit interfaces, cleaner allocation, or less bespoke residue. These phrases point to real engineering work, but they do not name one scalar property.
Modularity can improve along one characteristic while worsening another. A design can reduce external coupling and increase interface alphabet size. A platform can standardize interfaces and create unhelpful rigidity. Evidence reuse can improve while functional-to-module allocation remains tangled. A report can show a high reuse share while hiding source-return work or residual uncertainty.
C.31 turns modularity talk into a small characteristic vector plus repair direction. It does not promise that every characteristic is measurable now, comparable across cases, causal, admissible for decision use, or evidence-backed.
Forces
Solution
C.31 defines and constrains modularity and reusable-structure characteristic assertions as C.16-compatible characteristic heads, composite descriptions, lens-backed characteristic interpretations, temporal or scale-sensitive characteristic interpretations, causal-use-sensitive characteristic interpretations, or report-only proxies. It starts from action guidance and adds fields for beyond-local-repair use only when a use being made requires them.
Ordinary output: ModularityVectorLite
ModularityVectorLite is the ordinary output. It names at most three characteristics under evaluation because the first task is to find the next repair, not to audit all possible modularity interpretations.
The vector is complete enough when it states what can be done next and what cannot be inferred. relatedClaimPatternLocatorsIfClaimed is a non-semantic locator field: if a characteristic is used beyond local repair, the exact subject assertion and its defining or constraining ClaimGraph remain separately required. Architecture scale-preference claims use the predicate defined in [C.31.ASAP](/generated/patterns/C.31.ASAP).
Filled ModularityVectorLite
Near miss: a high interface-standardization count alone is not a C.31 improvement. If field-service work, source-return events, or variant-specific evidence increase, the vector records that proxy divergence and returns to repair rather than treating the count as architecture quality.
Characteristic classes
Every C.31 head is classified before use:
In C.31, declared basis and comparability basis name C.16-compatible measurement or comparison fields. They are not generic reason words and are not substitutes for evidence, assurance, cause, source, decision, or architecture-description relations.
Measurement-head mapping
When a head becomes decision-facing or publication-facing, create MeasurementHeadMapping before relying on it:
This mapping is not a measurement template by itself. It prepares a C.16-compatible characteristic card or a report-only boundary. When the head is decision-facing or publication-facing, the mapping names required evidence plus at least one evidence relation, evidence-provenance relation, or source relation. If no evidence claim is being made, evidenceClaimAbsentBecause states why the head remains local, report-only, or repair-only.
C.31 characteristic card
Use the full card only when the use goes beyond local repair:
Each card states its own C.16 well-formedness fields: characteristic, scale, unit or unitless interpretation, declared measurement basis, comparability basis, evidence relation, evidence-provenance relation, source relation, or evidence-claim-absent reason, non-admissible use, and repair action. When source material is used as evidence, the source relation is named. A source checklist, source-discharge slice, dashboard label, or inherited score is not enough.
Seed characteristic heads and repair actions
These heads are seeds, not an exhaustive taxonomy. Use only the heads that change the next action.
Claim-scoped residual heads
C.31 uses residual heads only as qualitative repair cues. These heads do not create one complexity characteristic.
Proxy-risk discipline
Every decision-facing C.31 card includes ProxyRisk and AuditQuestion. If the proxy diverges from the value it was meant to represent, the card stops at report-only use or returns to repair.
Rejected shortcut
The expression ModularityScore = average(all measures) is not admissible as a C.31 result. A local score is admissible only when the scoring method, codomain, polarity, characteristic basis, comparability basis, and use boundary are disclosed through the governing scoring or comparator pattern. Without that, keep the result as report-only or return to ModularityVectorLite.
Lowering and currentness conditions
Lower or reopen a ModularityVectorLite, ModularityCharacteristicCard, or report-only proxy when any of these conditions changes the characteristic use:
- proxy audit worsens, such as more integration failures, workarounds, source-return events, stale evidence reuse, or bounded exceptions;
- measurement basis, comparability basis, scoring method, codomain, polarity, unit policy, or declared characteristic basis changes;
- evidence relation, evidence-provenance relation, source relation, evidence-claim-absent reason, or source-return condition changes;
- described holon, architecture question or intended use, ClaimScope or qualification window, architecture claim, structure kind, characteristic head, or repair direction changes;
- a report-only proxy is used for comparison, selection, publication, assurance, benchmark, causal-use, cross-case reuse, decision, procurement, or architecture scale-preference;
C.31.RSA,C.31.ASAP,C.16,C.25,C.29,C.30.STRAT,A.6.M,C.30,C.30.ASV,A.10,B.3,A.20,A.21,G.5, orC.11changes the boundary for the neighboring claim being made.
Admissible repair results are: keep the result report-only, split or rename the characteristic head, update basis or evidence fields, revise the repair direction, change relatedClaimPatternLocatorsIfClaimed, lower a score to a local proxy, or stop C.31 use for the beyond-local-repair claim and constitute the exact subject assertion under its predicate.
Archetypal Grounding
Tell. Modularity is a vector of action-guiding characteristics, not a magic scalar. A good C.31 interpretation says what to repair next.
Show. A product architecture can have high interface standardization and still poor substitutability. A software-system architecture can reduce external coupling while increasing hidden data custody. A safety-case architecture can reuse evidence while increasing regulatory bespoke residue. Each case needs a different characteristic and a different repair.
Show. A DSM or dependency graph can substantiate a modularity interpretation, but the graph does not by itself say which dependency kind matters, what scale applies, whether the interpretation is comparable, or what action follows.
Holon and episteme: architecture and modules are selected structures of described holons for named architecture questions and uses; the described holon may be an admitted system, organization-as-system, episteme, work occurrence, discipline, or another admitted holon kind. Publication-family material uses the episteme and publication patterns. A MethodDescription is an episteme; a Method uses A.3.1, and any relation asserted for it uses the pattern that defines that relation. C.31 heads, cards, vectors, and report-only proxies are characteristic records, declared-measurement-basis records, comparability-basis records, or report-only records about those structures.
Bias-Annotation
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
Benefits:
- Modularity becomes action-guiding without becoming one fake score.
- Cheap repair remains possible before measurement.
- Characteristic, declared-measurement-basis, comparability-basis, proxy-risk, and subject-pattern boundaries are visible.
- DSM, MOSA, platform, product-line, and architecture-operation sources can inform practice without importing their ontology wholesale.
Costs:
- Familiar score language often has to be downgraded to report-only use.
- Cross-case comparison requires additional C.16, C.25, G.2, comparator, evidence, or decision claim.
- Some attractive "complexity" statements are assigned to characteristic named by value, lens, or residual cue rather than becoming a general complexity pattern here.
Rationale
C.31 is a characterization pattern because modularity and reusable-structure talk changes engineering action through characteristics: coupling, cohesion, interface variation, substitutability, reuse, evidence reuse, hidden coupling, source-return cost, and residual growth. Those heads are useful only when their subject, scale, declared measurement or comparison basis, false use, and repair action is visible.
The pattern puts ModularityVectorLite first to preserve affordability. Many practitioners need to see one relation to repair, one interface grammar to tighten, or one residue to account for. Requiring the full measurement apparatus too early would turn C.31 into a control form and would violate the architecture source invariant: repair succeeds only when one useful admissible action remains.
The pattern rejects a single complexity or modularity score because selected heads are not automatically commensurable. When a local score is genuinely useful, it belongs under disclosed scoring, comparator, characteristic, declared-measurement-basis, and subject-pattern discipline.
SoTA-Echoing
Source-currentness front. Use the table's Currentness or lineage use cell as the source-use boundary. A lineage row can explain why a characteristic family matters, but it cannot establish current comparison, procurement, assurance, benchmark, decision, publication, or other beyond-local-repair use without a current source relation under G.2 and the exact subject assertion for that use. Refresh the source use when MOSA or acquisition guidance changes, platform or product-line practice changes, DSM or modularity-index practice changes, queueing or coordination-overhead assumptions change, proxy-pressure law is used for a new claimed value relation, or architecture-operation language is used as current practice rather than as source-side recognition language. When refresh changes the source-use relation, update the affected characteristic head, proxy-risk field, audit question, related claim locator and assertion, or report-only boundary rather than treating the older source as current by default.
Rows named current, such as MOSA guidance, current platform practice, current scalable-workload extensions, or current architecture-operation corpus material, require source refresh before beyond-local-repair use when the named practice changes. Rows named lineage stay lineage unless a current source relation is explicitly recovered.
Older or local sources may serve as lineage or worked examples only when the row says so. They do not stand in for current competitive source, and they do not make a modularity value admissible for beyond-local-repair use without the subject pattern for that use.
Relations
C.31:End
Reusable Structure Accounting
Type: Characterization pattern Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when a practitioner needs to locate where reusable structure lives, where bespoke residue grows, which accounting basis is being used, what can be refactored, and what remains a bounded exception or source-return condition. A report-only share stays report-only unless the relevant outside-RSA use is governed by its governing pattern.
Claim-use boundary: any use that relies on the RSA account to make a stronger claim is outside RSA. Examples include comparison, publication, evidence validity, assurance or safety-case reliance, gate use, architecture scale preference, causal use, selected-set result declaration, candidate synthesis, and local decision. Record with C.31.RSA only the reusable locus, bespoke residue, accounting basis, report-only share, repair direction, and source-return condition. Add another claim only after naming and applying the pattern that defines and tests it.
The first useful move is ReusableStructureTriage:
Use the fuller accounting description only when an accounting basis and structure references are declared. Ordinary use stops when the practitioner knows where reusable structure lives, where bespoke residue grows, what can be refactored, and what remains a bounded exception.
What goes wrong if C.31.RSA is missed: a reusable share is treated as a proof of modularity; one-off work is hidden under a reuse label; evidence reuse is counted without validity context; hidden residual uncertainty is averaged with reusable templates; and "more reusable structure" is treated as always better.
What C.31.RSA buys in practice: the practitioner can state where structure is reusable, where it is bespoke, what source-side distinctions must remain reachable, and when the result is only report-only accounting.
Not this pattern when the question under repair is source-label recovery, module-interface relation repair, modularity-characteristic selection, measurement or comparability admissibility, architecture scale preference, mathematical-lens use, or any outside-RSA use named above. Use [C.30.STRAT](/generated/patterns/C.30.STRAT), [A.6.M](/generated/patterns/A.6.M), [C.31](/generated/patterns/C.31), [C.16](/generated/patterns/C.16), [A.10](/generated/patterns/A.10), [B.3](/generated/patterns/B.3), [G.6](/generated/patterns/G.6), [C.31.ASAP](/generated/patterns/C.31.ASAP), [C.29](/generated/patterns/C.29), [G.5](/generated/patterns/G.5), or [C.11](/generated/patterns/C.11) as appropriate; do not treat C.31.RSA as the synthesis or selector pattern.
Problem
Architecture teams often say that structure is reusable, repeated, templated, common, standardized, or bespoke. Those phrases are useful, but they do not say what is being counted, described, or compared. Structure can be selected from functions, flows, control relations, module interfaces, work methods, evidence packages, regulatory arguments, data schemas, deployment constraints, or exception networks.
Functional, flow, control, module-interface, work, evidence, and assurance structures may be included only when their declared accountingBasisRef and evidence relation named by value, assurance relation, source relation, or source-return condition are declared when those relations are being claimed.
The practical question is: which reusable loci matter, which bespoke residue remains, what source distinctions are lost by accounting, and what repair or source return follows?
Forces
Solution
C.31.RSA governs reusable-structure accounting as a typed description over declared structures and structural aspects. It starts with ReusableStructureTriage; it uses ReusableStructureAccountingDescription@Context only when the accounting basis is declared.
Typed accounting description
accountingBasisRef states the accounting rule being used: description length, dependency edges, work items, evidence package count, cost share, template instances, interface variants, regulatory case sections, or another declared accounting rule. The accounting rule is not implied by the word "reuse".
Well-formedness: every slot is over declared structureRefs, declared structuralAspectRefs, and one declared accounting basis. Slot labels are explanatory; they are not root kinds and are not automatically commensurable.
Explanatory slot labels
A local accounting description may use explanatory slot labels such as:
These labels are local slots, not FPF ontology. H_residual is residual uncertainty or unmodelled variance under the accounting basis. It is not obviously the same unit as interface grammar, work template, evidence package, or regulatory argument.
Report-only shares
Numeric shares require a declared accountingBasisRef, declared scale or unitless-value rule, unit when relevant, polarity when relevant, admissible comparability relation, and comparator admission named by value such as CG-Spec, ComparatorSetRef, or a comparator-governing reference named by value before they can guide outside-RSA use such as comparison, ranking, selection, gate use, or decision use. Without that, the share remains local report-only guidance.
Pseudo-sum boundary
An explanatory decomposition may be useful:
This is not ReusableStructureEquation, not an architecture amount, and not a hidden StructureAmount kind. It is a readable decomposition of one declared accounting description. If the slots do not share a declared accounting basis and comparability rule, they cannot be summed or ranked.
Structure-relocation actions
RSA is useful because it points to relocation and repair actions:
High reusable structure is not always good. The architecture question is where structure lives and what action follows: reusable templates, interfaces, flows, control relations, work methods, evidence packages, or unique exception networks and hidden coupling.
After a relocation or reuse move, ask what got worse:
The result is not "more reuse is better." A conforming RSA move states the reusable locus, the bespoke or residual locus, the accounting basis, the first repair direction, and the first cost, loss, or source-return condition that can make the move inadmissible.
Triage and accounting use boundary
Use only ReusableStructureTriage when:
- there is one local case;
- no outside-RSA use is being made;
- the practitioner only needs a repair direction;
- no numeric share is being relied on.
Use ReusableStructureAccountingDescription@Context when:
- the accounting basis is declared;
- a report-only share is useful;
- structure refs or structural aspects need to be compared inside one declared
accountingBasisRef; - source-return conditions matter;
- reusable structure or bespoke residue is used for outside-RSA use such as cross-case report, publication, assurance, architecture scale preference, or decision.
Reopen and lowering conditions
An RSA result remains valid only inside its declared accounting basis, structure edition, source-return condition, and comparator admission. Reopen the triage or lower the admissible use when any of the following changes:
- a hidden source distinction becomes action-relevant;
- the accounting basis changes or proves heterogeneous;
- the selected structure, structural aspect, interface grammar, evidence package, work method, or assurance argument changes edition;
- a comparator set, CG-Spec, or outside-RSA use is added after a report-only share was recorded;
- downstream reliance uses the RSA result for outside-RSA evidence, assurance, gate, causal-use, scale-preference, or decision work that the RSA note did not admit;
- evidence validity, assurance window, or source-return condition decays;
- a local bounded exception becomes repeated enough to require refactoring;
- a reuse move improves one locus while worsening interface cost, variation loss, evidence decay, assurance work, source-return cost, or hidden bespoke residue.
Lower the result to report-only when outside-RSA comparison, ranking, selection, gate use, or decision use lacks comparator admission named by value. Lower it to quote-only or source cue when the accounting basis cannot be recovered. Mark it blocked when the reusable locus and bespoke-residue locus cannot be separated.
Archetypal Grounding
Tell. Reusable structure is not a substance. It is structure located in declared places under a declared accounting basis.
Show. In one architecture, reusable structure may be located in a template and interface grammar. In another, it may be located in a test package, regulatory argument, work method, or flow pattern. In a third, the reusable part may be small, but the bounded exception is exactly what preserves safety or local fit.
Show. A share can be useful as a local report. It becomes misleading when it hides which structure was counted, which structure was not counted, and when the reader must return to source records.
Holon and episteme: the structures being accounted over are selected architecture-relevant structures in context. The RSA description, slots, report-only shares, and source-return condition are accounting descriptions, slot-bearing records, report-only records, and source-return records about those structures.
Worked case: reusable evidence package, bespoke delivery work
Situation:
ReusableStructureTriage:
Admissible move: publish the local report-only RSA note and repair the recurring delivery approval work into reusable work structure and reusable evidence structure. Non-admissible move: claim that the reusable evidence package proves every deployment or that a high reusable share makes the architecture better.
Anti-case: high share hides a bad architecture move
Situation:
This is not a successful RSA result. The accounting basis counts template instances but hides interface relation cost, lost variation, hidden bespoke work, and evidence decay. The repair is to mark the share as report-only, add the missing bespoke-residue slots, and apply A.6.M, C.31, or an characteristic pattern governing the claim to the interface relation cost before any comparison or decision use.
Lowering replay: the team tries to use the 85 percent share to rank this template architecture above another product-line variant and approve the template program. The use is lowered to local report-only accounting because the comparator set, accounting-basis alignment, interface-cost measure, source-return condition, and decision record are absent. Before comparison or decision use, A.6.M must repair the interface grammar, C.16 or A.19 must govern comparability and characteristic space, and C.11 must govern the local decision claim.
Stop condition: do not use the 85 percent share for outside-RSA ranking, gate, assurance, or decision. Reopen the RSA note when the interface grammar, exception register, or comparator set changes.
Transfer case: neural-network block replacement
Situation:
RSA can transfer from product-line architecture to neural-network architecture only after [C.30.STRAT](/generated/patterns/C.30.STRAT) has treated block, cache, and related terms as source labels unless the reusable locus is already recovered. Then RSA names the declared structures and accounting basis:
- reusable structure may be located in recovered repeated-block topology, dataflow pattern, cache-placement rule, or evaluation harness;
- bespoke residue may be located in model-specific tuning, data distribution dependence, memory-layout exception, or ablation gap;
- benchmark gain is not reusable-structure accounting by itself;
- evidence claims apply
[A.10](/generated/patterns/A.10)and[G.6](/generated/patterns/G.6); causal claims apply[C.28](/generated/patterns/C.28); mathematical-lens or compression claims apply[C.29](/generated/patterns/C.29).
Admissible move: record which recovered structural locus was reused, what changed, what source distinctions must remain reachable, and which governing pattern governs benchmark, evidence, causal-use, or mathematical-lens claims. Non-admissible move: treat "block replacement improved the architecture" as RSA proof.
Bias-Annotation
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
Benefits:
- Reusable structure and bespoke residue become visible without a false architecture amount.
- Practitioners get a cheap triage before accounting.
- Report-only shares can guide repair without becoming proof.
- Evidence reuse, work repeatability, interface grammar, and bounded exceptions can be separated instead of averaged.
Costs:
- Some attractive reuse reports remain report-only.
- Numeric shares require declared
accountingBasisRef, declared scale or unitless-value rule, relevant unit and polarity, admissible comparability relation, and comparator admission named by value before they can guide outside-RSA comparison, ranking, selection, gate, or decision use. - The pattern raises a source-return question whenever accounting hides distinctions needed by downstream action.
Rationale
C.31.RSA is separate from C.31 because accounting over reusable structure has a different reusable-structure accounting question from choosing modularity characteristics. C.31 asks which characteristic changes action. C.31.RSA asks where reusable structure and bespoke residue are located under a declared accounting basis.
The pattern refuses StructureAmount because architecture is selected structure in context, not a substance. A useful accounting description can still report shares, but only under declared structure refs, structural aspects, and an accounting basis.
The pattern also keeps residue ethically and practically neutral until interpreted. Bespoke residue can be a defect, a local necessity, a safety boundary, a regulatory constraint, or a deliberately accepted exception. The repair is to name which one.
SoTA-Echoing
Source-currentness front. Use the table's Currentness or lineage use cell as the source-use boundary. Rows named current, such as ISO/IEC/IEEE 42010:2022, MOSA guidance, current product-line or variability work, GSN Community Standard v3, current safety-case reuse work, and the architecture-operation corpus material used as current practitioner language, require source refresh before outside-RSA use when the named standard, guide, practice family, or corpus use changes. Rows named lineage, such as DSM or product-architecture lineage, Eppinger and Browning lineage, Goodhart and Campbell proxy-pressure lineage, system-evolution and information-hiding lineage, and Pohl, Boeckle, and van der Linden lineage, stay lineage unless a current source relation is explicitly recovered.
Refresh or lower the RSA result when a source-use change alters the reusable locus, bespoke-residue locus, accounting basis, source-return condition, comparator admission, evidence-validity relation, assurance or safety-case reliance, architecture scale-preference relation, or any outside-RSA use. A source row may explain why an accounting distinction matters, but it does not make an RSA share current for comparison, decision, assurance, gate, or publication without the applicable pattern for that outside-RSA use.
Older or local sources may serve as lineage or worked examples only when the row says so. They do not stand in for current competitive source, and they do not make an RSA share admissible for outside-RSA use without the governing pattern for that use.
Relations
C.31.RSA:End
Architecture Scale-Amenability Preference
Type: Characterization pattern Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when a practitioner compares architecture alternatives under a declared scale variable or scale window and needs to avoid treating a modularity label, platform label, product-line label, reusable-structure share, or coarse-graining metaphor as an automatic scale-preference claim.
The first useful move is ScaleClaimTriage:
Ordinary use starts by naming the alternatives and described holon, the exact U.ClaimScope and relevant A.2.6 U.ContextSlice membership, the scale variable and scale window, the claimed preference under scale, the available slope or scale-probe evidence or no-probe reason, the expected stable or improving structure, and the exception-growth risk. Name modelUseStructureRef only when one independently selected BoundedModelUseStructure changes this receiving interpretation; it never replaces the claim scope. Use ArchitectureScaleAuditRecord@Project only when the scale preference is being used to affect a comparison, selected set, publication, assurance input, or architecture decision.
What goes wrong if C.31.ASAP is missed: "modular", "platform", "product line", "reusable", "general", "open", "coarse-grained", or "RG-like" becomes a shortcut for a scale-preference claim; a locally hand-engineered solution is called debt even when safety, law-domain, or mission constraints justify it; exception growth is hidden until the architecture is already expensive to change; and coarse descriptions keep losing lower-scope safety or semantic distinctions without a source-return condition.
What C.31.ASAP buys in practice: the practitioner can say what is being scaled, where the scale claim holds, what structure is expected to remain stable or improve, what exceptions are allowed, what evidence or no-probe reason exists, which scale-preference claim stays in C.31.ASAP, and which governing pattern governs any lens-use, evidence, assurance, selection, or decision claim being made.
Not this pattern when the question under repair is only module-interface relation repair, modularity-characteristic selection, reusable-structure accounting, mathematical-lens use, scale-law adequacy, method preference under general BLP, candidate architecture generation, selected-set return, or final local choice. Use [A.6.M](/generated/patterns/A.6.M), [C.31](/generated/patterns/C.31), [C.31.RSA](/generated/patterns/C.31.RSA), [C.29](/generated/patterns/C.29), [C.18.1](/generated/patterns/C.18.1), [C.19.1](/generated/patterns/C.19.1), [C.32](/generated/patterns/C.32), [G.5](/generated/patterns/G.5), [G.9](/generated/patterns/G.9), or [C.11](/generated/patterns/C.11) as appropriate. C.31.ASAP governs architecture scale-preference claims; it does not select the architecture, prove the scale law, or certify the project.
Problem
Architecture work often asks whether one structure will scale better than another: a product-line architecture rather than bespoke variants, an open interface rather than a closed integration, a stable flow topology rather than repeated project exceptions, or a reusable evidence package rather than repeated assurance work.
These claims are useful only after the scale relation is declared. "Scales better" can mean fewer interface grammar variants, lower exception growth, better learning transfer, more reusable templates, more stable control relations, less source-return cost, fewer regulatory exceptions, or more freedom of action. Those are not the same claim.
C.31.ASAP turns architecture scale-preference talk into a declared scale variable or window, a preference claim, evidence or no-probe reason, expected stable or improving structure, exception-growth risk, and source-return condition. It does not turn scale preference into proof, selection, assurance, causal use, or a universal law.
Forces
Solution
C.31.ASAP specializes scale-amenability preference for architecture alternatives. It applies when an architecture alternative set, scale variable or scale window, and claimed preference under scale are named.
Applicability fields
C.31.ASAP applies only when all of the following are present:
- a declared architecture alternative set, described holon, exact
U.ClaimScope, and relevant A.2.6U.ContextSlicemembership; - a declared scale variable or scale window;
- a claimed preference under scale;
- slope evidence, scale-probe evidence, or a no-probe reason;
- an expected stable or improving structure, exception-growth risk, or source-return condition that changes the next architecture move.
If those fields are absent, keep the claim in C.31 as a temporal or scale-sensitive characteristic cue, in C.31.RSA as report-only accounting, in C.29 as a bounded lens-use output, or in ordinary architecture prose.
ScaleClaimTriage
Use ScaleClaimTriage before any heavier scale audit:
The triage is complete enough when it states the next admissible architecture move and the stop or return condition. Include nonAdmissibleUse? only when it passes F.19's plausible-reader test; groundedScaleShortcut? is an alias for that same optional value. It may stop at local guidance when no comparison, publication, assurance, selected-set, or decision use is being made.
claimScopeRef designates one exact U.ClaimScope; selectedContextSliceRefs records the A.2.6 membership relevant to this use. A scale window is the range of the scale variable for which the preference is claimed, not a substitute for either scope object. modelUseStructureRef is optional and is filled only when an independently selected A.1.1 BoundedModelUseStructure changes the interpretation of this exact preference use.
Architecture scale-preference rule
When architecture alternatives satisfy the same safety boundary, law-domain boundary, and assurance boundary, prefer the alternative whose reusable functional-structure, flow-structure, control-structure, module-interface, work-template, and evidence-package structure and learning-transfer slopes remain stable or improve over the declared scale window, unless an ArchitectureScaleAuditRecord@Project records a bounded exception.
C.31.ASAP defines the scale-preference claim and its boundary. If an alternative set, shortlist, selected set, local choice, gate, or decision is being claimed, use G.5, G.9, C.11, A.21, or the governing pattern.
A scale-preference claim may inform C.32 candidate generation or supply one input to an A.19.CPM comparison by naming the scale variable, scale window, expected stable or improving structure, exception-growth risk, and source-return condition for candidate alternatives. Use C.32 to construct the candidate architecture palette, A.19.CPM to compare alternatives, G.5 to declare a selected-set result, C.11 to make a final local choice, and C.32.PAD to record a project architecture decision. When audience availability is current, use E.17 for a source-backed publication face and return to source and E.24.PUB for the publication occurrence, form, carrier, audience, bounded use, and availability. Apply the relevant evidence, assurance, gate, or release definition and test only when that claim is current.
When the same scale-sensitive pressure must also become a project criterion, C.32.ACS creates a separate row for the exact characteristic or Q-Bundle slot, bearer, scale form, and use class. That row may supply declared input to an ASAP preference. Use C.31.ASAP to state which alternative is preferable under the scale window; use C.32.ACS to admit and classify the criterion row as an optimization indicator, guardrail, or context-only row. Keep the preference record and criterion row separately referenced.
Scale variables
Typical architecture scale variables include:
The scale variable is not enough by name. The claim being made also needs a scale window, expected stable or improving structure, exception-growth risk, and source-return condition.
Scale audit outputs
Use the heavier audit only when the scale preference changes comparison, publication, selected-set, assurance-input, or decision use:
For ArchitectureScaleAuditRecord@Project and BespokeResidueRegister@Project, @Project is a compatibility and retrieval cue. An audit local to one actual project names both the exact composite U.Work in projectWorkOccurrenceRef and the obtaining direct audit-use relation in architectureScaleAuditProjectUseRelationRef. BespokeResidueRegisterRef may cite the register episteme. Assert that register's project locality only after a separate direct register-to-work relation is governed, and cite that exact occurrence; the audit-use relation remains about the audit. Otherwise retain only retrieval use and make no audit or residue-register project-locality claim.
ArchitectureScaleAuditRecord@Project records the triage of an architecture scale-preference claim. An assurance proof, gate record, selected-set result declaration, publication occurrence, local decision, or work plan remains a separate result under its own pattern; use A.15.2 for the work plan.
Waiver discipline
A deontic constraint, safety boundary, law-domain boundary, mission constraint, assurance infeasibility, or scale-probe overturn can justify a bounded exception without creating ArchitectureHeuristicDebt.
ArchitectureHeuristicDebt remains report-only unless tied to a decision, risk, work, evidence, assurance, or selected-set record through its governing pattern.
Scale-refactoring moves
Before scale-preference guidance becomes action-guiding, name at least one possible repair or stop:
C.29 lens relation
When a scale preference depends on an RG, coarse-graining, epiplexity, graph, multilevel-learning, or frustration lens, use C.29 for the mathematical-lens recovery and keep the architecture scale-preference claim in C.31.ASAP. Use C.18.1 for any scale-law claim.
For architecture use, the C.29 output should name MLU.Description@RGArchitecture, MLU.Description@MultilevelLearningFrustration, or another local MathLensUse output only when the lens changes the next admissible use. The C.31.ASAP side records the scale variable, scale window, slope or scale-probe evidence, exception-growth risk, and source-return condition. C.29 records candidate mathematical object, mapping mode, preserved structure, lost structure, visible payoff, declared use, stop condition, and any blocked overread justified through F.19.
Archetypal Grounding
Filled triage slice
Admissible move: prefer the platform alternative as a local scale-preference guide and start interface-grammar repair before deployment spread increases. Stop at local guidance; open the direct selected-set, evidence-sufficiency, assurance, gate, or decision pattern only when that downstream claim is current.
Near-miss lowering slice
Near-miss: a team says the platform architecture should win because it has an 82 percent reusable-structure share, an RG-like coarse description, and "less bespoke debt" than the local variant.
Lowering replay:
- The platform label is a source cue, not scale-preference evidence; recover variability slots, extension rules, exception curve, and source-return condition first.
- The 82 percent reusable-structure share stays report-only under C.31.RSA until the scale variable, scale window, accounting basis, comparator admission, and admissible comparison relation are declared.
- The RG-like phrase stays with C.29 unless the mathematical-lens fields, preserved structure, lost structure, payoff, admissible use, and stop condition are recoverable.
- The "bespoke debt" label is lowered to waiver review when safety, law-domain, mission, assurance, or scale-probe overturn reasons may justify the local variant.
Stop C.31.ASAP use when the scale window, probe evidence or no-probe reason, comparator admission, or source-return condition is absent. Reopen it only after those fields are recoverable and the platform-label, share, lens, and waiver claims have their governing patterns.
Bias-Annotation
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
Rationale
C.31.ASAP is added because C.31 and C.31.RSA can expose scale-sensitive characteristics and reusable-structure residue, but they should not themselves decide which architecture alternative is preferable under scale. C.31.ASAP governs this architecture scale-preference claim family; it is narrower than general BLP and broader than one measurement card.
The pattern adapts BLP-style scale-amenability to architecture: prefer the alternative that preserves or improves reusable structure over a declared scale window when safety, law-domain, and assurance boundaries are comparable. Treat modularity, reuse, platform practice, and mathematical coarse-graining as candidate cues. Base the preference on the named scale variable and window, expected stable or improving structure, exception-growth risk, and available slope or scale-probe evidence or no-probe reason.
SoTA-Echoing
Relations
- Builds on:
C.31,C.31.RSA,C.16,A.2.6,A.17,A.18,A.19,C.18.1,C.19.1, andC.29; uses A.1.1 only when a selectedBoundedModelUseStructurechanges the receiving interpretation. - Coordinates with:
A.6.Mfor module-interface relation repair;C.30,C.30.ASV,C.30.LCA, andC.30.ILCfor architecture and selected-structure questions;C.33,C.34, andC.35when scale-amenability material needs captured-structure adequacy, lost-structure adequacy, preservation adequacy, correspondence adequacy, or generated-carrier adequacy before candidate use;C.32.P2Swhen scale-amenability pressure must continue through problem-to-structure architecturing;C.32.ACSwhen the pressure is represented as a distinct project criteria row;C.32when scale preference informs candidate architecture generation;A.19.CPMwhen it supplies one input to explicit comparison;A.10,B.3, andG.6for evidence and assurance reliance;G.5,G.9, andC.11for selected-set, parity, and choice claims. - Boundary:
C.31.ASAPgoverns architecture scale-preference claims.C.32.ACSgoverns criteria-set and criteria-row construction;A.19.CPMgoverns explicit comparison.C.31,C.31.RSA,C.29,C.18.1,C.19.1,G.5,G.9, andC.11govern modularity-characteristic, reusable-structure accounting, mathematical-lens, scale-law, general method preference, selected-set, parity, and local-choice claims when those claims are being made. - Precision-restoration relation: source wording recovered by
E.10,E.10.ARCH, orC.30.STRATis governed by C.31.ASAP only when the recovered claim being made is architecture scale preference over a declared alternative set, scale variable, and scale window.
C.31.ASAP:End
Architecture Candidate Synthesis
Type: Architectural pattern Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when a practitioner has a C.30-grounded architecture question for one exact described holon and needs to synthesize several candidate architecture configurations across selected structures before comparison, archive or front-policy work, selected-set result declaration, actual publication, or decision. Keep any obtaining C.30 ArchitectureRelation occurrences, the selected U.Structure values they relate to the holon, and any candidate, required, desired, or expected structures named only in an ArchitectureClaim distinct throughout the synthesis.
Primary working reader: an architect or architecture-responsible practitioner preparing alternatives for one described holon before comparison, selection, selected-set result declaration, actual publication, local choice, or project decision.
Typical entry phrases:
First-minute use slice. A regulated product-family team has a C.30-grounded architecture question for one exact field-device-family holon. The question names its current obtaining ArchitectureRelation occurrences and their selected structures separately from candidate or expected structures stated only in the current ArchitectureClaim. The work question is synthesis: how should required functions, constructive modules, field placement, control responsibility, and certification evidence be coordinated so maintainability, substitutability, latency, and evidence reuse stay acceptable? Using C.32, the practitioner first records the selected structures and what each contributes to the synthesis, then records three candidate configurations: one shared module grammar with tighter evidence scope, one product-family split with lower interface burden, and one bounded exception that keeps the existing module split but changes evidence responsibility and reopen trigger. The team now has candidate architecture configurations under declared characteristics, not one attractive platform proposal and not new obtaining architecture relations by candidate wording.
The primary EntityOfConcern is the candidate architecture palette for one C.30-grounded synthesis question. Its inputs are the described holon, any obtaining ArchitectureRelation occurrences and their selected U.Structure participants, and any candidate, required, desired, or expected structures stated only in an ArchitectureClaim.
The described holon may be a system, product family, organization-as-system, discipline, AI-agent setup, built asset, episteme, Work occurrence, or another admitted holon kind. Do not admit a source label as a holon. For example, practice, culture, tradition, style, Method, or role may refer to a Method, Method relation structure, relation among local system-role kinds, classification, assignment, Work structure, episteme, source-local meaning, or C.36 cultural-evolution relation. Recover the actual object and claim through its subject pattern; route unresolved claim-bearing role wording through [E.10.ROLE](/generated/patterns/E.10.ROLE).
ClaimScope and a bounded model-use structure qualify the named use; neither becomes the holon. Architecture pressure may concern Method-family structures, relations among local kinds, classifications, or assignments. Keep each as a selected structure or separate input for the named architecture use, not as a holon kind or function bearer by label. C.32 is not software-system architecture by default; software-system sources are one source family and one domain example.
What goes wrong if C.32 is missed: the team optimizes one visible structure, such as modules, placement, team responsibility, control relation, or evidence package, and then treats that local improvement as architecture synthesis. The competing structures, architecture characteristics, losses, and alternatives disappear before they can be compared.
What C.32 buys in practice: a practitioner can build a small set of candidate architecture configurations, each grounded in selected structure changes, architecture characteristics, known losses, and patterns for the next questions.
Ordinary working move: name the selected structures that really change, name the few architecture characteristics that make the trade-off real, then write two to five candidate configurations with gain, loss, preserved structure, hidden loss, and next receiving use.
Adoption test: after using C.32, another practitioner can see at least two structurally different candidate configurations, the selected-structure changes, the architecture characteristics under pressure, each gain and loss, the source-return condition, and the next receiving use.
Use C.32 only for candidate palette construction. Do not use it to ground the architecture claim, recover one structure, build characteristic criteria rows, design eval programs, handle architecture-influence correspondence, run archive or front-policy work, declare a selected-set result, publish it to an audience, choose locally, or decide the project architecture.
Use [C.32.MWA](/generated/patterns/C.32.MWA) instead when several structures of Methods, Work, subjects and their descriptions, capabilities and providers, and cultural change do not line up one-for-one and the needed result is one usable practice architecture. Keep C.32 for a palette of candidate configurations for one grounded architecture question; do not copy the C.32.MWA action sequence here.
Common exits by claim kind:
[C.30](/generated/patterns/C.30)grounds the described holon, any obtainingArchitectureRelation, its selectedU.Structure, and any separateArchitectureClaim;[C.30.ASV](/generated/patterns/C.30.ASV),[A.6.F](/generated/patterns/A.6.F), and[A.6.M](/generated/patterns/A.6.M)recover structural views, function wording, and module-interface relations.[C.32.HCS](/generated/patterns/C.32.HCS),[C.32.ACS](/generated/patterns/C.32.ACS),[C.32.ACE](/generated/patterns/C.32.ACE),[C.25](/generated/patterns/C.25),[C.31](/generated/patterns/C.31),[C.31.ASAP](/generated/patterns/C.31.ASAP), and[C.16](/generated/patterns/C.16)govern starter heads, project criteria rows, eval programs, Q-Bundles, modularity or scale-preference claims, and measurement.[C.32.MLAO](/generated/patterns/C.32.MLAO),[C.32.CONWAY](/generated/patterns/C.32.CONWAY),[C.32.FAIL](/generated/patterns/C.32.FAIL), and[C.29](/generated/patterns/C.29)govern residual-reducing frames, architecture-influence and transformed-architecture correspondence, candidate repair, and mathematical-lens use.- Use
[A.19.CPM](/generated/patterns/A.19.CPM)for comparison,[A.19.SelectorMechanism](/generated/patterns/A.19.SelectorMechanism)for set-returning selection,[C.18](/generated/patterns/C.18)and[C.19](/generated/patterns/C.19)for archive, front, and current-pool treatment,[G.5](/generated/patterns/G.5)for selected-set result declaration,[C.11](/generated/patterns/C.11)for local choice, and[C.32.PAD](/generated/patterns/C.32.PAD)for a project architecture decision. When audience availability is current, use[E.17](/generated/patterns/E.17)for a source-backed publication face and return to source and[E.24.PUB](/generated/patterns/E.24.PUB)for the publication occurrence, form, carrier, audience, bounded use, and availability. [C.30.AD](/generated/patterns/C.30.AD),[E.17](/generated/patterns/E.17),[E.24.PUB](/generated/patterns/E.24.PUB),[A.10](/generated/patterns/A.10), and[B.3](/generated/patterns/B.3)govern architecture-description, publication-face, evidence, and assurance claims.
The first useful output is CandidateArchitecturePalette@Project. It is the project working record for candidate-palette construction. The name does not introduce a new U.* kind, and the record does not carry selection, publication, evidence, assurance, or decision authority.
For a first pass, fill only the described holon, synthesis question, intended palette use, current architecture relations and selected structures that change the question, selected-structure contribution rows, live architecture-characteristic rows, candidate configurations, and palette stop condition. Add ClaimScope or a bounded model-use structure only when it changes synthesis; add other optional refs only when they change the next use of the palette:
Across C.32, @Project is a compatibility and retrieval cue, not a project kind or relation assertion. CandidateArchitecturePalette@Project, ArchitectureSynthesisFrame@Project, and ArchitectureCharacteristicImprovementLoop@Project establish no composite project work, context, authority, viewpoint, or parthood by name. When one of these records is genuinely local to one actual project, identify the exact composite U.Work and the direct relation by which synthesis framing, palette construction, or improvement feedback concerns that work. Otherwise no project-work relation is implied. A cited ArchitectureQuestionCard@Project transfers neither project locality nor architecture truth: each affirmative currentArchitectureRelationRef must already resolve to one obtaining C.30 occurrence, while candidate, required, desired, or expected structure remains claim content until the C.30 predicate is independently satisfied.
Problem
Architecture synthesis is the constructive middle of architecture work. A practitioner may already know the described holon, architecture question and intended use, some obtaining architecture relations and selected structures, and some concerns, but still need to configure those structures together before later comparison or decision can be honest.
The typical synthesis problem is multi-structure. State each required function or functioning claim through the predicate and bearer recovered with A.6.F. Candidate module, placement, control, transformation-flow, information, evidence, Method, Work, local-kind, classification, or assignment structures may constrain or help explain a candidate, but a kind or assignment establishes no functioning, participation, capability, function bearing, or Work. A control relation can improve supervision while increasing timing or responsibility burden; an information structure can improve maintenance access when exposed through a digital-twin view while still hiding source-return loss; a team structure can improve flow while failing to match module or deployment structure. Every positive responsibility claim still needs its direct domain predicate, actual participants, applicability, and occurrence identity, or the exact A.6.RCD missing governor.
A functional architecture is not enough by itself. A function graph, use case decomposition, workflow, neural cell graph, Method step, or source function from cultural or practice material can enter architecture synthesis only after A.6.F identifies the function or functioning claim and its possible bearer, and after any selected structure or source label is recovered. If no bearer can satisfy the A.6.F predicate under the relevant module, Method, resource, placement, control, Work, evidence, local-kind, classification, or assignment constraints, the candidate must be repaired before it enters comparison, selection, local choice, or decision work. Those neighboring structures constrain the candidate; they do not bear the function by label.
The typical synthesis problem is also multi-characteristic. Architecture characteristics such as cohesion, coupling, substitutability, evidence reuse, work repeatability, latency, locality, control separation, source-return cost, and composite quality families often compete. Functional demands describe what the holon is to do; architecture characteristics describe whether the selected structures make those demands maintainable, controllable, evolvable, replaceable, inspectable, and otherwise acceptable in the current context.
One recurring candidate-generation heuristic is idealization: ask whether an existing selected structure or resource can carry an additional required function, whether a support bearer can disappear, or whether a more general scale-amenable bearer can replace several special bearers. Admit that heuristic only as a candidate. The candidate must name the functions transferred to a bearer, the bearer removed or generalized, the architecture characteristics improved and worsened, and any BLP scale window or waiver when scale advantage is claimed.
Use C.32 to make the constructive translation explicit. Build a small palette whose candidates answer: which selected structures are configured together, which architecture characteristics improve or worsen, which constraints remain admissible, what source detail must remain recoverable, and which pattern supplies the next claim or test.
Forces
Solution
Create an ArchitectureSynthesisFrame@Project when the selected structures and characteristics are not yet visible enough. The frame is a temporary visibility aid for C.32 use; the palette remains the first useful output. Then create a CandidateArchitecturePalette@Project. Treat the palette as a small constructive object over selected structures of a described holon, not as a checklist, not as a decision, not as a selected-set result declared under G.5, and not as a publication occurrence.
Work in seven steps:
- Anchor the palette to one described holon or holon family, synthesis question, and intended next use. Name any current C.30 architecture relations and selected structures that can change that question.
- Write the smallest useful set of selected-structure contribution rows. Start with the functional demand and candidate bearer recovered with
A.6.F, constructive module or manufacture structure, and placement or deployment structure when they shape the question; add control, transformation-flow, Method, Work, local-kind relation or classification, assignment, information, evidence, scale, or other selected structures only when they change the synthesis question. Send unresolved claim-bearing “role” wording throughE.10.ROLE. For each required function, name at least one admissible bearer under the declared constraints. - Reference the architecture-characteristic criteria rows and any Q-Bundle slots that make the trade-off real. Separate functional demand, architecture characteristics, criteria rows, eval results, and decisions.
- Generate candidate architecture configurations. A candidate claim may propose, for example, changed decomposition, allocation, A.6.F function bearing, bearer count, placement, interface grammar, a control or transformation-flow relation, Method use, future assignment conditions, an independently established responsibility relation, evidence scope, information structure, or a bounded exception. Modal candidate wording creates no assignment occurrence and proves no Work occurred. Use a WorkPlan, policy, commitment, permission, decision, or other truthful prospective object when one applies. For actual precise Work, recover each exact actual performer System through A.13 and let A.15.1 independently admit the dated Work and enacted Method; add an assignment occurrence, its declared species, and F.6 only when the candidate account or its receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment. F.6 identifies neither assignment nor performer, missing or failed F.6 leaves the Work intact, and an assignment never carries responsibility by itself.
- For each candidate, state selected structure changes, expected architecture gain, known architecture loss, constraint fit, preserved structure, lost or hidden structure, and source-return condition.
- When a front, archive, search result, or pool-treatment policy is being used, cite
C.18,C.19, or NQD and OEE support as generation or retention support only. Keep the C.32 candidate content separate from archive work, front membership, pool treatment, selected-set result declaration, actual publication, and local choice. - Stop when the palette contains the fields required by the pattern for the next question, such as comparison, C.18 or C.19 front-policy use, selected-set result declaration, actual publication, local choice, decision, or repair.
These contribution rows are not an audit checklist. Together they name only the structures that actually change the candidate configuration.
Architecture-characteristic improvement loop. C.32 is one turn in a continuing improvement cycle over architecture characteristics, not a one-shot search for final form. The practitioner starts with characteristic pressure or criteria rows from C.32.ACS, C.31, C.25, C.16, C.16.P, C.31.ASAP, or a local Q-Bundle; synthesizes candidate selected-structure changes; and records which criteria rows are expected to improve and which protected rows may worsen.
ArchitectureCharacteristicImprovementLoop@Project is a local feedback record for reopening C.32 synthesis when characteristic pressure changes. It is not an E.23 method, an ACE eval program, a comparison rule, a selection result, or a decision.
Keep each receiving claim with its subject pattern.
Criteria rows stay with C.32.ACS; Q-Bundles with C.25; scale preference with C.31.ASAP; measurement with C.16; eval programs and eval results with C.32.ACE.
Improvement-question framing and repeated-improvement method stay with E.22 or E.23.
Use A.19.CPM for comparison, A.19.SelectorMechanism for set-returning selection, G.5 for selected-set result declaration, C.11 for local choice, and C.32.PAD for a project architecture decision. For publication, use E.17 for a source-backed face and source return and E.24.PUB for the publication occurrence and audience availability.
For this loop, bring only the changed characteristic pressure into C.32 and return the next candidate palette.
Open the next synthesis question from the resulting eval result, front relation, retained alternative, rejected candidate, or source-return trigger.
An eval result that cohesion improved, evidence reuse decayed, coupling changed, latency worsened, or exception growth changed does not choose an architecture. A practitioner may use it as feedback only after the bearer, criteria row, scale or qualitative reading frame, selected structures, parity frame, and pattern for the next question are recoverable.
Candidate architecture changes are local C.32 entries for candidate configurations. They are not FPF work occurrences, method steps, or receiving-pattern claims. A change is admissible only when the selected structure being changed is named.
Didactic mini-slices. Use these as examples of the kind of work C.32 expects, not as domain-specific templates.
When one independently typed architecture-side or other source constrains transformed-side architecture content for a changed referent, use [C.32.CONWAY](/generated/patterns/C.32.CONWAY) before using Conway, mirroring, or inverse-Conway language in candidate synthesis. The practitioner names the changed referent and any actual A.3.4 transformation separately, each influence source by exact kind and its direct relation only when that occurrence is asserted, and, for each actual architecture side, the exact C.30 described holon, obtaining ArchitectureRelation, and selected U.Structure; modal architecture content stays in an exact ArchitectureClaim. Without an admitted and satisfied direct influence predicate, the pressure stays synthesis-local in the C.32.CONWAY frame with its missing-governor, unresolved-grounding, or false-predicate disposition and no exact pair row. Candidate work then names influence-source-side, transformed-side, joint, or bounded-mismatch changes, architecture characteristics under pressure, expected gains, known losses, and source-return conditions.
Keep the candidate palette as the C.32 result. [C.32.CONWAY](/generated/patterns/C.32.CONWAY) carries the architecture-influence correspondence frame or one exact reusable pair-row episteme. Influence alone supplies no acting System, local system-role kind, System-classification judgment, assignment, Work, changed-referent identity, or transformation participation. Transformation, acting and Work attribution, exact influence, transformation-flow, and module-interface claims belong to [A.3.4](/generated/patterns/A.3.4), [A.12](/generated/patterns/A.12), [A.2.1](/generated/patterns/A.2.1), [A.15.1](/generated/patterns/A.15.1), [F.6](/generated/patterns/F.6), the direct influence pattern, [E.18](/generated/patterns/E.18), C.30.TFS-REL, or [A.6.M](/generated/patterns/A.6.M) when current. Structural-similarity or preservation claims belong to [C.29](/generated/patterns/C.29) when they are current.
A richer dossier is optional. Open it only when one candidate must carry source views, relation notes, measurements, C.29 lens outputs, evidence notes, or failure repairs that affect the next architecture use. Ordinary C.32 use should remain one row per candidate configuration.
Downstream use. The C.32 result is architecture-specific candidate content. Use [G.5](/generated/patterns/G.5) to declare a selected-set result, [C.11](/generated/patterns/C.11) for a fixed local choice, and [C.32.PAD](/generated/patterns/C.32.PAD) for a project architecture decision. Use [C.18](/generated/patterns/C.18) or [C.19](/generated/patterns/C.19) for archive, front, pool-treatment, or generation policy when that claim is current. Use [C.30.AD](/generated/patterns/C.30.AD) for architecture-description work. For publication, use [E.17](/generated/patterns/E.17) for a source-backed face and source return and [E.24.PUB](/generated/patterns/E.24.PUB) for the publication occurrence and audience availability.
Stop condition. Stop C.32 when the palette can support the next use without hiding the selected structures, architecture-change kind, architecture gain, architecture loss, constraint fit, source-return condition, or pattern for the next question.
Lowering condition. Lower the record out of C.32 use when the needed architecture claim is not grounded, the item is only a source artifact, only one configuration is visible, the candidate lacks selected-structure change, the functional demand has no feasible bearer, the architecture gain or loss is unnamed, or the next use is already comparison, selection, selected-set result declaration, actual publication, local choice, decision, evidence, or assurance. Use [C.30](/generated/patterns/C.30) for grounding, the source or description pattern for source artifacts, [C.32.FAIL](/generated/patterns/C.32.FAIL) for candidate repair, and the named pattern for the next question when the downstream claim is current. Reopen C.32 when a criteria row, eval result, retained alternative, front relation, source-return trigger, or source-currentness change alters the selected structures under pressure or the acceptable loss profile.
Archetypal Grounding
Tell. The regulated product-family first-minute slice in the Problem frame shows the minimum complete move: one grounded question, a small set of selected-structure contribution rows, three genuinely different candidate configurations, explicit gains and losses, and no premature decision. Show. The cases below vary the described holon and the selected structures while keeping that move recognizable. Show again. The didactic mini-slices in Solution 4 show what to repair when a required function has no feasible bearer. These three views are one grounding set, not three additional procedures.
Bias-Annotation
Scope: Limited to constructing a small candidate architecture palette for one C.30-grounded architecture question about one described holon or holon family. C.32 is not a universal architecting Method, a software-architecture default, a comparison or selection rule, a publication route, or a decision procedure.
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Architecture trade-off failures
More repair cues
Consequences
Rationale
Architecture practice needs a method between a grounded architecture question and an architecture decision. Use C.30 to ground the question over selected structures of a described holon. Use C.30.ASV, A.6.F, A.6.M, C.30.LCA, C.30.TFS-REL, C.25, and C.31 to recover the particular structures and characteristics. Later, use C.18 or C.19 for front, archive, or pool treatment, G.5 for selected-set result declaration, E.17 and E.24.PUB for their distinct publication jobs, C.11 for local choice, and the applicable decision pattern for a project decision.
Use C.32 for the constructive middle: building a small set of candidate architecture configurations whose selected structures, allocations, characteristic trade-offs, known losses, source-return conditions, and patterns for the next questions are explicit.
The same middle repeats during improvement. A later criteria-row change, scale-row change, C.16 reading, C.25 or C.31 pressure change, C.31.ASAP scale-preference change, or C.18 or C.19 front, archive, or retained-alternative relation can reopen C.32 when it changes the architecture-characteristic pressure, the selected structures under stress, or the acceptable loss profile. The practitioner then synthesizes another candidate palette; the trigger does not decide the architecture.
The nontrivial work is not to warn against every possible confusion. The work is to make synthesis real enough that architecture content is available for a later front, comparison, selected-set result declaration, actual publication, or decision.
SoTA-Echoing
These rows show how source practice contributes to C.32. The opening of each second-column entry classifies the source use; the opening of each transfer states its disposition. The blocked-overread column gives the use limit, and the source-currentness boundary below gives the reopen rule. Software-system sources are comparison inputs, examples, or lineage only; they do not narrow C.32 to IT architecture.
Source-currentness boundary. Use each source row only for the C.32 candidate-generation move that the row transfers. If a named standard, guide, book edition, survey, or research line changes that move, recheck the row before using it again. If a receiving FPF pattern named in the row changes how it handles the source family, recheck the row before using it again. If the project needs comparison, selection, selected-set result declaration, actual publication, local choice, decision, evidence, or assurance, leave C.32 and open the pattern for the next question. Rows named as lineage, such as TRIZ ideality, information hiding, or mature DSM lineage, stay lineage until a current source relation is recovered.
Relations
- Builds on:
C.30for the exact described holon, obtainingArchitectureRelationoccurrences, their selectedU.Structureparticipants, and separately identifiedArchitectureClaimcontent;C.30.P,C.30.ASV,A.22,A.6.F,A.6.M,C.32.HCS,C.32.ACS,C.32.ACE,C.25,C.31,C.31.ASAP,C.16,C.16.P,E.22,E.23,C.19.1,C.30.LCA,C.30.TFS-REL,E.18,A.3.4,A.15, and local patterns for recovering source-side architecture referents. - Uses:
C.30.ILCwhen a residual starts the candidate work;C.32.MLAOwhen residual-reducing multilevel framing is being used;C.32.CONWAYwhen exact influence-source and transformed-side architecture content must be co-synthesized without inferring acting, Work, or transformation facts;C.32.FAILwhen a candidate needs repair before explicit comparison, selection, local choice, or decision;C.32.ACEwhen candidate eval results are needed before later comparison or selection;C.33when a source, description, view, decision record, eval report, handoff, or realized observation captures only part of selected structure;C.34when candidate or source structures need preservation adequacy or correspondence adequacy;C.35when generated or discovered carriers need admission support before candidate palette use;C.29when mathematical-lens use is being claimed. - Patterns for the next questions:
A.19.CPMfor explicit comparison claims,A.19.SelectorMechanismfor set-returning selection claims,G.5for selected-set result declaration,C.18andC.19for archive, front, or pool-treatment policy,C.11for fixed local choice,C.30.ADfor architecture-description work,E.17for a source-backed publication face and source return,E.24.PUBfor the publication occurrence and audience availability, andC.32.PADfor project architecture decisions. - P2S docking:
C.32.P2Suses C.32 for the candidate-synthesis stages after problem pressure, selected structures, architecture characteristics, and structural uncertainty have been recovered; C.32 continues to define the candidate palette. - Routes to:
C.32.MWAwhen one usable practice-architecture answer must be synthesized from several structures that do not line up one-for-one; C.32 retains general candidate-palette construction. - Boundary: Use C.32 to construct a candidate architecture palette for one grounded architecture question over selected structures of a described holon. C.35 may feed C.32 with generated or discovered carrier adequacy, but C.35 does not select candidates, publish sets, or decide the project architecture. Evidence, assurance, gate, release, work authorization, Method rules, ethical mediation, and causal claims use their own patterns when those claims are being made.
Footer marker
Use C.32 to synthesize a first useful architecture candidate configuration for one grounded architecture question. Later front-policy, selected-set result declaration, actual publication, local choice, architecture-description, decision, gate, release, and authority-relation claims require their own definitions and tests.
C.32:End
Problem-to-Structure Architecturing Unfolding
Type: Architectural process pattern under C.32 Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when an architect or architecture-responsible practitioner has a stated external-use hypothesis for one project system-of-interest and must carry the resulting architecture pressure through selected structures, candidate synthesis, project architecture decision, realization Work, actual-structure feedback, and the next action selected for the current question. If the expected change outside the system, beneficiary or relying use, project designation, boundary hypothesis, or required functioning is not yet intelligible, stop before internal architecture and use the pattern for that missing claim.
The common first moment is practical: a required function has no recoverable bearer; an architecture characteristic is failing; a cross-scope residual survives local repair; a modularity, reuse, interface, scale, or description-loss problem blocks action; one typed Work, communication, tool, method, deployment, evidence, selected-structure, or architecture-side source cannot yet sustain the transformed-side architecture content needed for the changed referent; or operation shows that expected structures and actual structures diverge.
The first useful output is ProblemToStructureArchitecturingFlowCard@Project. The card is a working U.Episteme about one project-local P2S architecturing transformation flow, not the flow itself, the P2S method, a U.MethodDescription, or any planned or performed U.Work. It is not a new U kind, not an architecture claim, not an architecture decision, not a work plan, not an eval result, and not a publication format. It keeps the connected flow reviewable while each local object remains distinct and the practitioner uses the pattern for each current claim.
For the first pass, fill only the fields that prevent the next wrong move: exact problem claim or pressure, described holon, architecture question and intended use, ClaimScope or qualification window when material, first pattern to use, one unknown or selected structure slot, selected transformation-flow structure when one is actually relied on, and pattern for the next claim. Add decision, work, eval, publication, and feedback refs only when the corresponding question becomes current.
For ProblemToStructureArchitecturingFlowCard@Project, flowId designates the exact project-local P2S architecturing transformation flow that is the card's C.2.1 EntityOfConcern. The claims carried by the filled card and the effective U.ReferenceScheme for its designations remain recoverable; changed claim content, changed flow EntityOfConcern, or changed effective reference scheme identifies another card episteme. @Project is a compatibility and retrieval cue only. It establishes no project entity, composite-work identity, context, authority, viewpoint, or parthood. When the card is genuinely used in one actual project, projectWorkOccurrenceRef identifies the exact composite Work occurrence admitted under U.Work and architecturingFlowCardProjectUseRelationRef identifies the direct relation by which architecturing work uses the card. The card, the architecturing work it helps coordinate, and the larger project work remain distinct.
The problem, architecting-side, realization, and architecture refs point to independently established objects; they are not P2S relation kinds. acceptedProblemCardRef resolves to one C.22.2 C.2.1 episteme; the nested signal and pressure fields neither constitute that card nor make an actual Problem obtain. An assignment claim uses architectingAssignmentSpeciesRef and architectingSystemRoleAssignmentRef for its separately declared species and obtaining occurrence; it supplies neither classification nor performance. When performance is current, each exact performer first has its A.13 core and each performedWorkRef names Work independently admitted through A.15.1. performedWorkAttributionRefs are optional and appear only when the flow or receiving use expressly represents precise assignment-bound attribution through the same obtaining A.13 assignment; missing or failed F.6 leaves the Work refs intact. Authority, responsibility, capability, Work, assignment, attribution, and result remain separate.
actualTransformationRefs name independently identified actual changes under [A.3.4](/generated/patterns/A.3.4). The Work-to-change fields pair each relation that actually obtains with the cited pattern or local claim used to check it. The three production refs resolve to separate local [A.15.PROD](/generated/patterns/A.15.PROD) claims and remain absent when their particular question is not current.
actualStructureRefs name subject-side U.Structure values whose declared substrate and selected relation organization are recovered under [A.22](/generated/patterns/A.22) from direct facts that actually obtain; they introduce neither an ActualStructure kind nor an actualization relation. Use C.30 to keep the described holon, obtaining ArchitectureRelation occurrences, selected structures, and any affirmative, negative, unresolved, candidate, required, desired, or expected ArchitectureClaim content separate. actualStructureDescriptionRefs name later descriptions of those structures and do not make them actual.
Not this pattern when the current work is only a problem card, only a grounded architecture claim, only a structural view, only a candidate palette, only a project architecture decision, only an ADR-like publication, only work planning, only performed work, only measurement, only a mathematical lens, or only [G.11](/generated/patterns/G.11) currentness, freshness, telemetry, edition, or decay orchestration. Use the pattern named in Relations for that narrower claim.
Problem
FPF has patterns for problem records, grounded architecture, structural views, candidate palettes, architecture characteristics, eval programs, decisions, ADR-like projections, methods, Work occurrences, separate method descriptions and work-record epistemes, measurements, mathematical lenses, improvement loops, and currentness or decay orchestration. A practitioner still needs one readable pattern for the architecture work that connects them.
Without C.32.P2S, architecture work can fail in two opposite ways.
First, the flow collapses into a description or decision artifact: a diagram, view set, ADR, memo, dashboard, score, or publication record is treated as if it carried the architecture, the decision, and the realized structure. The project then loses the distinction between selected structure, description, decision, method expectation, performed work, and actual structure.
Second, the flow starts inside the boundary or disappears into relation rows. An architect selects modules, interfaces, or an attractive configuration before stating the external change, relying use, project system-of-interest, and functioning hypothesis that would justify them; or every local pattern is correct but no readable flow carries the pressure through Work and feedback. In either branch, the user can name patterns but cannot explain why this internal structure serves the outside use.
Forces
Solution
Create or update one ProblemToStructureArchitecturingFlowCard@Project and apply the P2S method through only the smallest useful part of the Plain action sequence below. The numbered presentation guides attention; it is not by itself a claim about the order, identity, or occurrence of project Work or actual transformations. When the applicable rule in another pattern fully answers the current question, use that pattern and stop there. Continue the P2S card only while the connected project-local P2S architecturing transformation flow remains the object being reviewed.
Before selecting internal structure, state four things in ordinary language: the expected change outside the system, the beneficiary or relying use, the actual or intended project system-of-interest and its boundary, and the functioning hypothesis by which that system could support the use. A merely intended system stays in plan or description content. A.1/A.1.SCR is the pattern for actual-system recognition; A.15.6 is the pattern for project designation; A.1.STM can locate the first unsupported long-map answer. If one of the four statements is missing or contested, return there and do not justify architecture from the inside alone.
Use the analogy with E.18.1 P2W narrowly. A P2W use carries an accepted problem-side record or exact accepted C.22.2 ProblemCard episteme plus the carried distinction into the next FPF use. A C.32.P2S use carries architecture-relevant pressure and structural uncertainty into candidate structures, selected structures, project architecture decision, realization work, and actual-structure feedback. The practitioner then uses the pattern for the next question. The analogy ends when that question is method, work, telemetry, publication, or improvement-loop use; use its pattern rather than stretching P2S into generic process management.
- Recover the problem pressure or architecture concern together with its outside-use basis. Name the expected environmental or relying-use change, beneficiary or user, project system-of-interest designation and boundary hypothesis, required functioning, pressure signals, source-use records, affected holon, and first pattern to use. If the pressure is still only a cue, use C.22.2 and cite the resulting
ProblemCardepisteme when it becomes the accepted input. If an actual Problem is claimed, cite an independently obtaining C.22.PFRProblematicForRelation; the card and its fields create no such occurrence. If the outside-use or system basis is absent, recover it under the applicable recognition or problem pattern before continuing with P2S. - Recover the described holon after the outside-use and boundary hypotheses are visible. State the architecture question and intended use, plus ClaimScope or qualification window when either changes the answer. Then recover candidate or selected structure kinds, selected structures when available, and architecture characteristics. Use C.30 for the grounded architecture claim, C.32.HCS for starter characteristic heads, C.32.ACS for project criteria rows, and C.25 when a composite quality family is current.
- Represent future-structure uncertainty. State unknown structure kinds, unknown internal composition, candidate bearers, interfaces, allocations, variation points, constraints, expected structures, and the condition that returns the work to stronger inspection of the selected or expected structure. Record what is captured, handed off, latent, hidden, or lost.
- Generate architecture ideas, principles, constraints, and candidate structure changes. Use an admitted problem-side record, source-pack cue, architecture pressure note, or candidate-generation input only after the affected selected structure, architecture characteristic, expected gain, accepted loss, and pattern for the receiving claim are recoverable.
- Synthesize candidate architecture configurations and candidate sets through
C.32. Keep function-bearing feasibility, constructive modules, placement, control, transformation-flow, ordinary work organization or actual Work, information, evidence, scale, and other selected structures visible when they change the candidate. Route every unresolved claim-bearing role cue throughE.10.ROLE; carry the recovered local system-role kind, separate System-classification judgment, assignment, direct-relation position, function claim, organization or representation position, or ordinary wording rather than a generic role structure. - Compare, retain, declare a selected-set result, publish it, or return alternatives only under the exact predicate that defines or constrains that relation. Use
A.19.CPMfor explicit comparison,A.19.SelectorMechanismfor set-returning selection,C.18andC.19for archive, front, and pool policy,G.5for selected-set result declaration, andC.11for a fixed local choice. For publication, useE.17for a source-backed face and source return andE.24.PUBfor the publication occurrence and audience availability. - Make a project architecture decision through
C.32.PADwhen implementation commitment is current. The decision relation names the selected architecture option, affected structures, trade-off, accepted losses, method and work consequences, accepted lost-structure return, and decision repair or supersession condition. - Publish descriptions, views, ADR-like records, narrative renderings, or other records only as descriptions, structure-to-narrative renderings, or publication forms of structures, decision relations, method expectations, description or view loss repair, and reader use. Use
C.30.AD,C.30.ASV,C.32.ADR,A.6.3.NAR,E.17, andE.24.PUBas applicable. - Name the intended architecting or realizing Systems first, then make the needed Method descriptions, constraints, readiness expectations, work expectations, and structure-use return conditions available to them under their own access or use relations. Do not call a System a holder unless a separately obtaining assignment is present; assignment neither classifies nor acts. Keep availability or access, local kind, separate classification, assignment, readiness, permission, authority, responsibility, and plan or commitment independent. When performance is claimed, recover each exact actual performer through A.13 and let A.15.1 independently admit the
U.Work. AddperformedWorkAttributionRefsonly when the flow or receiving use expressly represents precise assignment-bound attribution. Add a Work-to-change relation only when that direct predicate obtains. Return the exact missing governor for an unsupported direct claim. - Realize selected structures in the transformed holon through domain work without treating the selected or expected structure, decision, method,
MethodDescription,WorkPlan, model, description, evaluation result, publication, or transfer as the actual structure or as an actual transformation. UseA.15.1for each dated work occurrence andA.3.4for each independently identified actual bounded change. If work is said to cause or realize a change, name the Work-to-change relation and use the cited pattern to check the applicable rule. If no reusable relation is available, cite a local claim selected underA.6.RCDdisposition 2. Use separate localA.15.PRODclaims only when production-work participation, entity-identity inception, or historically indexed production completion is current. The P2S card records refs; it performs none of the work and derives none of those claims. - Observe, inspect, measure, and evaluate subject-side
U.Structurevalues whose declared substrate and selected relation organization are recovered underA.22from relation occurrences, applied constraints, invariants, or other facts that actually obtain. Include architecture-characteristic results and functional-characteristic or capability implications in operation or use. Ask whether those actual structures enable or block the functions and effects they were meant to bear, and ask what selected structure, accepted loss, counter-characteristic, or functional implication got worse when a visible metric improved. A description, measurement, evaluation result, publication, or resemblance to the selected structure does not itself make a structure actual or establish conformance. UseC.30to name an obtainingArchitectureRelationonly when its exact holon, selected-structure participant, and predicate are satisfied; keep candidate, required, desired, expected, negative, or unresolved architecture content in an exactArchitectureClaim. UseC.30.ADorC.30.ASVfor actual-structure descriptions or views,C.32.ACEfor eval programs and eval results,C.16for measurement, andC.25for Q-bundles. UseE.23when repeated improvement method is current,G.11when currentness, telemetry, edition, freshness, or decay orchestration is current,E.18for transformation-flow slice-local refresh,C.18orC.19for archive, front, and pool updates,C.32.PADorC.32.ADAfor decision repair or supersession,C.32for new synthesis, andC.30.ADorC.30.ASVfor architecture-description or structural-view loss repair. Use the pattern for the next question to select the return or repair action from actual-structure divergence, eval results, functional implications, freshness loss, description or view loss, and new constraints.
At the realization boundary, keep selected structure, expected structure, actual subject-side structure, exact dated work, independently identified actual transformations, local production claims, actual-structure description, and evaluation result as different objects. Shared assembly work, temporal adjacency, common affected referents, one flow, or one selected configuration establishes neither one composite transformation nor absence of finer transformation parts. If a receiving claim requires transformation composition, return the exact missing-governor blocker; do not use that blocker to stop independent work, inception, completion, actual-structure, description, evaluation, or return claims.
When architecture-influence correspondence constrains the candidate set, add the C.32.CONWAY branch before synthesis becomes narrow. Name the changed referent and any independently grounded A.3.4 transformation separately. Name every influence source by exact kind. Put only asserted influence facts with an exact obtaining direct relation in influenceSourceRows[]; otherwise keep the pressure synthesis-local in the C.32.CONWAY frame with its missing-governor, unresolved-grounding, or false-predicate disposition. For each actual architecture side, name the exact C.30 holon, obtaining ArchitectureRelation, and selected U.Structure; keep modal content in an exact ArchitectureClaim. Then frame candidate families that change the influence-source side, the transformed side, both, or declare a bounded mismatch with the named correspondence or decision-repair return condition.
P2S Unfolding Structure Block
When the P2S card must remain reusable across patterns for decision, description, work, and feedback claims, add this local block. P2SUnfoldingStructureBlock is an architecture-facing local A.22.CGUS U.Structure specialization block defined here for problem-to-structure architecturing use. That U.Structure, the project-local P2S architecturing transformation flow, the P2S method, and the flow-card episteme remain distinct. A pre-admission ProvisionalUnfoldingDemonstrationDescription or post-admission DemonstrativeUnfoldingSlice is a separate episteme whose displayed order is not the CGUS, flow, method, or Work. The block is not a root U-kind, not an architecture decision, not an ADR, not an architecture description, and not a work plan by itself.
The block is useful when the architecture work has to show how problem pressure constrains candidate, selected, expected, or actual structures without hiding the rule for the next claim or the pattern that contains it. unfoldingStructureRef names the selected CGUS or local architecture-facing U.Structure block. When a narrower-specialization relation is needed, name and test it under the pattern that defines its predicate; use A.6.RCD if that predicate is missing. decisionLinkageRef points to [C.32.PAD](/generated/patterns/C.32.PAD) only when a project architecture decision is current. descriptionRefs[] point to [C.30.AD](/generated/patterns/C.30.AD), [C.30.ASV](/generated/patterns/C.30.ASV), [C.32.ADR](/generated/patterns/C.32.ADR), [A.6.3.NAR](/generated/patterns/A.6.3.NAR), or publication patterns only when a description, view, ADR projection, narrative rendering, or publication claim is current. realizationWorkLinkageRef points to the A.15-family work relation; use [A.3.4](/generated/patterns/A.3.4) for actual transformations. The Work-to-change fields keep the obtaining relation separate from the cited pattern or local claim used to check it. The three production-ref groups point only to separate local [A.15.PROD](/generated/patterns/A.15.PROD) claims. Establish any Work-authorization, performed-Work, or selected/expected-to-actual claim through its direct pattern. Otherwise stop with the problem-to-structure result, next receiving action, and stop or return condition.
groundedArtifactConfusion? is an alias for the same optional blockedOverread? value.
Use e18TransformationFlowUnfoldingRefs[] only for slices whose substrate is transformation-flow structure. P2S itself is broader: it can carry, for example, module, functional, placement, control, method, evidence, scale, and information structures through architecture synthesis and feedback. Any role-like source wording first resolves to the independently relevant local kind, classification judgment, assignment occurrence, direct-relation or representation position, function claim, organization position, responsibility or authority relation, or ordinary label; P2S has no generic role-structure carrier.
Architecture Unfolding Structure Use
Use ArchitectureUnfoldingStructureUse@Project when a named constraint-governed unfolding structure is being used as architecture-relevant structure inside problem-to-structure architecturing. This dependent architecture-use relation record is defined here; use it with the relevant C.30 or C.32 pattern. Record any architecture decision, description, ADR projection, or realization Work through its direct pattern when that claim is current.
For ArchitectureUnfoldingStructureUse@Project, the suffix remains a compatibility and retrieval cue until an exact use is asserted. Every asserted occurrence includes projectWorkOccurrenceRef as the exact composite U.Work participant; without that Work, keep only the retrieval cue and do not assert the relation record. architectureQuestionCardRef may cite the exact C.30 triage episteme, while architectureBearingHolonRef names its independently identified subject. architectureRelationRefs[] contain only independently obtaining C.30 occurrences; modal architecture content stays in architectureClaimRefs[]. unfoldingStructureRef names the admitted CGUS or local block being used. affectedSelectedStructures[], architectureCharacteristicRefs[], and acceptedLosses[] state why the unfolding structure matters for architecture rather than for a generic route. Method and work refs point to the A.15 family only as realization or feedback linkage. For decisions, descriptions, ADR-like projections, measurements, evals, evidence, gates, publication, and performed work, use the exact subject predicates and treat their patterns only as locators.
Stop conditions:
- stop at
[C.22.2](/generated/patterns/C.22.2)when the signal is not yet a reviewable problem-side record; - stop at
[C.30](/generated/patterns/C.30)or[C.30.ASV](/generated/patterns/C.30.ASV)when the current need is only architecture claim or structural-view adequacy; - stop at
[C.32](/generated/patterns/C.32)when the next useful artifact is a candidate palette rather than a whole P2S carry-through record; - stop at
[C.32.PAD](/generated/patterns/C.32.PAD)when the project architecture decision is current; - stop at the A.15 family when the current question is method, work planning, readiness, or performed work;
- stop at
[C.16](/generated/patterns/C.16),[C.25](/generated/patterns/C.25),[C.29](/generated/patterns/C.29),[C.32.ACE](/generated/patterns/C.32.ACE),[E.23](/generated/patterns/E.23), or[G.11](/generated/patterns/G.11)when the current claim is measurement, quality-bundle, mathematical-lens, eval, improvement, or[G.11](/generated/patterns/G.11)currentness refresh; - reconsider P2S only when a later subject assertion establishes architecture pressure that changes candidate structures, expected structures, actual structures, selected structures, or the stronger-structure inspection condition.
Archetypal Grounding
Tell. A capable architect does not merely "document the architecture." The architect carries pressure into structure: first by finding which selected structures are missing or inadequate, then by constructing alternatives, deciding what will be pursued, enabling exact domain work, and watching which subject-side structures actually obtain under operation. An actual transformation is introduced only when its own A.3.4 basis is grounded.
First-minute use slice. A plant architect sees that expected throughput and actual throughput diverge after a layout change. The first P2S card pass names the production cell as described holon, the throughput-after-layout-change architecture question, operating-shift qualification window, pressure kind actualStructureDivergesFromExpectedStructure, first pattern to use C.30, unknown structure material-flow bottleneck bearer, selected structure candidate buffer placement, and pattern for the next claim C.32. The card does not yet add a PAD decision, work plan, or eval result; those refs appear only when their questions become current.
Lens-use slice. If the plant team builds a DSM or epiplexity-style lens over stations, buffers, and routing events, P2S records only the architecture use: which dependency or learnable structural content was preserved, which flow distinction was compressed away, which selected structures the lens can inform, and which lens-use return condition sends the claim back to C.29. The lens result is not architecture adequacy, an eval result, or a decision.
Show A - built asset and technical system. A clinic has rising instrument-turnaround delays and infection-control pressure. The first P2S move does not ask for a better diagram. It names the clinic service system as described holon, the turnaround-and-contamination architecture question, intended operating use, applicable scope and window, candidate structure kinds, architecture characteristics, and uncertainty: room layout, sterile and contaminated flows, equipment modules, tray interface, maintenance work, throughput, contamination isolation, maintainability, and surge adaptability. Candidate synthesis compares a centralized autoclave bay, distributed sterilization modules, and a reusable tray-interface change. Use C.32.PAD for the decision selecting one configuration, C.30.AD and C.32.ADR for its descriptions and publication, and A.15-family patterns for construction and operating work. During operation, measure actual turnaround, contamination events, maintenance burden, and actual-structure feedback triggers.
Show B - organization and Method structures. Inspection work catches ontological errors late. The source may call the object a review practice and speak of checker roles, but P2S first restores the claim: the described holon is the review organization-as-system; if review Work is the subject instead, recover each exact performer through A.13 and identify the U.Work occurrence independently through A.15.1. Use E.10.ROLE to separate any local checker kind, classification, current assignment, direct review-relation position, function claim, organization position, and ordinary audience label. Candidate synthesis compares modal alternatives; it makes none obtain. For later actual inspection Work, add F.6 only when the flow or receiving use expressly represents precise assignment-bound attribution. Telemetry separately shows whether errors are caught earlier.
Show C - architecture-influence and transformed-side co-synthesis. A team wants a modular product architecture but its toolchain, team communication, release method, and evidence workflow only support one tightly coupled build. The team uses C.32.CONWAY within the P2S flow: those typed influence sources and their direct relations remain separate from both exact C.30 architecture sides, the changed referent, any actual transformation, acting Systems, assignments, and Work. Candidate families include changing the product modules only, changing the influence-source structures only, changing both, or accepting a bounded mismatch while retaining a named correspondence-frame return condition. The decision states which side changes now, what architecture characteristics are protected, what Work and exact work-to-change relations realize the change, and what operation or delivery feedback can return to the C.32.CONWAY correspondence frame or to decision repair.
Show D - PumpSkid 7 realization and return. Architecture pressure calls for a modular pump-skid with selected module and placement structures; use C.32.PAD for the project architecture decision. Assembly work W-PS7-ASSEMBLY and later commissioning work W-PS7-COMMISSION are separate Work occurrences admitted under U.Work by A.15.1. Mounting change T-PS7-MOUNT, wiring change T-PS7-WIRE, fluid-connection change T-PS7-CONNECT, and commissioning-related change T-PS7-COMMISSION are each independently identified under A.3.4. Where the assembly or commissioning work is asserted to cause a change, cite the work-to-change relation and its declared predicate. Shared work, temporal adjacency, and one selected pump-skid configuration do not establish one composite transformation. The local A.15.PROD entity-identity-inception claim uses the applicable PumpSkid 7 identity-specification edition, its applicability basis, work-to-change and change-to-identity facts, and inceptionBoundary; it need not assert a composite transformation. Later commissioning can remain production work until subject-state facts at completionBoundary satisfy the applicable production-completion-criterion edition; only then can a separate historically indexed completion claim be written. A later C.30.AD or C.30.ASV record describes the actual structure; use C.32.ACE to evaluate service-access coupling. When coupling is worse than the selected expectation, the eval result returns to decision repair or new synthesis. Neither the description, evaluation, identity-inception claim, completion claim, nor shared assembly work proves conformance to the selected architecture or transformation composition.
Bias-Annotation
Use these rows as repair cues for problem pressure, source-practice transfer, or observed signals, not as a catalogue of mistakes.
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
The project gains one replayable architecturing flow from pressure to actual-structure feedback. Practitioners can see where the Work currently stands and which assertion is next, with the relevant pattern as a locator, without treating descriptions, decisions, eval results, Work occurrences, or separate records about them as interchangeable.
The cost is disciplined record work: the card preserves structural uncertainty, candidate plurality, accepted losses, handoffs, and stronger-structure inspection return. If one narrower pattern already answers the question, use it directly and do not open P2S.
The pattern improves cross-holon and adjacent-structure reuse. Practitioners may apply the same P2S method and Plain action sequence to different project-local flows for holons such as systems, built assets, product families, organizations-as-systems, epistemes, AI-agent setups, disciplines, and C.36-recovered cultural-evolution cases. Sharing that guidance does not give the flows one cross-holon identity or turn the examples into performed-work order. When architecture pressure concerns source wording such as roles, methods, practices, cultures, traditions, or styles, name the described holon and locality separately. Keep each recovered local kind, classification judgment, assignment, direct-relation or representation position, Method, Method relation structure, MethodDescription, Work claim, canon or memory episteme, recognition or selection regime, and mediation-system claim with the pattern for that claim.
The pattern does not guarantee adequacy. It makes the architecturing flow inspectable. For candidate quality, decision adequacy, evidence, assurance, gate passage, release, measurement validity, and G.11 currentness refresh, use the relevant patterns.
Rationale
C.32.P2S belongs under C.32 because its central architecturing concern is architecture synthesis: recovering problem pressure and structural uncertainty, generating candidate selected-structure changes, preserving alternatives, making decision-ready content, and returning actual-structure feedback to the next synthesis question. This architecturing concern is not itself a U.Transformation; identify and test every actual bounded change during realization under A.3.4.
It cannot be only a C.22 pattern because a problem card does not carry architecture synthesis, decision, realization, and feedback. It cannot be only a C.30 pattern because grounded architecture and structural-view adequacy do not supply candidate construction or downstream-work instructions. It cannot be only a C.32 pattern because the palette is only one stage of the larger architecturing flow. It cannot be only C.32.PAD or C.32.ADR because decisions and records do not create the candidate space and do not realize structures. It cannot be only A.15 or E.18.1 because method and work carry-through and P2W do not supply architecture candidate synthesis or selected-structure decision content.
The P2S structural-information slots are necessary because otherwise P2S cannot explain what changes. Architecturing refines uncertainty about future structures into candidate, selected, expected, and actual structures, while descriptions, decisions, methods, Work occurrences, separate records about them, and eval reports capture only part of that content. The practitioner records which structural content is captured by descriptions, decisions, method handoffs, references to Work occurrences, separate work-record epistemes, evals, and measurements; which structure remains latent, hidden, or lost; and which stronger-structure inspection return condition returns the work to stronger structure inspection, description or view loss repair, decision repair, or a C.29 lens use such as epiplexity, DSM, graph, coarse-graining, equivalence, or morphism.
SoTA-Echoing
These rows document transfers from source practice into C.32.P2S. Software-system sources are used as source families and examples only; they do not narrow P2S to IT architecture.
SoTA-anchor currentness boundary. Use each SoTA source-anchor row only for the P2S card field, P2S method or architecturing-transformation-flow step, boundary, or repair named in the row. Recheck the row when the source-practice anchor, applicable FPF pattern, described holon, structure kinds, architecture characteristics, architecture-influence relation, eval mode, or project use changes.
Relations
- Builds on:
A.1andA.1.SCRfor an existing system boundary,A.15.6for project system-of-interest designation and intended-system separation,A.1.STMwhen the missing outside-to-inside dependency must be located,C.22.2for problem-side recovery,C.30,C.30.AD, andC.30.ASVfor grounded architecture, architecture-description adequacy, and structural-view adequacy,C.33,C.34, andC.35for structural-information capture, preservation, and generated or discovered carrier adequacy inside the flow,C.32for candidate architecture synthesis,C.32.HCS,C.32.ACS, andC.32.ACEfor characteristic starter heads, project criteria rows, and eval programs,C.25for Q-bundles,C.31family patterns for modularity, reusable structure, and scale preference,C.29for mathematical-lens use when claimed,E.17for a source-backed publication face and source return, andE.24.PUBfor the publication occurrence and audience availability. - Uses:
A.22.CGUSfor the P2S unfolding-structure block when problem pressure, structure uncertainty, candidate synthesis, decision linkage, work linkage, and actual-structure feedback must remain inspectable as one constraint-governed unfolding structure;E.18.3,C.30.TFS-REL,E.18, andA.3.4when architecture pressure concerns transformation-flow or bounded change;C.30.ILC,C.32.MLAO, andB.2family patterns when cross-scope, interlevel, interlayer, meta-holon, emergence, or reidentification pressure changes the candidate frame;C.32.CONWAYwhen co-synthesis of exact influence-source and transformed-side architecture content is current;C.32.FAILwhen a recognizable architecture-synthesis failure becomes a repair action. - Patterns for the next questions:
A.19.CPM,A.19.SelectorMechanism,C.18,C.19,G.5, andC.11for comparison, selection, archive, front, pool policy, selected-set result declaration, and local choice;C.32.PAD,C.32.ADR, andC.32.ADAfor project architecture decision, ADR-like projection, and decision adequacy;C.30.ADfor architecture descriptions;A.6.3.NARfor architecture-mediated narrative renderings;E.17for source-backed publication faces and source return;E.24.PUBfor publication occurrences and audience availability;A.15,A.15.1,A.15.2, andA.15.5for method, performed work, work plan, and readiness;A.3.4for each actual bounded change; the pattern for the predicate, orA.6.RCD, for Work-to-change claims and blockers;A.15.PRODfor separate local production-work, entity-identity-inception, and production-completion claims;C.16,C.25,C.29,C.32.ACE,E.23,G.11, andE.18for measurement, Q-bundle, mathematical lens, eval, improvement, currentness refresh, and transformation-flow slice-local refresh. - Boundary: Use C.32.P2S for the connected project-local architecturing transformation flow from architecture-relevant pressure to subject-side actual structures recovered under
A.22from obtaining facts, and then to feedback.C.33,C.34, andC.35deepen the structural-information slot group already present in P2S; they do not move the whole connected flow out of P2S. C.32.P2S does not define or test architecture claims, architecture descriptions, structural views, candidate palettes, comparison, selected-set result declarations, decisions, ADR-like publications, publication forms, publication-use claims, methods, Work, measurement, eval, evidence, assurance, gate, release, improvement, currentness refresh, or formal structural-information theory.
Footer marker
Use C.32.P2S for one reader-facing problem-to-structure architecturing flow: pressure and structural uncertainty are carried into candidate, selected, and expected structures, then through domain work to independently grounded actual changes and subject-side actual structures, with descriptions, evaluations, and return or repair exits selected for the next question.
C.32.P2S:End
Architecture-Bearing Family Characteristic Starter Packs
Type: Architectural characterization subpattern under C.32 Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when a practitioner must choose a few architecture-characteristic starter heads for a described holon or for method, system-role-assignment, work, evidence, or cultural-evolution structures recovered from a source label, and the available catalogues are too broad to choose the first project criteria rows.
Primary working reader: an architect or architecture-responsible practitioner choosing a small first set of architecture-characteristic heads for an admitted holon family or another recovered architecture-bearing family, after naming the described holon or source-bearing episteme or publication context and any recovery patterns actually used.
Typical entry phrases:
First-minute use slice. A review lead sees a long quality catalogue and a software-oriented checklist, while the source wording calls the object a reusable review practice. Using C.32.HCS, the practitioner first resolves that label: the live holon is the review organization-as-system; exact review Work occurrences and any presentation carrier remain separate. The relevant structures include a method relation structure, method descriptions, local system-role kinds, separately obtaining assignments, work-product structures, and evidence records. Only then does the practitioner inspect repeatability, transferability, evidence reuse, and exception growth. A.2.7 tests kind substitutability. Assignment continuity, holder replacement, staffing, and Work coverage remain separate candidate characteristics; use the pattern that defines or tests each claim, or return missing-governor. Teachability is recorded as a likely C.25 Q-Bundle. The project carries only those starter heads and first project questions to [C.32.ACS](/generated/patterns/C.32.ACS) instead of copying hundreds of names or admitting "practice" as a holon kind.
The primary EntityOfConcern is one architecture-bearing family starter pack for beginning to turn broad architecture-characteristic names into project criteria rows. A starter head is only a possible characteristic head before project bearer, scale, use class, proxy risk, and protected counter-characteristics are bound. Carry admitted starter heads to ACS. Keep Q-Bundles, measurements, eval programs, candidate palettes, comparison rules, G.5 result declarations, actual publications, and architecture decisions as separate objects handled by their applicable patterns.
Ordinary working move: choose the starter pack for the admitted holon family or recovered architecture-bearing family, keep only the heads that plausibly fit the project, ask the first project question for each head, then hand those heads to [C.32.ACS](/generated/patterns/C.32.ACS) for bearer, scale, and use-class binding.
The first useful output is an ArchitectureBearingFamilyCharacteristicStarterPack@FPF. It is a working starter record under C.32.HCS: it suggests heads and first questions for one admitted holon family or one recovered architecture-bearing family. It does not introduce a new U.* kind and does not by itself create project criteria, scale rows, Q-Bundles, measurement methods, eval programs, or a universal holon ontology:
Use describedHolonRef when the starter heads concern an exact holon. Use presentationCarrierRef only when the carrier itself changes how the starter pack is presented or used; do not fill it as a substitute for the described holon.
What goes wrong if C.32.HCS is missed: the team faces hundreds of -ility or quality names, copies a catalogue, or starts from a software-module list even when a source label such as method, role, culture, practice, built asset, or evidence workflow still hides what actually bears the characteristic.
What C.32.HCS buys in practice: the practitioner has a short architecture-bearing starting point before [C.32.ACS](/generated/patterns/C.32.ACS) turns starter heads into project criteria rows, three to five optimization indicators, and monitored guardrails.
Adoption test: after using C.32.HCS, the project has a short starter set and first project questions; it has not copied a catalogue and has not yet claimed bearer, scale, use class, or optimization status.
Not this pattern when the project already has admitted architecture-characteristic rows with bearers, scales, and use classes. Also not this pattern when the current work is composite-quality modeling, measurement, eval design, candidate synthesis, comparison, selected-set result declaration, actual publication, local choice, or project architecture decision.
Common exits by claim kind:
[C.32.ACS](/generated/patterns/C.32.ACS)for project criteria rows.[C.25](/generated/patterns/C.25)for Q-Bundles and composite quality families.[C.16](/generated/patterns/C.16)for measurement and[C.32.ACE](/generated/patterns/C.32.ACE)for eval programs or eval results.[E.13](/generated/patterns/E.13)when a source-looking cue, score, benchmark, or dashboard starts replacing the architecture concern.[C.32](/generated/patterns/C.32)for candidate synthesis after project criteria rows exist.[A.19.CPM](/generated/patterns/A.19.CPM)for explicit comparison and[A.19.SelectorMechanism](/generated/patterns/A.19.SelectorMechanism)for set-returning selection.[G.5](/generated/patterns/G.5)for selected-set result declaration,[C.11](/generated/patterns/C.11)for local choice, and[C.32.PAD](/generated/patterns/C.32.PAD)for a project decision. For publication, use[E.17](/generated/patterns/E.17)for a source-backed face and source return and[E.24.PUB](/generated/patterns/E.24.PUB)for the publication occurrence and audience availability.
Problem
Architecture characteristics recur more than functions do. Reliability, substitutability, change reach, evidence reuse, control separation, or coordination load can appear across admitted holons and across method, system-role-assignment, work, evidence, or cultural-evolution structures. The same head may require a different bearer, scale, use, or pattern definition or test. Recurrence alone neither establishes that a source-labelled method-like object satisfies U.Method, nor turns a local system-role kind into a holon, nor admits practice or culture as holon kinds.
A function depends on what performs it, while a functional demand may also depend on the holon that needs that performance. A saw-as-system can cut; a system may satisfy a local system-role-kind criterion; an obtaining system-role assignment may place that system in work-facing use; and a direct responsibility relation may hold independently. A method description can guide work, an enacted work family can be repeatable, and an organization-as-system can coordinate. A culture or practice label must first be resolved into systems, disciplines, method and work families, local system-role kinds and assignments, canon or memory epistemes, recognition and selection regimes, or mediation systems. A project therefore needs starter packs that suggest common heads while requiring the practitioner to re-identify the bearer, any separate demand holder, and the scale before optimization.
Forces
Solution
Choose a starter pack by the described holon's declared family. Use the pack only to start narrowing starter heads into project criteria rows; then hand the result to C.32.ACS for the project criteria set.
Starter pack construction
Build or use a starter pack in this order:
- Name the admitted holon family. If the source label is method, role, practice, culture, tradition, style, or evidence practice, first name the described holon, or name the source-bearing episteme or publication context when the label is only a description-side family, and record only the recovery-pattern references actually used.
- List a small set of starter characteristic heads that often matter for that family.
- For each head, name likely bearers or selected structures, not only a quality word.
- Record likely C.25 Q-Bundle boundaries when a head is usually composite.
- State a first project question that helps the practitioner decide whether the head belongs as a draft row in the project criteria set.
- Hand the resulting starter heads to
C.32.ACS; do not optimize or measure inside HCS.
Built-in starter packs
In HCS, source-return cost is a starter head only when a holon family repeatedly pays effort, latency, or risk to move from a derivative, coarsened, extracted, rendered, or reused publication or evidence carrier back to the named source expression, selected source U.Episteme, EpistemePublicationRelation occurrence when availability matters, source-bearing relation, evidence-provenance entry, evidence relation, transform record, or defining ClaimGraph needed for stronger reliance. It is not a generic source-quality name. If the project is only asking whether a catalogue term is useful, keep the wording as source catalogue wording; if recoverability itself is the concern, carry source-return cost to C.32.ACS and bind its bearer, scale, and use.
Rebinding rule
When a starter head is reused at another admitted holon family, declared holon level, or recovered architecture-bearing family, rebind it. The reusable item is the head, not the row.
Example: availability for an engineered service may use time-window and service-scope measures. A method-side case may ask whether an exact System can access a Method description and evidence relation in the working situation. A kind case may ask whether A.2.7 admits substitution; an assignment case may ask whether holder replacement or assignment continuity obtains; a responsibility case needs its own direct relation. These are different bearers, predicates, and scales.
Refresh the starter pack when its starting assumptions no longer hold: the admitted holon family changes, source-label recovery changes the recovered family or bearer, a B.2 whole reidentification changes the bearer or scale, a source catalogue changes the available vocabulary, repeated ACS project-row uses show that a head never survives project binding, or repeated ACS project-row uses reveal a missing head for that family. Refresh only starter-pack fields and blocked overreads. Existing project criteria rows remain with C.32.ACS; measurements remain with C.16; eval programs remain with C.32.ACE.
ACS Criteria-Row Use
HCS stops with starter heads and first project questions. The next C.32.ACS use governs:
- whether C.32.ACS admits the head as a draft project criteria row;
- whether it is one characteristic or a C.25 Q-Bundle;
- whether the project uses it as an optimization indicator, monitored guardrail, or context-only row;
- which scale, reading, and pattern for the next question apply.
Before ACS criteria-row use, ask one proxy-resistance question for each carried starter head: what architecture concern would worsen or disappear if the visible catalogue entry, domain term, benchmark row, or dashboard value looked better? Such visible material is not yet an architecture-characteristic starter head. Carry it forward only when the holon family, likely bearer, likely scale, Q-Bundle boundary, first project question, source catalogue entry, benchmark row, dashboard row, or publication row, source-to-use path, and reopen condition remain recoverable. Also name the selected source U.Episteme and an EpistemePublicationRelation occurrence when availability matters. If no worsening or lost concern can be named, keep the wording as source catalogue wording or remove it from the starter pack.
Stop condition. Stop C.32.HCS when the starter pack names the described holon family, starter heads, likely bearers or selected structures, likely composite-quality boundaries, first ACS questions, and any blocked overread. The next project criteria-row work belongs to C.32.ACS.
Lowering condition. Lower a starter head to source catalogue wording or remove it from the starter pack when the holon family is not declared, the likely bearer or likely scale is missing, the composite-quality boundary is still unresolved, the first ACS question is absent, repeated ACS uses reject the head for that holon family, or the item is being used to smuggle measurement, eval, comparison, publication, local choice, or decision work into HCS. Use C.25 when the head is composite, C.32.ACS when the project criteria-row question is ready, and the named pattern for the next question when the stronger claim is current.
Worked slices
Engineered-system family. A field-device project starts from reliability, maintainability, substitutability, evidence reuse, locality, and source-return cost. C.32.ACS later marks only maintainability, substitutability, and evidence reuse as optimization indicators; safety and availability remain guardrails.
Method-side family. A source calls a reusable review method "the practice." HCS identifies the review organization-as-system as the described holon, then keeps exact review Work, any presentation carrier, the method relation structure, method descriptions, work products, local kinds, separately obtaining assignments, and evidence records separate. The starter heads are repeatability of enactment, transferability, evidence reuse, and exception growth. If substitution is current, A.2.7 tests kinds; assignment continuity, holder replacement, staffing, or Work coverage receives its own predicate and bearer. Teachability belongs to C.25 because it combines learner scope, measures, mechanisms, and evidence.
AI-agent workflow. A retrieval-action setup starts from evidence refresh, policy controllability, latency, observability, and rollback. Benchmark performance stays a benchmark signal or comparison input until an architecture bearer and scale row are named.
Starter-pack proxy near-miss. A review team copies availability, throughput, and testability from a software quality catalogue because the list looks mature. The copied heads make the starter pack look complete, but they hide exception growth, evidence reuse, kind substitution, assignment continuity, and Work coverage, which have different bearers and predicates. C.32.HCS keeps the catalogue terms as source wording; A.3.1 and A.15 separate the Method, descriptions, assignments, and Work, while A.2.7 supplies kind-relation structure and substitution only for kinds. HCS carries only the recovered questions to C.32.ACS.
Receiving-Claim Boundary
Use C.32.HCS only to build architecture-bearing family starter packs. Use C.32.ACS for project scale rows, C.25 for Q-Bundles, C.16 for measurements, C.32.ACE for eval programs, C.32 for candidate synthesis, A.19.CPM for comparison, A.19.SelectorMechanism for selection, G.5 for selected-set result declaration, C.11 for local choices, and C.32.PAD for project architecture decisions. For publication, use E.17 for a source-backed face and source return and E.24.PUB for the publication occurrence and audience availability. C.32.HCS neither establishes a source-labelled object as U.Method, nor turns a local system-role kind into a holon, nor admits practice, culture, tradition, or style as holon kinds.
Conformance checklist
Common failures and repairs
Consequences
Rationale
The 300-to-3 problem needs a middle step. A project cannot optimize from a catalogue, but it also should not invent criteria from scratch. Architecture-bearing starter packs give a small, recognizable entry. Criteria-row construction, measurement, eval, comparison, selection, selected-set result declaration, actual publication, local choice, and project architecture decisions then use their applicable patterns.
SoTA-Echoing
These rows document transfers from source practice into C.32.HCS. Keep a source name only when the draft uses it to set or revise a starter-pack field, an ACS criteria-use condition, or a blocked overread.
Source-currentness boundary. Use ISO/IEC 25010:2023 as ICT product-quality vocabulary, not as holon-family ontology. Use the O'Reilly architecture-characteristic and evolutionary-architecture sources for recurring starter heads and for later metric or eval work after the heads are named. Use an FPF row only for the claim it defines, constrains, or tests. Reopen HCS when a named source edition changes starter-head guidance, when the pattern for a next question changes how it handles that source family, when repeated C.32.ACS uses show that a starter head never survives project binding, when repeated project uses reveal a missing head for the admitted holon family or recovered architecture-bearing family, or when source-label recovery changes the recovered family or bearer.
Relations
- Receiving use:
C.32.ACSproject criteria-set construction, including scale rows and use classes when the project later needs them;C.32.P2Swhen starter heads are needed before the architecturing flow can bind project criteria, candidate synthesis, eval, and refresh. - Uses:
C.25when a starter head is composite;C.30andC.30.ASVwhen the selected structures are not yet recoverable. - Boundary: HCS is not a catalogue, measurement pattern, Q-Bundle pattern, optimization method, or architecture decision pattern.
Footer marker
C.32.HCS closes when the practitioner can name an architecture-bearing starter pack, any needed described holon, source-bearing episteme or publication context, any recovery-pattern refs actually used, starter architecture-characteristic heads, likely bearers, likely Q-Bundle boundaries, and first project questions for C.32.ACS.
C.32.HCS:End
Architecture Characteristic Criteria Set for Improvement Cycles
Type: Architecture characterization pattern under C.32 Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when a project must turn architecture-characteristic pressure into a small project criteria set for architecture improvement, candidate synthesis, residual optimization, and later eval work.
Primary working reader: an architect or architecture-responsible practitioner turning broad quality names into project criteria rows for the next improvement cycle.
Typical entry phrases:
First-minute use slice. A product-family architect has HCS starter heads and source catalogue names for maintainability, substitutability, evidence reuse, safety, availability, latency, and scale amenability. Using C.32.ACS, the practitioner builds project rows and gives each row its bearer, exact U.ClaimScope, relevant A.2.6 U.ContextSlice membership, effective reference scheme and plane, qualification or evaluation window, scale form, proxy risk, protected losses, and source-return condition. Maintainability, substitutability, and evidence reuse become optimization indicators; safety and availability remain monitored guardrails. The source phrase "scale amenability" remains only a starter cue until ACS admits a concrete characteristic row, such as exception growth or interface-grammar variation, with its bearer and scale form; a claim that one alternative is preferable under a declared scale window remains a separate [C.31.ASAP](/generated/patterns/C.31.ASAP) object. C.32 can now synthesize candidates against declared criteria instead of a loose list of quality words.
This pattern concerns one project architecture-characteristic criteria-set record for improvement cycles. Its rows can supply C.32 synthesis, C.32.MLAO residual work, C.32.ACE eval programs, and later patterns for the next questions. The set and its rows are C.32.ACS-local record forms, not new U.* kinds; starter packs, U.Characteristic values, Q-Bundles, measurement methods and results, eval programs and results, candidate palettes, comparison rules, selection results, G.5 result declarations, actual publications, local choices, and architecture decisions remain separate objects.
Ordinary working move: make one row per project architecture characteristic, bind its bearer and scale, mark whether it drives optimization, guards against loss, or only gives context, and record what eval reading can reopen synthesis.
The first useful output is ArchitectureCharacteristicCriteriaSet@Project:
For a first pass, fill the described holon, architecture use, three to five draft row names, and for every row the bearer or selected structure, exact claim scope and selected context slices, reference scheme and plane, qualification or evaluation window, scale form, use class, protected losses, receiving use, and reopen condition. Add readings, target bands, and eval-program references only when the current receiving use needs them; add a selected BoundedModelUseStructure only when it independently changes interpretation of the row use.
For ArchitectureCharacteristicCriteriaSet@Project and ArchitectureCharacteristicImprovementRow@Project, @Project is a compatibility and retrieval cue only; it establishes no project entity, composite-work identity, context, authority, viewpoint, or parthood. A criteria set or improvement row local to one actual project names both the exact composite U.Work in projectWorkOccurrenceRef and the obtaining direct use relation for that exact record in architectureCriteriaProjectUseRelationRef; either field alone is insufficient, and a relation occurrence about the set is not silently reused for a distinct row. Otherwise the record remains retrieval-only and no project locality is asserted.
draftProjectCriteriaRows are draft project criteria rows. They are not candidate architectures, selected architectures, or a selected set returned by [A.19.SelectorMechanism](/generated/patterns/A.19.SelectorMechanism).
What goes wrong if C.32.ACS is missed: the team says that the architecture should be more maintainable, scalable, modular, safe, or evolvable, but no one can say which selected structures carry the characteristic, which few rows are criteria for the next optimization, which rows only guard against loss, which C.25 Q-Bundle is involved, or which eval result can reopen synthesis.
What C.32.ACS buys in practice: the practitioner can reduce broad catalogue and starter-pack material to draft project criteria rows, then to three to five optimization indicators, while keeping other important characteristics as monitored guardrails against Goodhart-style proxy loss.
Adoption test: after using C.32.ACS, the project can name the few rows that drive optimization, the guardrail rows that protect against loss, and the bearer, scale, proxy risk, receiving use, and reopen condition for each live row.
Not this pattern when the current work is choosing the holon-family starter pack, modeling a Q-Bundle, validating a measurement method, designing an eval program, synthesizing candidates, comparing or selecting candidates, choosing locally, declaring a selected-set result, publishing it to an audience, or deciding the project architecture.
Common exits by claim kind:
[C.32.HCS](/generated/patterns/C.32.HCS)for holon-family starter packs.[C.25](/generated/patterns/C.25)for Q-Bundles and composite quality families.[C.16](/generated/patterns/C.16)for measurement templates, readings, units, thresholds, or comparability claims.[C.32.ACE](/generated/patterns/C.32.ACE)for eval-program framing and typed-result classification over declared rows; each actual result is a separate subject assertion under its exact predicate or constraint.[E.13](/generated/patterns/E.13)when an indicator, score, or dashboard starts replacing the declared architecture concern.[E.22](/generated/patterns/E.22)and[E.23](/generated/patterns/E.23)for improvement-question framing and repeated improvement method.[C.32](/generated/patterns/C.32)for candidate synthesis and[C.32.MLAO](/generated/patterns/C.32.MLAO)for residual-reducing candidates.[A.19.CPM](/generated/patterns/A.19.CPM)for explicit comparison,[A.19.SelectorMechanism](/generated/patterns/A.19.SelectorMechanism)for set-returning selection,[C.11](/generated/patterns/C.11)for local choice, and[G.5](/generated/patterns/G.5)for selected-set result declaration. For publication, use[E.17](/generated/patterns/E.17)for a source-backed face and source return and[E.24.PUB](/generated/patterns/E.24.PUB)for the publication occurrence and audience availability.[A.10](/generated/patterns/A.10)and[B.3](/generated/patterns/B.3)when evidence or assurance claims are being made.[C.32.PAD](/generated/patterns/C.32.PAD)for project decision.
Problem
Architecture synthesis needs criteria. A multi-criteria or multilevel optimization phrase is empty until the criteria are named. In C.32-family work, those criteria are admitted architecture-characteristic rows or declared C.25 Q-Bundle slots of the described holon, each bound to its exact bearer, U.ClaimScope, relevant A.2.6 U.ContextSlice membership, effective reference scheme and plane, qualification or evaluation window, and receiving use. A broad domain or bounded-context label supplies none of those bindings.
Architecture characteristics are not the same as user functions. Functional demand says what the holon must do. An architecture characteristic says whether the selected structures make that demand maintainable, controllable, replaceable, observable, evolvable, scalable, affordable, safe enough, or otherwise acceptable.
Source catalogues and textbooks can offer hundreds of possible quality or architecture terms. A project may inspect dozens. The actual optimization loop should normally use only a few indicatorized rows, often three to five. Other important rows remain monitored guardrails or context-only rows so that optimizing one visible measure does not damage functional adequacy, safety, evidence, maintainability, or another protected architecture concern.
C.32.ACS supplies the project criteria set and scale rows. It does not create the holon-family starter pack, define a Q-Bundle, validate a measurement method, run an eval, compare candidates, choose an architecture, or decide the project architecture.
Forces
Solution
Build an ArchitectureCharacteristicCriteriaSet@Project from starter heads, source catalogues, architecture constraints, and the project improvement question.
Kind settlement
ArchitectureCharacteristicCriteriaSet@Project is a C.32.ACS-local project working record: it holds criteria-row references and use classifications for improvement work. Each draftProjectCriteriaRows entry is another local record form, not the referenced U.Characteristic, Q-Bundle slot, scale, predicate, measurement result, eval program, or eval result. The set and rows create no new U.* kind and replace none of those direct objects.
An architecture characteristic is the property or quality-like head under discussion. A C.25 Q-Bundle is the structured form for a composite quality family. A scale row binds one characteristic or Q-Bundle slot to a bearer, scale form, use class, and receiving use. A row whose scale form exposes exception growth, interface variation, or another scale-sensitive characteristic remains a criterion row; a preference between architecture alternatives over a declared scale window is a separate C.31.ASAP claim. An architecture-characteristic eval program belongs to C.32.ACE; it frames evaluation of one declared row, coupled rows, Q-Bundle slots, or C.32 candidate palettes while each actual typed result remains with its subject pattern.
Criteria-set construction
Work in this order:
- Name the described holon, architecture use, and improvement cycle or one-pass eval use. For every proposed row, bind the exact claim scope and selected context slices, effective reference scheme and plane, and qualification or evaluation window. Designate a selected A.1.1
BoundedModelUseStructureonly when it independently changes that row's interpretation. - Start from a
C.32.HCSstarter pack when the project has no draft criteria rows yet. Use source catalogues only as input, not as the criteria set. - Build draft project criteria rows. There may be dozens of draft rows when broad scanning is needed, but each row must have a possible bearer, use reason, and pattern for the next question.
- For each source or starter head, decide whether it is one architecture characteristic, one C.25 Q-Bundle, one Q-Bundle slot, or only source vocabulary.
- Narrow the optimization-indicator core. The ordinary target is three to five rows. More rows require an explicit reason, such as a regulated trade-off study or a multi-team decision use.
- Classify remaining admitted rows as
monitoredGuardrailorcontextOnly. A guardrail protects against a loss caused by optimizing another row; a context-only row helps interpretation but does not drive optimization now. - Bind each admitted row to bearer or selected structure, scale form, polarity, current reading or no-reading reason, proxy risk, protected counter-characteristics, receiving use, and source-return condition.
- Reference
C.32.ACEonly after the row exists and an eval program is needed for current characterization, candidate comparison, monitoring, or preparing inputs forA.19.SelectorMechanism. - Reopen the criteria set when the holon family changes, a B.2 whole reidentification changes the bearer, a guardrail degrades, an eval program no longer fits its declared parity frame, or the source-currentness relation changes the acceptable trade-off.
Row use classes
Use optimizationIndicator only when the row can responsibly guide architecture changes now. A project normally carries only three to five such rows.
Use monitoredGuardrail when the row protects against a loss caused by optimizing another row. Guardrails can have readings and eval results, but they do not define the cycle's optimization direction.
Use contextOnly when the row helps interpretation but should not drive improvement, comparison, or selection in the current cycle.
Stop condition. Stop C.32.ACS when the criteria set names draft rows, use class, bearer or selected structure, scale form, proxy risk, protected counter-characteristics, receiving use, source-return condition, and any C.32.ACE or Q-Bundle reference that the current use actually needs.
Lowering condition. Lower an optimizationIndicator to monitoredGuardrail or contextOnly when it no longer guides the next architecture change or its proxy risk is not controlled. Lower a draft row to source vocabulary when bearer, scale form, use reason, receiving use, or protected counter-characteristics are missing. Use C.32.HCS when the holon-family starting point is wrong, to C.25 when the row is really composite, and to the named pattern for the next question when measurement, eval, comparison, publication, local choice, evidence, assurance, or decision work is current.
Improvement-cycle use
When a row is used inside an improvement cycle, add:
The row prepares improvement work. It does not carry a claim outside its declared scale and use. An eval result is a reading over a declared row; another pattern may use it as source material for an A.10 evidence relation, improvement feedback, comparison input, selection input, or decision input only when that pattern for the next question is named by value. It does not become the characteristic, the declared architecture concern, the architecture choice, or the optimization direction.
Worked slices
Manufacturing cell. HCS suggests maintainability, locality, function-bearer fit, change reach, and scale amenability. ACS keeps nine draft criteria rows, then marks setup-change reach, function-bearer fit, and exception growth as optimization indicators. ACS records safety and evidence reuse as monitored guardrails. C.32 later synthesizes universal-fixture candidates under those criteria.
Method-family architecture. HCS suggests repeatability, teachability, transferability, evidence reuse, exception growth, and change reach. ACS marks evidence reuse, exception growth, and transferability as optimization indicators. Teachability goes to C.25 because it depends on learner scope, measures, mechanisms, and evidence.
AI-agent architecture. HCS suggests evidence refresh, policy controllability, latency, observability, and rollback. ACS marks policy controllability, evidence refresh, and latency as optimization indicators. Benchmark performance is not an architecture characteristic by name; it can supply an eval reading only after the bearer, scale, parity frame, and receiving use are declared.
Team and assignment architecture. A hospital escalation team starts from coordination load, accountability clarity, decision latency, evidence custody, substitutability among local system-role kinds, and continuity of assignment occurrences and their holder Systems. ACS creates separate criteria because A.2.7 can compare or relate local kinds but does not substitute holders. The kind-substitutability row binds the exact local kind-relation structure and predicate; the assignment-continuity row binds the exact assignment occurrences, holder Systems, and continuity predicate. ACS marks decision latency, accountability clarity, and evidence custody as optimization indicators, keeps patient-safety loss and assignment-continuity loss as guardrails, and leaves staffing choice to the receiving decision pattern.
Kind and Receiving-Claim Boundary
C.32.ACS governs project criteria-set construction for architecture improvement. It does not govern:
- holon-family starter packs, governed by
C.32.HCS; - architecture-characteristic eval programs, governed by
C.32.ACE; - C.25 Q-Bundle normal form, governed by
C.25; - C.16 measurement templates or readings, governed by
C.16; - C.31 modularity and reusable-structure characteristic repair, governed by
C.31; - C.31.ASAP scale-preference claims, governed by
C.31.ASAP; - E.22 question framing and E.23 repeated improvement method, governed by
E.22andE.23; - C.32 candidate synthesis, governed by
C.32; - A.19.CPM comparison, A.19.SelectorMechanism selection, C.11 local choice, G.5 selected-set result declaration, E.17 source-backed publication-face and source-return work, E.24.PUB publication-occurrence and audience-availability work, or architecture-decision work for
C.32.PAD.
Conformance requirements
Common failures and repairs
Consequences
Rationale
Architecture optimization is meaningful only after the criteria are named. ACS supplies that middle object: not a generic quality catalogue, not a starter pack, not a Q-Bundle, not an eval program, and not a decision, but a project criteria set that can guide synthesis, residual reduction, and repeated improvement.
The pattern stays holonic by allowing starter heads to recur across holon families while requiring bearer and scale rebinding. It stays action-facing by limiting optimization indicators and keeping non-optimized criteria rows as guardrails.
SoTA-Echoing
These rows document transfers from source practice into C.32.ACS. Keep a source citation only when the draft uses it to set or revise a criteria-row field, use-class rule, or receiving-pattern boundary.
Source-currentness boundary. Use each source row only for the ACS field, use-class rule, or receiving-pattern boundary named in that row. Recheck the row when a named standard, book edition, source presentation, FPF pattern for the next question, or current architecture-evaluation line changes the transferred move. If the project wants measurement, eval-program design, comparison, selection, selected-set result declaration, actual publication, local choice, evidence, assurance, or decision use, leave ACS and open the pattern for the next question.
Relations
- Builds on:
C.32.HCS,A.17,A.18,A.2.6,A.19,C.16,C.16.P,C.25,C.30,C.30.P,C.31,C.31.ASAP,E.13,E.22, andE.23; uses A.1.1 only when a selectedBoundedModelUseStructurechanges one row's interpretation. - Receiving uses:
C.32.P2Sproblem-to-structure architecturing flow,C.32candidate synthesis,C.32.MLAOmultilevel residual work,C.32.CONWAYcorrespondence frames,C.32.FAILrepair cues,C.32.ACEeval programs,A.19.CPMcomparison inputs,A.19.SelectorMechanismselection inputs,C.11local choice inputs, inputs for selected-set result declaration underG.5, source-backed publication-face and source-return inputs underE.17, publication-occurrence and audience-availability inputs underE.24.PUB, and architecture-decision inputs forC.32.PAD. - Starter-pack boundary: Use
C.32.HCSwhen the project needs a holon-family starting set before criteria rows exist. - Q-Bundle boundary: Use
C.25when the architecture characteristic is really a composite quality family with several measures, scope slots, mechanisms, statuses, qualification windows, or evidence. - Scale-preference boundary: Use
C.31.ASAPwhen a project claims that one architecture alternative is preferable over another under a declared scale window; the ACS row supplies a criterion, not that preference. - Eval boundary: Use
C.32.ACEwhen a project wants eval-program framing over declared rows, Q-Bundle slots, candidates, or selected-structure changes; state each actual typed result separately under its exact predicate or constraint. - Measurement boundary: Use
C.16when a reading, coordinate, unit, threshold, score, or cross-case comparability claim is made. - Structural-information boundary: Use
C.33orC.34when the issue is captured structure, lost structure, or preservation adequacy before a criterion row exists. Use C.32.ACS only when that structural-information or preservation concern becomes a declared architecture-characteristic criterion row. UseC.35only as generated-carrier admission support or discovered-carrier admission support before C.32 or ACS receives a criteria-bearing claim. - Proxy boundary: Use
E.13when an optimization indicator, score, eval result, or dashboard state begins to replace the declared architecture concern. - Synthesis boundary: Use
C.32after criteria rows exist and the next useful work is to synthesize candidate selected-structure changes. - Decision and publication boundary: Use
A.19.CPMfor comparison,A.19.SelectorMechanismfor selection,C.11for choice,G.5for selected-set result declaration, andC.32.PADfor an architecture decision. For publication, useE.17for a source-backed face and source return andE.24.PUBfor the publication occurrence and audience availability.
Footer marker
C.32.ACS closes when the project can name the starter-pack row or source-catalogue line, draft project criteria rows, optimization indicators, monitored guardrails, context-only rows, bearers, row claim scopes and selected context slices, reference schemes and planes, qualification or evaluation windows, scale forms, current reading or no-reading reason, protected counter-characteristics, receiving uses, and source-return conditions. Continue with the pattern whose use conditions match the next question. If later precise Work is asserted, recover each exact actual performer System through A.13 and let A.15.1 independently admit the dated Work and enacted Method; add an assignment occurrence, its declared species, and F.6 only when the ACS account or receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment. F.6 identifies neither assignment nor performer, missing or failed F.6 leaves the Work intact, and ACS itself creates none of these facts or responsibility or agency.
C.32.ACS:End
Architecture Characteristic Eval Programs
Type: Architecture eval-support subpattern under C.32 Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when an architecture team already has project architecture-characteristic rows and must evaluate the current architecture, compare candidate architectures, monitor evolution, or prepare a selection input.
Primary working reader: an architect or evaluator preparing readings over declared architecture-characteristic criteria without turning those readings into the criteria or the decision.
Typical entry phrases:
First-minute use slice. A product-family team has ACS rows for substitutability, evidence reuse, and latency, plus safety as a monitored guardrail. Two candidate architectures look plausible. The practitioner writes one ACE program record with the same claim scope, selected context slices, reference scheme and plane, evaluation window, parity frame, and input projections for both candidates. EvalService-7 first has the A.13 core for candidate evaluation, and A.15.1 independently admits CandidateEvalWork-42, which enacts ArchitectureCandidateEvaluationMethod-7 and occurs within ProductFamilyEvaluationService-7. This first-minute record expressly represents evaluator accountability under EvaluatorAssignment-3, an obtaining occurrence of directly declared species EvaluatorAssignment, so it also includes the separate F.6 relation through the same A.13 assignment. A Work-only ACE record would omit those assignment and attribution refs, and failed F.6 would leave CandidateEvalWork-42 intact. CandidateLatencyReading-42 and CandidateEvidenceScopeFinding-42 are typed results established through their result patterns. Those results can become inputs for [A.19.CPM](/generated/patterns/A.19.CPM) comparison or the next C.32 synthesis pass; neither the program record, Work, nor a result defines the criterion or decides the architecture.
This pattern concerns one architecture-characteristic eval-program record over declared criteria rows, Q-Bundle slots, candidates, bearers, or selected structures under a parity frame. It is a C.32.ACE-local record form, not a new U.* kind and not, by its program label, a U.Method, U.MethodDescription, U.WorkPlan, dated U.Work, or evaluation result. When measurement validity, comparison policy, a selection result, G.5 result declaration, publication, or architecture decision is current, use the definition and test for that claim.
Ordinary working move: choose the declared criteria rows, bind the claim scope, relevant context slices, reference scheme and plane, evaluation window, and input projections, and hold one parity frame for all variants. When evaluation actually occurs, recover each exact evaluator through A.13 and let A.15.1 independently admit the U.Work occurrence. Add evaluationWorkAttributionRefs only when the program or receiving use expressly represents precise assignment-bound attribution; missing or failed F.6 leaves the Work intact. Any A.6.1 operation application is an additional relation, not a substitute for the Method enacted by the Work. Return the typed results established through their result patterns as feedback for comparison or the next synthesis pass.
The first useful output is an ArchitectureCharacteristicEvalProgram@Project. This C.32.ACE-local working record states how one bounded architecture evaluation is to be framed over declared criteria. When a reusable way of evaluating is current, identify that separate U.Method under A.3.1; when a claim-bearing episteme describes that exact Method, test the same episteme for U.MethodDescription under A.3.2. A planned evaluation belongs to A.15.2, an actual dated evaluation to A.15.1, and each result to its direct measurement, comparison, evaluation, or assertion pattern. The record reads characteristics through rows, slots, candidates, or structures; it is not any of those neighboring objects:
For a first pass, fill the exact claim scope and selected context slices, reference scheme and plane, evaluation window and input projections, evaluated rows or Q-Bundle slots, evaluated candidates or structures, parity frame, eval purpose, intended eval operation, result form, receiving use, and refresh or retire condition. Add project-use refs only for a claimed project-local program; add Method, MethodDescription, actual evaluation Work, operation-application, and typed-result refs only when those separate objects are current.
Here @Project is a compatibility and retrieval cue only. It supplies no project entity, composite-work identity, context, authority, viewpoint, or parthood. A program local to one actual project names both the composite U.Work in projectWorkOccurrenceRef and the obtaining program-use relation in architectureEvalProgramProjectUseRelationRef; either field alone is insufficient. evalOperation states the intended operation family in the program record, not an actual run or application. Each evaluationWorkRef names one independently identified U.Work occurrence whose exact actual performers have A.13 cores and which A.15.1 admits independently. evaluationWorkAttributionRefs are optional and appear only when the record or receiving use expressly represents precise assignment-bound attribution; any present ref resolves through F.6 to the same obtaining A.13 assignment, and its absence or failure does not invalidate the Work ref. Any A.6.1 application binding and each typed result remain under the applicable patterns. A program, Method, MethodDescription, Work occurrence, operation application, assignment, attribution, and result never substitute for one another.
What goes wrong if C.32.ACE is missed: a project has architecture-characteristic rows but treats a test, monitor, dashboard, or source-side "fitness function" as the criterion or as the decision. The team may then reject useful losing variants as errors, optimize one indicator, or choose a candidate without fair comparison.
What C.32.ACE buys in practice: eval work is framed as typed evaluation over declared architecture criteria. A losing candidate can still add knowledge about the solution space, while an actual error remains a failure against an expectation that causes unplanned rework.
Adoption test: after using C.32.ACE, the record shows which variants were read under the same parity frame, what result form was produced, and which pattern for the next question may use that reading as feedback.
Not this pattern when the characteristic rows do not exist yet. Also not this pattern when the current work is measurement validity, composite-quality modeling, explicit comparison, set-returning selection, local choice, selected-set result declaration, actual publication, evidence, assurance, or project architecture decision.
Common exits by claim kind:
[C.32.HCS](/generated/patterns/C.32.HCS)and[C.32.ACS](/generated/patterns/C.32.ACS)before characteristic rows exist.[C.16](/generated/patterns/C.16)for measurement validity, readings, units, uncertainty, or comparability claims.[C.25](/generated/patterns/C.25)for Q-Bundles and composite quality families.[E.13](/generated/patterns/E.13)when an eval result or dashboard starts replacing the declared architecture concern.[C.32](/generated/patterns/C.32)for candidate synthesis,[C.32.MLAO](/generated/patterns/C.32.MLAO)for residual input, and[E.23](/generated/patterns/E.23)for repeated improvement feedback.[A.19.CPM](/generated/patterns/A.19.CPM)for explicit comparison,[A.19.SelectorMechanism](/generated/patterns/A.19.SelectorMechanism)for set-returning selection,[C.11](/generated/patterns/C.11)for local choice, and[G.5](/generated/patterns/G.5)for selected-set result declaration. For publication, use[E.17](/generated/patterns/E.17)for a source-backed face and source return and[E.24.PUB](/generated/patterns/E.24.PUB)for the publication occurrence and audience availability.[A.10](/generated/patterns/A.10)and[B.3](/generated/patterns/B.3)when evidence or assurance claims are being made.[C.32.PAD](/generated/patterns/C.32.PAD)for project decision.
Problem
Architecture synthesis is an optimization and learning activity under competing characteristics. It needs evals: deliberate measurement, simulation, benchmark, scenario, review, or monitoring runs that say how a current architecture or candidate architecture reads against declared criteria.
Testing for errors is a neighboring use. A test asks whether an expectation is violated. An eval asks how variants compare, how a candidate changes the trade-off front, which constraint is hit, or whether the next synthesis pass should open. A candidate that loses the eval is not automatically an error; it may be a deliberate probe that improves the architecture team's knowledge of the solution space.
Evolutionary-architecture sources often say "fitness function". In FPF that is source-side wording. The recoverable FPF object is an eval program over declared architecture-characteristic rows, Q-Bundle slots, candidate structures, and a parity frame. Some eval programs can be automated tests or monitors, but automation does not change the kind.
Forces
Solution
Create an architecture-characteristic eval program only after the evaluated criteria rows exist in C.32.ACS or a declared C.25 Q-Bundle slot.
Work in this order:
- Reference the evaluated ACS criteria set, evaluated rows, and any Q-Bundle slots.
- State the eval purpose: current characterization, candidate comparison, portfolio-frontier work, post-change impact measurement, monitoring, or trigger for the next synthesis pass.
- Name the candidates, bearers, and selected structures being evaluated.
- Establish one exact
U.ClaimScope, the relevant A.2.6U.ContextSlicemembership, effectiveU.ReferenceSchemeand reference plane, evaluation window, input projections, resource budget, units, admissible observation or evidence inputs, and missing-or-unknown policy. Record their parity requirement inparityFrameRef; the parity-frame record does not replace those bindings. - Choose eval scope: one criterion, coupled criteria, one Q-Bundle slice, a candidate portfolio, or a holistic use slice.
- Choose eval operations. Use measurement, simulation, benchmark, scenario walkthrough, monitor, review, or evidence audit according to the claim. Use
testonly when the intended operation checks an expectation or hard constraint. When evaluation actually occurs, recover each exact evaluator through A.13 and let A.15.1 independently admit theU.Workoccurrence and enacted Method. AddevaluationWorkAttributionRefsonly when the record or receiving use expressly represents precise assignment-bound attribution. Independently identify the relation or A.6.1 application binding that obtains and the typed result; the program record itself does not run. - Declare the result form. Examples include a reading, band, rank, dominance relation, trade-off front, qualitative state, or evidence finding; use the definition and test for the actual result kind.
- Name proxy risk and protected counter-characteristics before the eval result can drive work. Optimize only the cycle's chosen indicators; keep the remaining protected characteristics visible as guardrails or risk signals.
- State the receiving use:
C.32synthesis input,C.32.MLAOresidual input,E.23improvement feedback,A.19.CPMcomparison input,A.19.SelectorMechanismselection input,C.11choice input, input for a selected-set result declared underG.5, or architecture-decision input forC.32.PAD. For publication input, distinguishE.17source-backed face and source return from theE.24.PUBpublication occurrence and audience availability. - Refresh or retire the eval program when the evaluated row, C.32 candidate palette, bearer, selected structure, environment, parity frame, or source-currentness relation changes.
Stop condition. Stop C.32.ACE when the eval program names evaluated rows or Q-Bundle slots, evaluated candidates or structures, parity frame, eval purpose, eval operation, result form, receiving use, proxy risk, protected counter-characteristics, and refresh or retire condition.
Lowering condition. Keep the result as an eval result only while the evaluated rows, evaluated candidates or structures, parity frame, eval operation, result form, and receiving use still match the work being done. Lower the result to report-only when missing data, proxy risk, or parity-frame mismatch prevents synthesis, comparison, selection, selected-set result declaration, actual publication, choice, evidence, assurance, or decision use. Retire the eval program when its evaluated row, bearer, selected structure, environment, source-currentness relation, or receiving use no longer belongs to the current architecture work. Use C.32.ACS when the criteria row is missing or wrong, C.16 when measurement validity is current, C.25 when the evaluated item is composite, and the named pattern for the next question when a stronger downstream claim is current.
Worked slices
Latency candidate. A service candidate promises latency under 100 ms and an eval reads 240 ms. If the 100 ms band is a hard constraint, the candidate is inadmissible for this cycle. If the project is still exploring a trade-off front, the candidate is a losing variant with useful evidence about resource placement, interface burden, or control separation. Treat it as an error only when the project used that expectation to plan work and unplanned rework follows.
BIM digital twin. A built-asset team compares architecture candidates that combine placement, schedule, use-phase, maintenance, and cost structures. ACE does not treat the number of dimensions as the evaluation. The practitioner defines a parity frame and evals the ACS rows declared for the project, such as access, source-return cost, observability, and maintenance reach, then records results with the parity-frame and result-form fields needed by A.19.CPM.
Method-family architecture. A review-Method family has ACS rows for evidence reuse and change reach. If source wording also says “role substitutability,” use E.10.ROLE and C.32.ACS to bind the exact recovered subject and predicate—such as substitutability among local system-role kinds under A.2.7, not among holders or assignments—before ACE evaluates it. A separate C.25 bundle covers teachability. ACE defines a batch evaluation over three Method variants. One variant loses on teachability but reveals a reusable evidence relation; C.32 may use it as a stepping stone.
AI-agent workflow. A model-supported workflow has candidates with different function graphs and tool boundaries. ACE evaluates latency, evidence refresh, policy controllability, and rollback under the same task set and evidence window. A benchmark score is not the architecture decision; it supplies one eval reading inside the parity frame.
Hospital escalation. A hospital escalation team has ACS rows for decision latency, accountability clarity, and evidence custody. Any source “role continuity” or “role-boundary” criterion first goes through E.10.ROLE and C.32.ACS, which binds the exact subject and predicate—such as continuity of assignment occurrences and their holder Systems, or a boundary among exact participant relations. ACE evaluates two recovered architecture variants under the same incident scenarios and handoff evidence window. The result can feed comparison or the next synthesis pass; staffing choice remains with the receiving decision pattern.
Kind and Receiving-Claim Boundary
Use C.32.ACE to construct the local architecture-characteristic eval-program record and to keep criterion, reusable evaluation Method, MethodDescription episteme, intended operation family, planned evaluation, actual dated evaluation Work, actual operation application, typed result, comparison input, selection input, and decision input distinct. The local record admits no new U-kind. Use A.3.1, A.3.2, A.15.2, A.15.1, and A.6.1 for their respective objects and relations; use the pattern that defines and tests each actual result. C.32.ACE does not define starter characteristic selection, ACS scale-row construction, measurement validity, Q-Bundle normal form, candidate synthesis, comparison policy, final selection, local choice, G.5 selected-set result declaration, publication, or an architecture decision. When those claims are current, use C.32.HCS, C.32.ACS, C.16, C.25, C.32, A.19.CPM, A.19.SelectorMechanism, C.11, G.5, or C.32.PAD as applicable. For publication, use E.17 for a source-backed publication face and return to source and E.24.PUB for the publication occurrence, form, carrier, audience, bounded use, and availability.
Conformance requirements
Common failures and repairs
Consequences
Rationale
An architecture-characteristic eval program is the missing middle object between criteria rows and architecture selection. It answers "how did these candidates or structures read under this parity frame?" It does not answer "what is the criterion?", "is the measurement valid outside this use?", or "which architecture must be chosen?"
The pattern is architecture-specific because it evaluates selected structures and architecture characteristics. It stays holon-grounded because the same eval form can apply to admitted holons such as systems, organizations-as-systems, built assets, epistemes, work occurrences, disciplines, AI-agent setups, and C.36-recovered cultural-evolution cases. It can also evaluate Method-side, Work-side, evidence-side, local-kind, classification, or assignment structures after the described holon, the defining or constraining ClaimGraph located through the subject pattern, the bearer and predicate, and the scale rows are rebound. Unresolved “role” wording goes through E.10.ROLE; the pattern does not admit Methods, roles, practices, or cultures as holon kinds by label.
SoTA-Echoing
These rows document transfers from source practice into C.32.ACE. Keep a source citation only when the draft uses it to set or revise an eval-program field, result-use boundary, or refresh condition.
Source-currentness boundary. Use each source row only for the ACE eval-program field, result-use boundary, or refresh condition named in that row. Recheck the row when a named book edition, source presentation, FPF pattern for the next question, metric practice, or evolutionary-architecture practice changes the transferred move. If the project wants criteria-row admission, measurement validity, Q-Bundle structure, explicit comparison, selection, selected-set result declaration, actual publication, local choice, evidence, assurance, or decision use, leave ACE and open the pattern for the next question.
Relations
- Builds on:
C.32.HCS,C.32.ACS,C.16,C.16.P,C.25,A.2.6,A.19,E.13,E.22,E.23, andA.19.CPM; coordinates with A.3.1, A.3.2, A.15.2, A.15.1, and A.6.1 only for separately current Method, MethodDescription, planned Work, dated Work, or operation-application claims. - Receiving uses:
C.32.P2Sactual-structure feedback and next-synthesis repair,C.32candidate synthesis,C.32.MLAOresidual optimization,C.32.CONWAYcorrespondence frames,C.32.FAILrepair,A.19.CPMcomparison,A.19.SelectorMechanismselection,C.11local choice, selected-set result declaration underG.5, source-backed publication-face and source-return work underE.17, publication-occurrence and audience-availability work underE.24.PUB, and architecture-decision work forC.32.PAD. - Measurement boundary: Use
C.16when a reading, coordinate, unit, threshold, score, uncertainty, or cross-case comparability claim is made. - Structural-information boundary:
C.33,C.34, andC.35can supply captured structure, lost structure, preservation adequacy, generated-carrier context, or discovered-carrier context for an eval only afterC.32.ACS,C.16, orC.25has declared what is being evaluated. Use C.32.ACE for the eval-program frame, and accept each actual typed result under its own measurement, comparison, evaluation, or assertion definition and test.C.33,C.34, andC.35do not define eval programs. - Q-Bundle boundary: Use
C.25when the evaluated item is a composite quality family. - Test boundary: Use
testonly as an eval operation for a declared expectation or hard constraint. Error recognition and architecture-synthesis repair useC.32.FAIL; non-architecture defects use the local defect-subject pattern. - Decision boundary: An evaluation framed by an ACE record may reference separately admitted readings, ranks, dominance relations, trade-off-front descriptions, and other typed results. When such a result is current, identify the admitted System, dated evaluation Work, applicable operation application, and the definition and test used for that exact measurement, comparison, evaluation, or assertion result. Such a result may serve as source material for an A.10 evidence relation when an evidence claim is current. Use
A.19.CPMfor explicit comparison,A.19.SelectorMechanismfor set-returning selection,C.11for local choice,G.5for selected-set result declaration, andC.32.PADfor a project architecture decision. When audience availability is current, useE.17for a source-backed publication face and return to source andE.24.PUBfor the publication occurrence, form, carrier, audience, bounded use, and availability.
Footer marker
C.32.ACE closes when the eval program names evaluated criteria, evaluated candidates or structures, exact claim scope and selected context slices, effective reference scheme and plane, evaluation window and input projections, parity frame, eval purpose, scope, intended eval operation, trigger mode, result form, method refs, proxy risks, protected counter-characteristics, receiving use, and refresh or retire condition. When actual evaluation is claimed, each exact evaluator has its A.13 core and evaluationWorkRefs name independently admitted A.15.1 Work. Optional evaluationWorkAttributionRefs appear only when the record or receiving use expressly represents precise assignment-bound attribution. Any separately obtaining operation application and typed result remain independently identified.
C.32.ACE:End
Architecture-Influence and Transformed-Architecture Correspondence
Type: Architectural subpattern under C.32 Status: Stable Normativity: Normative unless explicitly marked informative Tech-name:
Architecture-Influence and Transformed-Architecture CorrespondencePlain cue: compare an architecture that influences the change with the architecture being changed Lineage and search cue only: Transformer and Transformed Architecture Correspondence
Problem frame
Use this pattern when one architecture-side source — recovered as an exact described holon, selected U.Structure, and either an obtaining C.30 ArchitectureRelation or truthful modal ArchitectureClaim — or another independently typed Work arrangement, communication structure, constraint, or candidate-synthesis result influences the candidate architecture of a changed referent, and the practitioner must decide what to change on either side without mistaking influence for action.
Plain cue: compare an architecture that influences the change with the architecture being changed.
Primary working reader: an architect or architecture-responsible practitioner who must compare one independently typed influence source with the current or modal architecture content of the changed referent and prepare candidate changes without turning an ArchitectureRelation, selected structure, claim, or architecture-bearing holon into an actor.
Typical entry situations include:
- a desired product architecture cannot be produced and verified by the current manufacturing and certification arrangements;
- chosen service boundaries still force every delivery team to coordinate every release;
- a method family is proposed for changing documents, but the assigned review roles and evidence structure do not fit what the project must produce;
- an AI-agent toolchain is intended for Work on project products, but its control and evidence boundaries do not fit the changed product architecture; or
- the project needs a source-side, transformed-side, joint, or bounded-mismatch inverse-Conway candidate rather than another diagram of the desired target.
A clean-looking target architecture can still be unbuildable or unproducible, untestable, hard to maintain or evolve, or hard to certify. Existing production, communication, approval, control, evidence, and operating arrangements can constrain the candidate and shift coordination into shared releases, approvals, evidence reconciliation, or exception handling. Treat each such arrangement as an independently typed influence source and recover its direct influence relation when that relation is asserted; the source architecture does not act, and mirroring alone does not establish architecture adequacy.
Start with the domain action: a manufacturing system builds a product, a compiler compiles a program, a service team changes a service, a clinical team treats a patient, or an instructional system teaches a learner. Identify the changed referent first. Only then name an acting system, exact system-role assignment, and dated Work when those facts are current. Separately name the architecture or other source that influences the candidate and the exact relation by which it does so.
First-minute use slice. A product-family team wants independently replaceable field modules. It identifies the changed referent as ProductFamilyFieldModuleBoundary@2026Q3. The influence side is the obtaining C.30 ArchitectureRelation(ManufacturingCertificationSystem@Plant-A, BatchLineSharedEvidenceStructure@Current); the transformed side is the obtaining C.30 ArchitectureRelation(ProductFamily@Current, FieldModuleBoundaryStructure@Current). The exact holons and selected U.Structure participants remain visible, and any desired replacement structure stays only in a separate ArchitectureClaim. No direct architecture-influence kind or predicate has yet been recovered, so the team keeps the pairing as a provisional independent-change pressure with missing-governor. It prepares source-side, transformed-side, joint, and bounded-mismatch candidates without naming an acting system, system-role assignment, Work occurrence, or actual transformation. Those facts are added separately only if a later claim needs them.
The primary working object is a local candidate-synthesis frame. It can pair actual architecture sides through exact obtaining C.30 ArchitectureRelation refs or carry candidate, required, desired, or expected structure only through separately identified ArchitectureClaim refs. When one exact architecture-influence or correspondence relation already obtains between two actual architecture sides, C.32.CONWAY is also the pattern for one reusable ArchitectureInfluenceTransformedArchitectureCorrespondenceRow@Context episteme about that exact occurrence. The frame, row, architecture relations, claims, selected structures, changing system, Work, actual transformation, changed referent, candidate palette, and any network that later cites the row remain different objects.
What goes wrong if this pattern is missed: an architecture, organization chart, method family, toolchain, communication structure, or network record is called the transformer and silently receives agency, a system-role kind or assignment, Work, or participation in the change. Or the reverse happens: real performer and Work facts disappear behind a vague claim that one architecture shaped another.
What this buys in practice: the practitioner can prepare architecture candidates while preserving four independent questions—what changed, who acted or performed Work, which sources influenced the candidate, and which exact architecture pair the current correspondence row concerns.
Ordinary working move:
- name the changed referent and, only when actual change is claimed, the independently admitted
U.Transformation; keep every actor-side or Work-to-change relation separate; - name exact acting and performance facts only when current;
- name each influence source with its kind and direct influence relation;
- for an exact reusable row, select one pair of obtaining C.30
ArchitectureRelationoccurrences and keep each holon and selected-structure participant visible; when either side is only candidate, required, desired, or expected, keep the pair in the frame with its exactArchitectureClaiminstead; - prepare source-side change, transformed-side change, joint change, or bounded mismatch candidates.
Adoption test: a reader can tell which exact case passes, which does not, what the practitioner changes next, and whether the result is only local synthesis material or a reusable exact pair row.
Not this pattern when the current work is only bounded-change identification, system-role assignment or Work attribution, module-interface repair, mathematical structural similarity, local choice, or an architecture decision. Use the subject pattern and return here only when one pair of an influence-source architecture and a transformed architecture changes candidate synthesis.
Common exits by claim kind:
A.3.4orA.3.4.Pfor the bounded change and changed referent.A.12for acting-side externalization,A.13for exact actual-performer recovery,A.15.1for independent dated-Work admission and distributed-performer forms,A.2.1for an exact assignment occurrence when separately claimed,F.6for a laterperformedUnderAssignment(W, RA)relation only when precise assignment-bound attribution is expressly consumed, and the pattern that defines any direct actor-side or Work-to-change relation needed by the current use. F.6's holder projection only supports equality comparison with the already recovered performer; it identifies neither assignment nor performer.A.6.Mfor module-interface repair.C.32.ACSfor current architecture-characteristic criteria rows andC.25for any composite Q-Bundle and exact slot used by the trade-off.C.29and the project-selected structural-equivalence pattern for structural similarity.A.19.CPMfor explicit comparison andA.19.SelectorMechanismfor set-returning selection.G.5for selected-set result declaration;E.17for a source-backed publication face and source return;E.24.PUBfor the publication occurrence and audience availability;C.18andC.19for archive, front, or pool-treatment policy.C.11for fixed local choice andC.32.PADfor a project architecture decision.
The first useful output is ArchitectureInfluenceTransformedArchitectureCorrespondenceFrame@Project. It is a working record for candidate synthesis, not an acting entity, exact relation occurrence, architecture decision, or structural-equivalence claim.
For a first pass, fill only the synthesis question, intended correspondence use, ClaimScope when it changes the claim, independently identified changed referent, source-side and transformed-side exact holon and selected-structure refs, and either an obtaining C.30 ArchitectureRelation ref or a truthful modal ArchitectureClaim ref for each side. Add architecture-characteristic criteria refs or plain provisional heads, applicable candidate-form heads, evidence and the evolution window, and the next pattern. Assert an influence row only when its direct relation is current and both architecture sides are obtaining C.30 occurrences; otherwise keep one explicit provisional pressure in provisionalArchitectureCharacteristicHeads[] and its exact return. The first-minute case above can be filled as follows:
This sparse frame asserts no influence occurrence and no exact pair row. The four candidate refs are first-pass heads, not comparison-ready configurations. Add acting-system, exact system-role-assignment, dated-Work, exact-pair-row, C.29, network, publication, comparison-ready gain, loss, and preservation, and any additional source-return fields only when the corresponding claim becomes current; adding them refines this frame without changing its changed referent, architecture pair, or provisional pressure. The complete extension schema is:
Project-local use keeps two separate fields. @Project remains a compatibility and retrieval cue only. If the frame is used in one actual project, projectWorkOccurrenceRef names the exact composite U.Work and architectureCorrespondenceFrameProjectUseRelationRef names the direct relation by which that Work uses the frame. The frame, synthesis Work, candidates, architecture relations, claims, selected structures, and project Work remain distinct. An ArchitectureRelation ref is affirmative only for an independently obtaining C.30 occurrence; candidate, required, desired, or expected architecture content stays in an ArchitectureClaim and cannot enter an exact pair row as though it already obtained.
TransformerTransformedArchitectureCorrespondenceFrame@Project and the former title “Transformer and Transformed Architecture Correspondence” are lineage and search cues only. They do not name the current Tech object, make any named value an actor, or establish an acting-system, system-role-kind, assignment, Work, or participation fact.
Problem
Architecture influence and action often occur in the same story but are not the same fact. A manufacturing architecture can constrain a product candidate while a manufacturing system performs production Work. A communication structure can influence service boundaries while people or teams perform change Work only through their admitted exact U.System identities. A method description can influence a work-product architecture without being a worker. A toolchain architecture can constrain project-task candidates while an admitted execution system acts.
The old transformer and transformed wording hid these differences. It could leave the changed referent implicit, treat an architecture bearer as the performer, omit the exact system-role assignment and dated Work, or call a source influential without a direct relation. It could also stretch one local architecture pair into a whole recursive transformation-flow network.
C.32.CONWAY repairs the problem by keeping the changed referent, actor and performance facts, influence-source facts, and one exact architecture pair separately recoverable. Conway and inverse-Conway practice then supplies candidate pressure, not a universal relation and not evidence that any source acted.
Forces
Solution
Build the local synthesis frame first. Admit a relation kind only through the applicable E.24-family admission pattern and direct settlement. Use that pattern's predicate and applicability to test the current pair. If current facts or constituting history satisfy the predicate affirmatively, one world-side occurrence obtains and the row may cite its exact identity. If the predicate is false, no exact pair row is asserted. If the current facts do not decide it, keep the correspondence synthesis-local and name the missing grounding or information-sufficiency boundary. Use missing-governor only when no direct relation kind and predicate govern the intended pair and use.
Keep acting, influence, and correspondence facts separate
- Name the domain action and changed referent. Identify
changedReferentRefindependently. AddactualTransformationRefonly when A.3.4 independently admits one bounded change of that same continuing referent; keep actor-side and Work-to-change relations under their subject patterns. Architecture influence identifies none of those facts. - Add acting and performance facts only when claimed. Every precise actual performer is one exact
U.Systemrecovered through A.13. Claimed performance requires one exact datedU.Workindependently admitted through A.15.1 and the exact actor-side or Work-to-change relation needed by the claim. Add an obtaining occurrence of a directly admittedU.SystemRoleAssignmentspecies under A.2.1 and F.6performedUnderAssignment(W, RA)only when this frame or its receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; then compareSwithRA.HolderSystemSlot. F.6 identifies neither assignment nor performer, and missing or failed F.6 leaves the Work intact. Use A.15.1CC-A15.1-17when several systems jointly perform the top-level Work or when the use instead needs a parent Work with separately performed child occurrences. - Name every influence source by kind. Architecture, selected structure, Work, communication, constraint, and candidate-synthesis results retain their kinds and direct influence relations. Influence alone supplies no system identity, system-role kind or assignment, Work, performer status, changed-referent identity, or transformation participation.
- Select one architecture pair. For an exact row, name one obtaining influence-source C.30
ArchitectureRelationand one obtaining transformed-side C.30ArchitectureRelation, with each exact holon and selected-U.Structureparticipant. Their architecture-bearing holons may differ from every acting system. Record equality only when independent actor and architecture-bearer facts establish it. If either side is only candidate, required, desired, or expected, keep its exactArchitectureClaimand the pair in the synthesis frame; do not assert an exact pair row. - Map only structures and characteristics that change the candidate. Name the source-side selected structure, transformed-side selected structure, expected gain, known loss, evolution window, pattern for the next question, and source-return condition. For each affected characteristic, reference only the few current
C.32.ACScriteria rows and any declaredC.25Q-Bundle slots that make this trade-off real. - Prepare four candidate forms. Change the influence-source side, change the transformed architecture, change both, or keep a bounded mismatch with an explicit cost and reopen trigger.
- Use C.29 only for structural-similarity claims. A correspondence row does not establish homomorphism, equivalence, or architecture adequacy.
- Stop at the next governed claim. Send comparison, selection, publication, choice, decision, evidence, assurance, gate, Work, or organization-governance claims to their direct patterns.
Exact reusable architecture-pair row
The row is a U.Episteme about one already obtaining direct influence or correspondence relation whose exact participants include the two obtaining C.30 architecture-relation occurrences required by this use. Because those occurrences fill participant positions of another relation, each is explicitly individuated under A.6.REL for this receiving use. The row neither creates the influence occurrence nor mints a universal Conway relation. Each C.30 occurrence keeps its exact holon and selected-U.Structure participants; the influence occurrence keeps its identity under its direct relation pattern and A.6.REL. This row only describes them for the current correspondence use. entityOfConcernRef, its kind, its governor, both C.30 occurrences and their participant pairs, and the changed referent are required. If the practitioner has only a useful local compound correspondence claim, or either architecture side is modal rather than obtaining, keep it in the frame for candidate synthesis. Assert the row only after the admitted influence relation kind's direct predicate is applicable and current facts satisfy it affirmatively. If the predicate is false, assert no row; if facts are unresolved, keep the frame and name that boundary; if the kind or predicate is absent, return missing-governor. None of these branches permits inferring a relation from two architecture claims, structures, diagrams, or names.
Qualified network reading
The same exact pair row may appear in architectureCorrespondenceRowRefs[] of several TransformationFlowStructureNetworkRecord@Context values while its pair, relation occurrence, evolution window, correspondence use, and claim scope remain current. Each citation contributes only one qualified architecture reading. The row's optional singular networkCrossFlowRelationRowRef, when present, qualifies only the exact current record edition named by that locator; it does not qualify the row's citations from other records. No citation makes the pair row the network, adds a member, or satisfies the network's exact cross-flow-relation discriminator.
Set networkCrossFlowRelationRowRef only when the pair row's exact influence occurrence and architecture-relation participants are independently grounded in member-flow positions and the locator's transformationFlowStructureNetworkRecordRef names the same exact current record whose architectureCorrespondenceRowRefs[] citation this mapping is intended to qualify. Resolve that record first, then require exactly one crossFlowRelationRow to match the occurrence and complete ordered endpoint-binding identity. That row must preserve the same kind, governor, participant order, endpoints, and bindings as this correspondence row. Zero or several matches, a different record, or a stale record edition leaves the locator unresolved. Do not reuse one locator to qualify another record's citation. A record citation alone infers none of those facts.
Acting-system identity, system-role assignment, F.6 attribution, Work, actual transformation, actor-side or Work-to-change relation, influence relation, and network cross-flow relation remain separately governed even when one case cites all of them.
Candidate moves and repair rows
Plain text begins with the domain action—builds, assembles, repairs, configures, treats, teaches, compiles, or evaluates. It then names the acting system and Work only when those facts are current. In a separate sentence it says which architecture or other source influences which candidate through which exact relation. Creator, creation, producer, transformer architecture, and uses remain ordinary cues, not universal technical labels.
Choose only pressures that change the candidate or protect against a concrete loss. Every affectedArchitectureCharacteristicRefs[] value in an exact pair row or comparison-ready candidate must resolve to a current C.32.ACS criteria row; when the pressure is one slot of a composite quality family, also resolve the declared C.25 Q-Bundle and that exact slot. If those governed objects do not yet exist, put plain heads such as independent change, substitutability, evidence reuse, latency, coupling or cohesion, coordination load, and source-return cost only in the local frame's provisionalArchitectureCharacteristicHeads[]; never place them in affectedArchitectureCharacteristicRefs[]. These heads are discovery cues, not a universal catalogue and not criteria refs. Use C.32.ACS or C.25 before making a stronger comparison, selection, or decision claim.
Stop condition. A first-pass frame may stop when it names the changed referent, separately typed source and transformed architectures, one selected structure on each side, either governed affected-characteristic refs or visibly provisional heads with their exact return, the applicable candidate-form heads, and the next subject pattern. Every acting, performance, or influence fact that is asserted must already have its direct basis. Before a candidate enters comparison or reliance, complete its source-side change, transformed-side change, expected gain, known loss, evolution window, pattern for the next question, source-return condition, and stop. An exact pair row additionally requires its direct relation predicate to be satisfied and its obtaining occurrence to be identified. A provisional pressure stays in correspondenceClaims[] with the exact reason visible: missing governor, unresolved grounding or information sufficiency, or a false predicate.
Lowering condition. Lower an exact row to synthesis-local correspondence material when its influence occurrence, either C.30 architecture-relation occurrence or participant pair, changed referent, evolution window, or receiving use is missing or stale. Retire a candidate when its source-side change, transformed-side change, bounded mismatch, or known loss no longer belongs to the declared evolution window. Use A.3.4 or E.18 when the actual transformation, changed referent, or flow relation is not recovered; to A.12, A.2.1, A.15.1, and F.6 when the issue is acting side, assignment, Work, or attribution; and to C.29 when the current claim is structural similarity or preservation.
Worked Correspondence Cases
The changed referent is independently identified as ProductFamilyFieldModuleBoundary@2026Q3. If the case also claims actual change, A.3.4 independently identifies FieldModuleBoundaryTransformation-17 : U.Transformation.
Before the candidate occurrence is called Work, A.13 recovers both collective performers for one shared scope, working situation, and window. The scope is ProductFamilyModuleChange@2026Q3; the situation is PlantAModuleTransitionArchitecturingSituation-17; and the window is 2026-07-14T09:00:00+03:00 through 2026-07-16T18:00:00+03:00. ManufacturingArchitectureTeam-A : U.System has boundary ManufacturingArchitectureTeamBoundary-A, comprising the rostered team members, their manufacturing-constraint decision channel, and the coordination interactions governed by ManufacturingArchitectureCoordinationMethod-v2. Its exact case-local action is ManufacturingBoundaryConstraintAction-17: select, revise, pause, or escalate manufacturing-feasibility constraints on the field-module boundary. It acts toward BatchFeasibleModuleBoundaryObjective-17 under the current batch-line capability, shared-evidence, and batch-exception conditions. CertificationArchitectureTeam-A : U.System has the distinct boundary CertificationArchitectureTeamBoundary-A, comprising its rostered members, certification-evidence decision channel, and the coordination interactions governed by CertificationArchitectureCoordinationMethod-v2. Its exact action is CertificationEvidenceConstraintAction-17: select, revise, pause, or escalate the certification-evidence obligations attached to the same boundary. It acts under CertificationEvidenceContinuityNorm-17, which requires every recommended boundary continuation to retain traceable applicable evidence and requires a hold when a material evidence gap remains. Its relevant conditions are the applicable certification obligations, current evidence links, and open evidence gaps. Neither System boundary includes the product family, either C.30 architecture-relation occurrence, the role-kind descriptions, or the assignment occurrences; neither action is yet called Work.
PlantArchitecturingSystemRoleKindDomain contains two exact local agential system-role kinds with independent membership criteria. ManufacturingArchitectureSystemRole requires the stable work-facing contribution of manufacturing-feasibility constraint judgment and goal-directed, condition-sensitive regulation toward BatchFeasibleModuleBoundaryObjective-17: the holder must select among admissible boundary continuations and revise, pause, or escalate its judgment when batch-line capability or exception evidence changes. CertificationArchitectureSystemRole requires the stable work-facing contribution of certification-evidence constraint judgment and corresponding regulation under CertificationEvidenceContinuityNorm-17: the holder must select among admissible evidence continuations and revise, pause, or escalate when an obligation or evidence gap changes. ManufacturingConstraintDecisionTrace-17 shows the manufacturing team comparing two admissible continuations, revising one constraint after new batch-exception evidence, and pausing the unsupported continuation. CertificationEvidenceDecisionTrace-17 shows the certification team revising the evidence obligation after an applicability change and holding the unsupported continuation pending a missing trace. A.10 evidence-use claims connect those traces and the respective boundary and coordination records to the two criteria. On that basis Plant-A separately classifies ManufacturingArchitectureTeam-A under ManufacturingArchitectureSystemRole and CertificationArchitectureTeam-A under CertificationArchitectureSystemRole. The evidence and classifications are independent of the candidate Work and of either assignment. No Grade, autonomy result, characteristic profile, or stronger assurance claim is consumed here.
The two-participant assignment kind PlantArchitecturingWorkAssignment is declared under U.SystemRoleAssignment. Its HolderSystemSlot admits a U.System; its local AssignedSystemRoleKindSlot uses PlantArchitecturingSystemRoleKindDomain; and its predicate says that, for the declared scope, situation, and interval, the holder is selected to supply the contribution defined by the assigned kind to the Plant-A transition-architecturing action. ManufacturingArchitectureAssignment-17 assigns ManufacturingArchitectureSystemRole to ManufacturingArchitectureTeam-A; CertificationArchitectureAssignment-17 assigns CertificationArchitectureSystemRole to CertificationArchitectureTeam-A. Both occurrences obtain with their declared holder and assigned-kind values, all species-specific predicates satisfied, and maximal uninterrupted predicate-true intervals covering the full stated window. These are the same obtaining assignments later consumed by F.6.
Only after both A.13 cores are established does A.15.1 independently admit ModuleTransitionArchitecturingWork-17 : U.Work. The independently grounded joint performance history records the two actions above as one top-level occurrence; the Work runs from 2026-07-14T09:00:00+03:00 to 2026-07-16T18:00:00+03:00 and enacts ModuleTransitionArchitecturingMethod-v3. A locally declared relation places that Work within ProductFamilyEngineeringSystem-A for the stated engineering-system boundary and Work interval. The independently admitted ProductFamilyEngineeringSystem-A : U.System is the second participant of that relation. Neither assignment nor an F.6 conclusion is an A.15.1 admission premise.
F.6 then records that ModuleTransitionArchitecturingWork-17 was performed under each of the same obtaining assignments established in the A.13 cores. The direct case facts link the exact Work to both assignment occurrences; holder equality holds for ManufacturingArchitectureTeam-A and CertificationArchitectureTeam-A, and both assignment intervals cover the Work. The Plant-A relation ArchitecturingWorkChangesModuleBoundary separately states that this Work brings about FieldModuleBoundaryTransformation-17.
This is the A.15.1 CC-A15.1-17 joint-performer form. Neither a lead assignment nor the architecture pair substitutes for either performer. Taxonomy and scheme epistemes may help interpret an assertion, but they are not assignment participants.
ProductDevelopmentNetworkRecord-2026Q3 may cite BatchEvidence-to-FieldModules-Row-17 once in architectureCorrespondenceRowRefs[]. That citation contributes one reading of the exact two C.30 architecture-relation occurrences. The pair row remains an episteme, not the TransformationFlowStructureNetwork, not one of its members, and not a cross-flow relation. Its optional networkCrossFlowRelationRowRef stays absent unless this same influence occurrence is independently grounded at exact member-flow positions and the composite E.18.NET locator resolves exactly one matching row in that same current record edition.
Network-qualified reading.
A product-development TFS and a production-system-change TFS participate in one selected E.18.NET-conforming network. A current architecture pair row about manufacturing-architecture influence may be cited by the network record alongside a separately grounded obtaining production or project occurrence. If the pair row also carries networkCrossFlowRelationRowRef, that locator names this same exact current record edition and resolves exactly one matching row; it qualifies no citation from another record. The pair row remains one reading of one exact architecture pair. It is neither the network nor proof that the architecture-influence occurrence is the cross-flow occurrence.
Near miss. A diagram places a factory architecture beside a product architecture and labels the arrow “shapes”. No direct relation kind and predicate govern that pair and use. The frame may retain the pair as synthesis-local pressure, but the exact row and network cross-flow mapping remain absent with missing-governor; the diagram does not create an occurrence.
Correspondence Failure Modes
Conformance Checklist
Common Repair Cues
Consequences
Rationale
Architectures do not act. Systems perform dated Work under exact system-role assignments when performance is claimed. Architectures, selected structures, Work arrangements, communication structures, constraints, and candidate-synthesis results can nevertheless influence which transformed architecture is feasible. C.32.CONWAY is useful precisely because it relates those facts without merging them.
The exact pair row gives one obtaining architecture-influence or correspondence occurrence a reusable episteme. The larger frame remains useful when a project has enough information to prepare candidates but not enough to assert that exact row. This preserves practical forward motion while keeping the exact relation status visible: missing governor, unresolved grounding, false predicate, or satisfied affirmative case.
The four candidate forms remain: change the influence-source side, change the transformed architecture, change both, or keep a bounded mismatch. The split between actor facts and influence facts changes their grounding, not their constructive purpose.
SoTA-Echoing
These rows document transfers from source practice into C.32.CONWAY. Each row states which field, repair row, or boundary the draft sets or revises from the source. The source family supports architecture practice; it does not decide actor identity or make a relation obtain.
Source-currentness boundary. Recheck a row when the changed referent, acting and performance facts, influence source or relation, architecture pair, selected structures, evolution window, source practice, or pattern for the next question changes. If the source no longer supports the selected local pressure, lower it to background lineage; do not preserve a technical claim by name alone.
Relations
- Builds on:
C.32for candidate architecture synthesis;C.30for exact described holons, obtainingArchitectureRelationoccurrences, selectedU.Structureparticipants, and modalArchitectureClaimcontent;A.3.4andA.3.4.Pfor the continuing changed referent and actual bounded transformation;A.12for acting-side externalization;A.13for exact actual-performer recovery;A.15.1for independent dated-Work admission and distributed-performer forms;A.2.1for assignment occurrence identity when separately represented;F.6for a laterperformedUnderAssignment(W, RA)relation only when precise assignment-bound attribution is consumed; direct subject relation patterns for actor-side, Work-to-change, and influence occurrences;A.6.RELwhen this episteme consumes occurrence identity;E.18for one TFS; andE.18.NETfor network identity and exact cross-member relations. F.6's holder projection only compares equality with the already recovered performer. - Uses:
C.32.ACSfor current architecture-characteristic criteria rows;C.25for composite Q-Bundles and their declared slots;C.32.MLAOfor a cross-scope residual;C.32.FAILfor a correspondence repair failure;C.29when structural similarity, preservation, mapping, or equivalence is claimed; andA.6.P.WMRandA.6.RCDwhen a required direct relation cannot be recovered. - Patterns for the next questions:
A.19.CPMfor explicit comparison,A.19.SelectorMechanismfor set-returning selection,G.5for selected-set result declaration,E.17for a source-backed publication face and source return,E.24.PUBfor the publication occurrence and audience availability,C.18andC.19for archive, front, or pool treatment,C.11for fixed local choice,C.32.PADfor architecture decisions,A.10for evidence,B.3for assurance,A.20orA.21for gate or release claims, and the direct method, Work, or organization-governance patterns when those claims are current. - Network boundary: an
ArchitectureInfluenceTransformedArchitectureCorrespondenceRow@Contextmay be cited as one qualified reading inarchitectureCorrespondenceRowRefs[]; it is not the network and does not satisfy an E.18.NET cross-flow relation without the separately grounded obtaining occurrence and endpoint bindings. Its optional singular row locator qualifies only the exact current citing record it names. - P2S docking:
C.32.P2Smay use C.32.CONWAY when a problem-to-structure flow needs one exact architecture-influence/transformed-architecture pair. It does not infer performer or influence facts from the flow card. - Boundary: C.32.CONWAY governs correspondence framing and one exact reusable architecture-pair episteme inside candidate synthesis. It does not govern actor identity, Work occurrence, organization redesign, authority, evidence sufficiency, assurance, gate passage, release, structural-equivalence theory, final architecture decision, or transformation-flow-network identity.
Footer marker
C.32.CONWAY governs candidate synthesis where one exact architecture or other typed source influences a transformed-architecture candidate through a governed relation. It keeps the changed referent, acting and performance facts, influence-source facts, one architecture pair, and any larger network separately recoverable.
C.32.CONWAY:End
Multilevel Architecture Residual Optimization
Type: Architectural subpattern under C.32 Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when a practitioner has a recoverable cross-scope or interlevel architecture residual and needs candidate architecture changes that reduce that residual under a declared evolution window.
Primary working reader: an architect or architecture-responsible practitioner who has already recovered a residual and must prepare candidate changes without calling a local improvement a whole-holon optimum.
Typical entry phrases:
First-minute use slice. A regulated product-family team has used [C.30.ILC](/generated/patterns/C.30.ILC) to name a residual: local product variants are quicker to ship, but certification evidence grows at the family scope. Using C.32.MLAO, the practitioner frames three residual-reducing candidate changes: add evidence scope, narrow interface grammar, or accept a bounded exception with a reopen trigger. Each candidate states the residual it reduces and the new burden it creates. The team now has explicit inputs for [A.19.CPM](/generated/patterns/A.19.CPM), [C.11](/generated/patterns/C.11), [A.19.SelectorMechanism](/generated/patterns/A.19.SelectorMechanism), or [G.5](/generated/patterns/G.5) when comparison, local choice, selection, or selected-set result declaration is current.
The primary EntityOfConcern is a residual-reducing candidate frame for one grounded architecture question. In plain working terms, the frame asks where a local architecture improvement moved the cost and which candidate can reduce that moved cost without hiding its new burden. The described holon can be a system, organization-as-system, discipline, AI-agent setup, built asset, episteme, work occurrence, or another admitted holon kind. Recover source labels such as practice, culture, tradition, style, or method before architecture use. Route role through [E.10.ROLE](/generated/patterns/E.10.ROLE): it may resolve to a local system-role kind, an assignment occurrence, a participant position in a direct relation, a function claim, an organization or representation position, or ordinary wording. Carry only the recovered object or relation, never a generic role-side structure. Candidate Systems, assignments, Methods, plans, and structures remain modal content until their own facts obtain; a publication family appears only under its applicable pattern. Use [E.17](/generated/patterns/E.17) for a source-backed publication face and source return and [E.24.PUB](/generated/patterns/E.24.PUB) for the publication occurrence and audience availability. C.32.MLAO is not a universal optimizer, adequacy claim, selector, decision, assurance argument, publication pattern, or software-system-only pattern.
What goes wrong if C.32.MLAO is missed: local success is called whole-holon architecture success, or an optimization phrase hides the residual that shifted to another declared holon-level ref or declared scope ref.
What C.32.MLAO buys in practice: the practitioner can prepare residual-reducing architecture candidates for later comparison by naming residual reduced, new burden created, affected scope, preserved structure, lost structure, and source-return condition.
Ordinary working move: name where the local improvement moved the cost, name the selected structure and scope that now carry the residual, then prepare candidate changes that reduce that residual while making the new burden explicit.
Adoption test: after using C.32.MLAO, a reader can see the residual reduced, the new burden, the affected scope, the preserved structure, the lost structure, and the evolution-window stop condition for each candidate.
Use C.32.MLAO only after residual triage. Do not use it to recover the residual itself, justify a mathematical lens, compare or select candidates, choose locally, declare a selected-set result, publish it to an audience, or decide the project architecture.
Common exits by claim kind:
[C.30.ILC](/generated/patterns/C.30.ILC)when the residual is not recoverable yet.[C.32.ACS](/generated/patterns/C.32.ACS)when architecture-characteristic criteria rows are missing.[C.32.ACE](/generated/patterns/C.32.ACE)when eval programs or eval results are the current claim.[C.29](/generated/patterns/C.29)when mathematical-lens use is being claimed.[A.19.CPM](/generated/patterns/A.19.CPM)for explicit comparison,[A.19.SelectorMechanism](/generated/patterns/A.19.SelectorMechanism)for set-returning selection,[C.11](/generated/patterns/C.11)for local choice, and[G.5](/generated/patterns/G.5)for selected-set result declaration.[C.18](/generated/patterns/C.18)and[C.19](/generated/patterns/C.19)for archive, front, pool treatment, or stepping-stone retention.[C.30.AD](/generated/patterns/C.30.AD)for architecture-description work,[E.17](/generated/patterns/E.17)for a source-backed publication face and source return, and[E.24.PUB](/generated/patterns/E.24.PUB)for the publication occurrence and audience availability.[C.32.PAD](/generated/patterns/C.32.PAD)for project decision.
The first useful output is MultilevelArchitectureResidualOptimizationFrame@Project. The frame is a working record for residual-reducing candidate framing. It records residual movement and candidate burdens; it is not a universal optimizer, scalar optimum, C.29 lens result, or architecture decision:
For a first pass, fill only the described holon, optimization question and objective basis, residual-triage ref, affected level or scope refs, selected structures, residual-bearing loci, criteria rows, ClaimScope when needed, evolution window, residual-reducing candidates with residual reduced and new burden, pattern for the next question, and stop condition. Add front, archive, NQD, OEE, C.29 lens, ideality, scale-amenability, function-bearer, and architecture-influence-correspondence refs only when that support is current for the candidate being framed.
Here @Project is a compatibility and retrieval cue only. It establishes no project entity, composite-work identity, context, authority, viewpoint, or parthood. When the frame is genuinely used in one actual project, projectWorkOccurrenceRef identifies the exact composite U.Work and residualOptimizationFrameProjectUseRelationRef identifies the direct relation by which that work uses the frame. The frame, the residual-reducing synthesis work, the candidate architectures, and the project work remain distinct.
Problem
Many architecture problems are residual problems. A local module boundary improves one team and creates integration exceptions elsewhere. A control relation improves response and creates audit or timing burden. A platform improves reuse and creates evidence decay. A method family speeds authoring and harms transfer.
The tempting shortcut is to call the local improvement optimized. C.32.MLAO blocks that shortcut by asking: where did the residual shift, which selected structure carries it, and which candidate change reduces it enough to be worth its new burden?
Forces
Solution
Build a residual-reducing frame around one recoverable residual. The frame is not a universal optimization target and not a scalar optimization result.
Work in eight steps:
- Start from a
C.30.ILC-compatible residual triage. - Name the affected declared holon-level refs or declared scope refs and the selected structures that carry the residual.
- Name the architecture-characteristic criteria rows and any Q-Bundle slots that make the residual worth reducing.
- Create or reference a C.32 candidate palette.
- For each candidate, state the residual it reduces, the selected structure changed, and the criteria rows affected.
- State the new burden, loss, exception, or source-return load created by that candidate.
- Record the evolution window and any support that only keeps candidate plurality or directionality alive, such as NQD, OEE, an archive or front, stepping-stone retention, ideality, or BLP.
- Stop at the frame, or name the pattern for the next question when a later claim is current: use
A.19.CPMfor explicit comparison,A.19.SelectorMechanismfor set-returning selection,G.5for selected-set result declaration,C.11for local choice,C.32.PADfor an architecture decision,C.30.ADfor architecture-description work, andC.29for mathematical-lens use. For publication, useE.17for a source-backed face and return to source, thenE.24.PUBfor the actual occurrence, form, carrier, audience, bounded use, and availability.
Admit a residual-reducing candidate only when it answers the working questions: which declared holon-level ref or declared scope ref is affected, which selected structure changes, which architecture-characteristic row or Q-Bundle slot is at stake, what residual is reduced, what structure is preserved or lost, and what new burden appears.
Comparison-input boundary. C.32.MLAO prepares comparison inputs; it does not run the comparison or choose a candidate. Its output rows are candidate records with residual reduced, new burden, selected structures, preserved structure, lost structure, source-return condition, and optional C.29 lens-output references.
Those references are diagnostic inputs only.
Admitted profiles and a ComparatorSpec belong to the receiving explicit-comparison pattern.
If the current claim is explicit comparison, use A.19.CPM with admitted profiles and a declared ComparatorSpec. If the claim is local choice over an existing option set, use C.11. If the claim is set-returning selection, use A.19.SelectorMechanism. If the claim is selected-set result declaration, use G.5. For publication, use E.17 for a source-backed face and source return and E.24.PUB for the publication occurrence and audience availability.
Lens-output discipline. Graphs, fronts, residual vectors, DSMs, RG-like descriptions, and frustration language are C.29 lens outputs, structural descriptions, or diagnostic signals after their architecture use is typed. The real failure is proxy preference: a candidate is preferred because the output looks better while selected structures, lost structure, architecture characteristics, and pattern for the next question remain unnamed. The repair is to interpret the output over selected structures and state what residual or loss it exposes; any comparison, selection, or choice claim then belongs to its pattern for the next question.
Method, culture, and episteme discipline. For a Method-family, culture, practice, or episteme case, first name the described holon, optimization question and use, selected structures, and the pattern that defines or constrains each load-bearing claim. If a publication family or publication face is in view, decide whether it is the described holon, a selected structure, an architecture description, or an MVPK face before using it. C.32.MLAO defines only the residual-reducing architecture candidate frame; use the applicable patterns for Method, Work, publication, evidence, ethical, and decision claims.
Dynamic candidate discipline. A preferred or retained candidate is bounded by an evolution window, source conditions, and the pattern for the next question that admitted the preference or retention. NQD, OEE, C.18, and C.19 can keep a front, archive, pool, or stepping stone visible; they do not select the architecture and they do not turn a front member into a durable optimum.
Ideality and BLP discipline. TRIZ ideality can suggest residual-reducing candidate changes: remove a support bearer, transfer a useful function onto an existing resource, or generalize a bearer so fewer selected structures carry more useful functions. BLP can prefer a more general scale-amenable bearer only inside its declared scale window and audit boundary. Both lines guide candidate generation; neither removes the need to state new burden, lost structure, and pattern for the next question.
Functional-bearer feasibility discipline. A residual-reducing candidate must name a bearer that could perform the function under the declared module, placement, resource, control, information, and evidence constraints. This is a design-time feasibility claim, not proof that the System, assignment, or Work already exists. An assignment supplies neither capability, functioning, function bearing, nor performance. If no feasible bearer can be proposed, add or change a candidate bearer, split the function, change placement, resource access, or control relations, reduce the demand, or mark the C.32 candidate unfit. Responsibility still needs an admitted direct predicate or the exact missing governor.
Architecture-influence and transformed-side discipline. When a residual is carried by one independently typed architecture-side source constraining architecture content for a changed referent, use C.32.CONWAY. For each actual side, keep the exact C.30 described holon, obtaining ArchitectureRelation, and selected U.Structure together; keep candidate, required, desired, or expected content in an exact C.30 ArchitectureClaim. Keep the changed referent and any actual A.3.4 U.Transformation separate. Then prepare residual-reducing candidates that change the influence-source side, the transformed side, both sides, or a bounded mismatch as comparison inputs or downstream candidate alternatives. Influence, transformation, flow, Work, and module-interface claims belong to their exact relation pattern, A.3.4, E.18, A.15, or A.6.M when current. Structural-similarity claims belong to C.29 only when they are current.
Level, stratification-term, and whole-reidentification discipline. If the case uses level, system level, holon level, layer, tier, or another stratification term, first use E.10.ARCH and C.30.STRAT unless the subject pattern and recovered neighborhood are already named by value. If the case uses BOSC, MHT, MET, MFT, emergence-family, boundary-crossing, or promotion-like wording, first use E.10 and B.2.P to recover the claim kind. Use B.2 only when a whole-reidentification question remains after the existing-whole explanation check; otherwise use the subject pattern for architecture, boundary, capability, function, measurement, publication, work, or lens claims.
Stop condition. Stop after the frame names residual, affected declared holon-level refs or declared scope refs, candidate changes, new burdens, preserved and lost structure, source-return conditions, and patterns for the next questions.
Lowering condition. Keep the frame as C.32.MLAO work only while the residual triage, affected level or scope refs, selected structures, criteria rows, evolution window, residual reduced, new burden, and pattern for the next question remain current. Lower a candidate to a diagnostic note when the residual is not recoverable, the selected structure is unknown or stale, the architecture characteristic is missing, the new burden is not named, or the pattern for the next question cannot use the row. Retire a candidate when its evolution window closes or a stronger residual triage replaces it. Use C.30.ILC when the residual itself is missing, to C.32.ACS when criteria rows are missing, to C.32.ACE when eval results are needed but not current, to C.29 when the current claim is a mathematical-lens claim, and to A.19.CPM, A.19.SelectorMechanism, C.11, G.5, or C.32.PAD when the downstream claim is current.
Worked Residual Cases
Residual And Trade-Off Failure Modes
Conformance Checklist
Common repair cues
Consequences
Rationale
C.30.ILC names cross-scope residuals and first architecture repair directions. C.32 creates candidate palettes. C.32.MLAO is needed when the constructive candidate work is specifically about reducing a residual across declared holon-level refs or declared scope refs.
The nontrivial work is to prepare candidate architecture changes for later comparison by naming residual reduced and burden created, not by using an optimizer phrase, scalar output, or locally improved structure as the candidate frame.
This subpattern also keeps multilevel source-side material usable as source cues without ontology transfer: multilevel learning, frustration, RG-like, DSM, and Pareto material may discipline the frame only after the affected declared holon-level refs or declared scope refs, selected structures, preserved structure, lost structure, comparison inputs, pattern for the next question, and stop condition are declared.
SoTA-Echoing
These rows document transfers from source practice into C.32.MLAO. Each row states which part of the residual-reducing frame the draft sets or revises from the source; none imports its source-domain ontology into FPF.
Source-currentness boundary. Use each source row only for the frame field, candidate-family row, discipline paragraph, or boundary named in that row. Recheck the row when a cited paper, book edition, DORA or Team Topologies page, FPF pattern for the next question, project residual, selected structure, criteria row, or evolution window changes. If the source no longer supports the concrete mutation, lower it to background lineage and keep the residual frame only when local residual triage, selected structures, criteria rows, new burden, and pattern for the next question remain recoverable.
Relations
- Builds on:
C.30.ILCfor residual triage,C.32for palettes,C.32.ACSfor architecture-characteristic criteria rows,C.32.ACEfor eval programs and eval results,C.29for mathematical-lens use when claimed,A.19.CPMfor explicit comparison,A.19.SelectorMechanismfor set-returning selection,C.11for local choice over an existing option set,G.5for selected-set result declaration,C.19.1for scale-amenability preference claims, andC.31orC.31.ASAPfor characteristic or scale-preference claims. - Uses:
E.10.ARCHandC.30.STRATwhen stratification terms hide the recovered neighborhood;E.10andB.2.Pwhen BOSC, emergence-family, MHT, MET, MFT, boundary-crossing, or promotion-like wording hides the claim kind;B.2when the candidate creates, reidentifies, splits, joins, or changes the relevant whole after existing-whole explanations are insufficient;C.32.CONWAYwhen residual reduction requires co-synthesis of exact influence-source and transformed-side architecture content;A.6.M,C.30.LCA,C.30.TFS-REL, and method or work patterns when their structures are the affected selected structures. - Patterns for the next questions:
A.19.CPMfor explicit comparison,A.19.SelectorMechanismfor set-returning selection,G.5for selected-set result declaration,C.11for fixed local choice,C.30.ADfor architecture-description work,E.17for a source-backed publication face and source return,E.24.PUBfor the publication occurrence and audience availability, andC.32.PADfor project architecture decisions. - P2S docking:
C.32.P2Suses MLAO when cross-scope, interlevel, interlayer, or meta-holon residual pressure must become candidate-synthesis and repair content inside the wider architecturing flow. - Boundary: Use C.32.MLAO only for residual-reducing architecture candidate frames after residual triage. Use the applicable patterns for mathematical-lens adequacy, evidence, assurance, gate passage, ethical mediation, causal claim adequacy, work authorization, and final selection.
Footer marker
C.32.MLAO governs bounded residual-reducing architecture candidate frames. Upstream residual triage and downstream decision, gate, release, publication, or authority-relation claims use their own patterns.
C.32.MLAO:End
Practice Architecture Synthesis from Several Structures
Tech-name:
PracticeArchitectureSynthesisFromSeveralStructuresPlain-name: build one usable practice architecture from several structures that do not line up one-for-one Type: Method-description pattern underC.32Status: Candidate Normativity: Normative unless marked informative
Problem frame
Use this pattern when several accounts describe one professional practice through different structures—for example Methods, performed or planned Work, subjects, descriptions or models, capabilities or providers, and cultural change—and those structures do not line up one-for-one. Use it only when a current decision needs one coherent practice-architecture answer across them.
The primary working reader is an architect, methodologist, practice designer, or domain-framework author who has already found useful source material but cannot safely copy its table, stack, lifecycle, or diagram as the practice architecture.
First useful move. Say whether the practice is obtaining or possible-future. In plain terms: is representative Work actually being performed, or is the practice still being designed? Then write the architecture question in one sentence and list only the structures that can change its answer.
What goes wrong if missed. A source layout is mistaken for the practice. A list becomes levels, a procedure becomes a hierarchy, simultaneous contributions become a sequence, a model becomes the thing modeled, or a future design acquires fictitious performed Work. A local repair may also look successful only because its unresolved burden moved to another structure or scope.
What this buys in practice. The reader gets a short, usable account of the practice, the selected structures and relations, their correspondences, the main conflict or moved burden, and the alternative that changes the current decision. The account can remain ordinary prose; a table or symbolic form is optional assurance.
Not this pattern when.
- Use the direct Method, Work, subject, description, capability, provider, or cultural-change pattern when only one such claim is unclear.
- Use base
C.32when the need is a palette of architecture candidates for one already grounded architecture question, rather than one coherent practice-architecture answer from several non-isomorphic structures. - Use
C.30.ILCandC.32.MLAOwhen an already recovered cross-scope conflict or residual is the main subject. - Do not use this pattern for one clear Method decomposition, one procedure order, a carrier index, a universal level stack, a mandatory record schema, domain filling, product-roster generation, or lifecycle design.
- This Method can supply evidence for a framework or project decision. It does not make that decision, establish a product, publish a description, or make a future practice actual.
The result is a practice-architecture synthesis for the named use. That phrase names an ordinary working description, not a new root kind. The practice, its Methods and Work, participating Systems, and its description remain different things.
Problem
Professional-practice sources commonly mix several useful accounts. One may show Method order, another Work participation, another organizational or technical subjects, another capabilities and providers, another descriptions or models, and another cultural generation or retention. Their rows can look aligned while referring to different wholes and relations.
Three failures follow.
- Layout substitution. The source's visible order or nesting is copied before the practitioner knows whether it means Method composition, Work order or overlap, subject composition, model grouping, provider dependency, cultural scale, or only chapter order.
- Present/future substitution. A possible-future practice is described as though a representative Work occurrence had already happened, so the architecture gains evidence it does not have.
- Local-success substitution. A candidate resolves one visible conflict but hides the residual or burden it moves elsewhere. The account reports the gain and loses the trade-off.
A fourth failure appears only in some uses: a live product-boundary question is reduced to one favored publication arrangement, or a product comparison is forced into an architecture question that does not concern product identity. Both errors confuse a conditional comparison with a universal step.
Forces
Solution
Build one readable synthesis from the relations supported by the current case. Keep the following eight actions in order as an attention aid, not as a claim that the practice itself is one eight-stage process.
Eight actions
- Choose a truthful entry. For an obtaining practice, anchor one independently admitted representative performed Work occurrence and the useful result at stake. For a possible-future practice, anchor an intended-use case,
WorkPlan, or another correctly typed prospective account; state what would realize it and how later representative Work would test it. Do not invent performed Work. - Name the subject and participants. State the subject under discussion (
EntityOfConcern) and the actual kinds of the participants before classifying rows or positions. A source word such as practice, layer, role, model, or provider does not settle those kinds. - Generate genuinely different organizations. Prepare alternatives that differ in a way that can change use or fail on different cases. When NQD is the current generation test, retain NQD-distinct candidates: their novelty is not a relabeling, their use-value preserves the declared constraints, and their diversity exposes different failure modes. Do not accept the source's first layout as the option set, and do not turn NQD into one scalar score.
- Recover each relation actually used. In ordinary words first, state whether the source claim concerns Method composition or order, Work parthood or overlap, a subject relation, description or model use, a capability or provider dependency, cultural dynamics, or another admitted relation. Use the pattern that defines or constrains that relation when the claim matters to the answer.
- Separate practice from description. Keep obtaining practice wholes and relations distinct from descriptions, models, views, and coarse-grained accounts. State their correspondence and the distinctions each description preserves or loses.
- Reidentify a whole when needed. Use
B.2when the previously identified Method, Work, System, Discipline, or selected structure cannot carry the current claim. Do not keep the old identity merely to preserve a neat stack. - Compare conflict and moved burden. Expose conflicts between candidate structures. For every apparent local repair, ask what residual, constraint, cost, evidence burden, delay, or loss moved to another structure or scope. Compare the alternatives against the named architecture question, not against visual tidiness.
- Keep deliberate and distributed change distinct. Separate a project's architecture choice or intervention from cultural generation, transmission, recognition, selection, rejection, retention, and loss. A project can influence those processes without controlling or proving them.
Short working result
Write the first result as a short account that another practitioner can use without decoding a private ontology. This outline is a writing aid, not a mandatory schema:
A compact table can support this account. Symbolic predicates are optional assurance and belong after the readable explanation. The result stops at architecture evidence; comparison, selection, decision, publication, evidence, assurance, or gate claims use their own patterns when those claims become current.
Conditional product-boundary comparison
Only when product identity is the current architecture question, compare these four genuinely different arrangements:
- one domain DPF;
- independently maintained sibling DPFs;
- direct use of FPF plus exact domain sources; and
- a proposed common applied DPF.
For each arrangement, state the recurring practitioner problem, first useful result, independently useful boundary, sources and maintenance burden, and what another arrangement would leave hidden or duplicate. These four are comparison forms, not a selected product roster. When product identity is not the question, do not force this comparison into the Method.
Stop, lower, and reopen
Stop when the short synthesis identifies the truthful entry, selected structures and relations, important correspondences and losses, at least one genuinely different alternative, the main conflict or moved burden, and the next use. Do not keep adding views that cannot change the decision.
Lower the claim when the subject, representative occurrence or prospective anchor, relation, evidence boundary, or alternative is not recoverable. Preserve the useful source cue and return to the direct pattern or source instead of completing the architecture by guesswork.
Reopen when representative Work contradicts the synthesis, a future practice becomes obtaining, a new structure changes the decision, a moved burden becomes material, a direct source changes, or the product-boundary question enters or leaves scope.
Archetypal Grounding
Tell. A five-minute social-dance occurrence sits inside a longer party. Preparation has a real first-then order, while movement regulation, figure performance, partner coordination, style-specific performance, and event participation can contribute during overlapping Work. A teaching diagram is a description; bodily and pair capabilities concern participating Systems; scene transmission and later style selection are cultural relations. The synthesis keeps these structures linked but not identical. A sequence-only stack loses simultaneity, while one culture-level stack loses the actual Work and subject relations.
Show — obtaining engineering practice. In a 90-minute power-converter integration run, model correction overlaps simulation, rig reconfiguration precedes closed-loop test, assurance overlaps later testing, and restoration of a simulation service overlaps the run without becoming part of the converter-integration Work. Plant and controller models are descriptions used in the Work, not the converter or the Work. The team compares a sequence-only account with a linked account of Method, Work, subjects, models, platform service, capability, and evidence. The linked account wins for this question because it preserves both the rig-change–then–test unfolding and the simultaneous contributions. If evidence assembly is moved to the platform, the synthesis records platform availability and traceability as a moved burden rather than declaring an unqualified gain.
Show again — possible-future Method. A five-day Method-adaptation sprint is obtaining Work, but the candidate Method it describes is not yet an obtaining practice. The team anchors the architecture in the intended project use, the incumbent Method used during the sprint, the candidate MethodDescription, and a planned representative trial. It compares candidate organizations of Method parts, tool and description support, provider capability, trial Work, and later repertoire maintenance. It states what would realize the candidate Method and what the trial must observe. It does not invent a past occurrence of the candidate Method. If the question is only how the project will use the candidate, the four product arrangements are omitted; if the question becomes where an independently maintained Method family belongs, that conditional comparison is opened explicitly.
Across the three cases, the same Method preserves a truthful entry, several non-isomorphic structures, exact relation claims, practice-description separation, whole reidentification, genuinely different alternatives, moved burdens, and the boundary between deliberate project change and distributed cultural change. The domain details remain different.
Bias-Annotation
Scope: Limited to synthesizing one usable practice-architecture answer when several selected structures do not line up one-for-one. This is not a universal practice ontology, a required view set, a product-selection Method, or a complete architecting lifecycle.
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
The Method preserves useful differences among Method, Work, subject, description, capability/provider, and cultural structures while producing one decision-ready account. It prevents source tables, lifecycle diagrams, and models from silently becoming practice ontology. It also makes future-practice claims and moved burdens inspectable.
The cost is a small amount of relation recovery and alternative construction before a clean diagram can be accepted. Some attractive source organizations will remain unresolved or will be retained only as descriptions. That cost is proportional: the first result is short, structures that cannot change the decision are omitted, and formal assurance is optional.
Receiving domains still supply their own Methods, institutions, evidence, constraints, providers, cases, and maintenance conditions. Reuse of this Method does not move those fillings into FPF.
Rationale
The eight actions follow the dependencies of a truthful synthesis. The entry must distinguish obtaining from prospective before evidence is interpreted. Subjects and participant kinds must be known before a source layout is classified. Alternatives must exist before the first layout can be challenged. Relations and description correspondences then make the alternatives comparable. Whole reidentification prevents a neat name from carrying the wrong claim. Conflict and moved-burden comparison expose the real trade-off, and the final deliberate/distributed distinction prevents one project from being mistaken for cultural evolution.
The Method does not require all structures to fit one master diagram. Its common result is coherence through stated relations and correspondences, not visual isomorphism. This is why a short prose account can be the first useful result and why a matrix, graph, or formal model remains optional.
SoTA-Echoing
The sources below make complementary contributions; none is used as authority for the whole Method. The pattern composes only the bounded moves stated in the table, and the final row keeps current FPF distinctions authoritative.
Recheck these source uses when a newer applicable architecture-description standard, practice-architecture synthesis, work-system method, or multi-domain technique changes the practical move, or when unlike cases show that the eight actions no longer preserve a decision-relevant structure at proportional effort.
Relations
- Builds on:
A.3.1for Method identity,B.1.5for Method order/composition and Work enactment distinctions,A.15.1andF.6for actual performed Work and attribution when claimed,B.2for whole reidentification,C.30andC.30.ADfor architecture and architecture-description distinctions, andC.36for cultural-change relations. - Coordinates with: base
C.32for general architecture candidate synthesis;C.17andC.18only when NQD generation, novelty/diversity, archive, or front claims are current;C.30.STRATbefore accepting level, layer, tier, stack, or similar source wording; andC.30.ILCplusC.32.MLAOwhen a conflict, residual, or moved burden needs its own treatment. - Provides a result to:
E.4.PFADwhen several practice structures change a framework-architecture answer;E.4.DPFwhen those structures change DPF identity, scope, pattern organization, first use, or use of named results;E.4.DPF.DAwhen package adequacy needs the resulting two-way sequence-versus-simultaneity evidence; andE.23.CDIonly when target-practice architecture must be recovered or compared before capability development. - Does not replace: the direct domain sources and Methods,
E.4product-family decisions, explicit comparison or selection, project architecture decision,E.24.PUBpublication occurrence and availability, evidence or assurance, or the currentness and refresh patterns.
Footer marker
Use C.32.MWA to build one readable practice-architecture synthesis from several structures without turning a source layout, description, future design, local repair, or project choice into more than the current case supports.
C.32.MWA:End
Architecture Failure Recognition and Repair
Type: Architectural subpattern under C.32 Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when a practitioner sees a recurring architecture-synthesis failure and needs to turn that warning into the smallest repair action over a named architecture object before evidence, assurance, selection, or decision claims are current.
Primary working reader: an architect or architecture-responsible practitioner who sees a warning sign during synthesis and needs the first architecture repair action, not a larger risk catalogue.
Typical entry cues:
First-minute use slice. A team calls an ML model a module in a safety-relevant product architecture. Using C.32.FAIL, the practitioner does not add another warning name. The practitioner names the architecture object under stress: a candidate module-interface relation for the described product holon. The blocked overread is: model file equals stable module. The first repair action is to recover interface behavior, admissible-use conditions, change policy, and evidence-decay boundary before using the model as a module. If a safety assurance claim is current, the case escalates only after that architecture repair is named.
The primary EntityOfConcern is one repair cue for one architecture object under stress. The cue is a working repair aid, not a risk register, assurance case, selection result, release argument, or decision object.
What goes wrong if C.32.FAIL is missed: failure language degenerates into a warning bank. The team can say what looks suspicious, but it cannot say which architecture object must be repaired or which pattern defines or constrains the next claim.
What C.32.FAIL buys in practice: a practitioner can convert a vague failure signal into one typed repair action, keep the repair near the selected structure, and stop before nearby decision, release, or governance claims expand the case.
Ordinary working move: convert the symptom into four fields: architecture object under stress, blocked overread, first repair action, and stop or escalation condition.
Adoption test: after using C.32.FAIL, a reader can see four things in the cue: the architecture object under stress, the blocked overread, the first repair action, and the pattern for the next question or stop condition.
Use another pattern when the current work is only lexical cleanup, evidence sufficiency, release, architecture description, MVPK publication face, comparison, selection, archive, front, selected-set result declaration, actual publication, local choice, or final architecture decision. Use C.32.FAIL only when the failure cue changes the first architecture repair action.
Common exits by claim kind:
[C.30.P](/generated/patterns/C.30.P),[A.6.F](/generated/patterns/A.6.F),[A.6.M](/generated/patterns/A.6.M),[C.31](/generated/patterns/C.31),[C.32](/generated/patterns/C.32),[C.32.MLAO](/generated/patterns/C.32.MLAO), and[C.32.CONWAY](/generated/patterns/C.32.CONWAY)for architecture or selected-structure repair.[A.19.CPM](/generated/patterns/A.19.CPM)for explicit comparison and[A.19.SelectorMechanism](/generated/patterns/A.19.SelectorMechanism)for set-returning selection.[C.18](/generated/patterns/C.18)and[C.19](/generated/patterns/C.19)for archive, front, pool-treatment, or retained-stepping-stone claims.[A.10](/generated/patterns/A.10)for evidence,[B.3](/generated/patterns/B.3)for assurance, and[A.20](/generated/patterns/A.20)or[A.21](/generated/patterns/A.21)for gate or release claims.[C.30.AD](/generated/patterns/C.30.AD)for architecture description,[E.17](/generated/patterns/E.17)for a source-backed publication face and source return, and[E.24.PUB](/generated/patterns/E.24.PUB)for the publication occurrence and audience availability.[G.5](/generated/patterns/G.5)for selected-set result declaration,[C.11](/generated/patterns/C.11)for local choice, and[C.32.PAD](/generated/patterns/C.32.PAD)for a project decision. For publication, keep the distinct E.17 and E.24.PUB uses just named.
The first useful output is ArchitectureRepairCue@Project. It is a working record for one repair action. It names the stressed architecture object and first repair; it is not a failure ontology, risk register, assurance case, release argument, selection result, or decision:
Here @Project is a compatibility and retrieval cue only. It establishes no project entity, composite-work identity, context, authority, viewpoint, or parthood. When the repair cue is genuinely used in one actual project, projectWorkOccurrenceRef identifies the exact composite U.Work and architectureRepairCueProjectUseRelationRef identifies the direct relation by which that exact project Work uses the cue. Any separately claimed repair Work and its own cue-use or work-to-change relation remain under their direct governors. The cue, the actual repair Work, the architecture object under stress, and the composite project Work remain distinct.
Problem
Architecture synthesis often fails before formal evidence or decision work starts. The defect is not only that a word is vague. The practical defect is that the architecture object under stress is missing or misread.
Most first-contact failures cluster into a few repair-entry families:
- a proposed bearer, module, platform, or universal substrate hides interface behavior, variation pressure, function bearing, evidence burden, or new coupling;
- a proxy result, generated artifact, architecture description, graph, dashboard, front member, or workshop favorite is used before the selected structures, losses, and pattern for the next question are named;
- one structure, function, system-role kind or assignment, responsibility, control relation, evidence relation, or Method step is improved while the synthesis frame loses the architecture characteristics and other structures that made the trade-off real;
- a current candidate is treated as a durable optimum, or ideality pressure deletes a bearer without naming the function still carried, the lost structure, and the new burden;
- an influence-source architecture and the transformed-side architecture content collapse into one claim instead of opening C.32.CONWAY and separating the changed referent, each obtaining C.30 architecture relation or modal
ArchitectureClaim, any asserted direct influence occurrence, and any separately current actor, assignment, Work, or actual transformation facts.
These cues are useful only when each one is converted into a repair shape: symptom, architecture object under stress, first repair action, and stop or pattern for the next question.
Use C.32.FAIL for that conversion. It does not mint a local ontology of failure kinds.
Forces
Solution
Convert the warning cue into an ArchitectureRepairCue@Project. Work in six steps:
- State the symptom in ordinary practitioner language.
- Name the described holon, architecture claim when one is current, concern, intended repair use, scope or qualification window when material, architecture object under stress, and failure evidence.
- State the blocked overread that would lead the team astray.
- Name the first subject pattern for the architecture object or lens relation.
- Propose the smallest repair action that changes architecture handling.
- State where to stop, or which neighboring pattern defines or constrains the next claim if another claim is already current.
Core repair families for first-draft use:
Admit a new repair family only when its row tells the practitioner what to repair first. A suspicious name alone is not enough; the row must name the architecture object under stress, the first repair action, and the stop or pattern for the next question.
Stop condition. Stop after the repair action, pattern for the next question, and source-return condition are named. Do not grow the cue into a risk register, evidence case, release argument, or final architecture choice.
Lowering condition. Keep the row as a C.32.FAIL repair cue only while the symptom, described holon, architecture object under stress, blocked overread, first subject pattern, repair action, stop condition, and escalation condition remain current. Lower the row to an observation when the architecture object is unknown, the repair action is missing, the first subject pattern is not named, or the symptom belongs only to evidence, assurance, release, description, publication, comparison, selection, choice, or decision work. Retire the cue when the repair action has been applied or the stressed architecture object is no longer current. Use A.6.P or E.10 when the case is only source-expression recovery, to C.32 when candidate repair is current, to C.32.MLAO or C.32.CONWAY when their residual or correspondence repair is current, and to the named pattern for the next question when a stronger downstream claim is current.
Worked Repair Cases
Tell. C.32.FAIL is a repair-entry pattern. It takes a recognizable warning cue and returns one typed repair action over a selected architecture object. It is useful only when the repair action changes architecture handling.
Show-A - Safety-relevant model-as-module. A model file is being treated as a module in a product architecture. The repair cue names the candidate module-interface relation, blocks the file-equals-module overread, and recovers interface behavior, admissible-use conditions, change policy, and evidence-decay boundary. Safety assurance follows only through its subject pattern.
Show-B - Product-family platform with exception growth. A platform promise reduces local delivery effort but grows evidence exceptions at the product-family scope. The repair cue names variation structure, substitution policy, and evidence scope as the architecture objects under stress. The first repair action is not to declare the platform adequate; it is to repair variation slots and bounded-exception rules, then open C.32.MLAO residual comparison if cross-scope burden is current.
Show-C - Responsibility change shifts coordination cost. A stream-aligned team improves local delivery flow, but release testing and evidence responsibility remain shared. The repair cue names the team or organization System, the coordination relation, and the module-interface and evidence structures under stress. A proposed responsibility retargeting names its direct predicate, the current and proposed participants, and the occurrence to replace; without that basis it returns missing-governor. Ordinary work organization, Method or plan structure, local kind, separate System-classification judgment, assignment, enactor relation, and actual Work network remain separate. C.32.CONWAY supplies only the architecture-influence synthesis frame or qualified pair row; it supplies none of those other facts.
Show-D - Generated architecture candidate. An agent system produces a high-scoring blueprint. The repair cue treats the blueprint as a source cue, recovers the selected-structure changes encoded in it, names preserved and lost structure, and rebuilds the candidate palette before G.5 selected-set result declaration, actual publication, or decision.
Show-E - Built-asset maintenance dashboard. A facility maintenance dashboard shows a dependency graph and freshness scores. The repair cue keeps the graph as a lens output, recovers the actual selected structures under stress in maintenance work and asset interfaces, and keeps timing or evidence claims with their subject patterns.
Show-F - Function with no feasible bearer. A searched AI workflow adds a verification function after model output, but the edge device has no resource margin and the cloud placement violates latency. The repair cue names the function-bearing gap, then opens C.32. Candidate repairs can, for example, add a local bearer, split verification into local and cloud steps, change deployment placement, reduce the demand, or reject the candidate for the current evolution window.
Repair-Entry Failure Modes
Conformance Checklist
Common repair cues
Consequences
Rationale
C.32 needs a failure-recognition subpattern because candidate architecture work repeatedly breaks at the repair-entry point. The useful work is not to collect more warnings. The useful work is to recover the architecture object under stress and make the next repair action reviewable.
The pattern stays intentionally small. It does not establish failure, make a score-based risk finding, select a candidate, or authorize a release. It gives practitioners a disciplined way to go from "something is wrong here" to "this architecture object needs this repair, and this neighboring pattern defines or constrains the next claim if it is current."
SoTA-Echoing
These rows document transfers from source practice into C.32.FAIL. Each row states which field, repair row, boundary, or receiving-pattern exit the draft sets or revises from the source. Do not keep a citation when the draft uses it only as decoration.
Source-currentness boundary. Use each source row only for the repair field, repair row, boundary, or receiving-pattern exit named in that row. Recheck the row when a cited standard, book edition, research result, DORA or Team Topologies page, model-practice source, FPF pattern for the next question, described holon, selected structure, or source cue changes. If the source no longer supports the repair, lower it to background lineage and keep the cue only when the architecture object under stress, blocked overread, repair action, stop condition, and pattern for the next question remain recoverable.
Relations
- Builds on:
C.32for candidate palette repair;C.32.CONWAYfor a synthesis frame or qualified pair connecting architecture influence with transformed-side architecture while keeping the changed referent, C.30 architecture relations or modal claims, direct influence occurrence, organization relations, local kinds, separate System-classification judgments, assignments, enactor relations, ordinary work or procedure organization, actual Work, direct responsibility relations, actual transformation, and any E.18.NET network distinct;C.30andC.30.ADfor architecture relation, claim, and description boundaries;C.30.ASVfor architecture structural views;C.31for module and interface architecture;C.32.MLAOfor cross-scope residual repairs;C.29for mathematical-lens use;E.17andE.24.PUBfor publication-face boundaries; andA.6.P,E.10, andE.10.ROLEfor source-expression and role-word recovery. - Coordinates with:
A.6.Fwhen function and architecture-characteristic wording is mixed;A.6.Mfor module-interface repair;C.19.1for a general scale-amenable bearer or Method; A.2/C.3 for a local system-role kind and any separate System-classification judgment; A.2.1 for an assignment species and occurrence; A.13 for every precise performer's core, A.15.1 for independent actual-Work admission, and F.6 only for current precise assignment-bound attribution; and the exact enactor, coordination, or responsibility predicate, or A.6.RCDmissing-governor, when that direct route is absent. UseE.10.ROLEonly for unresolved claim-bearing role wording. Ordinary work or procedure organization may remain ordinary. It also coordinates withA.10andB.3for evidence or assurance,A.20andA.21for gate or release,C.18andC.19for archive or pool treatment,C.27for temporal adequacy,E.18for transformation-flow structure,C.32.P2Sfor reopened carry-through,A.19.CPMfor comparison,A.19.SelectorMechanismfor set-returning selection,G.5for selected-set result declaration,E.17andE.24.PUBfor publication,C.11for local choice, andC.32.PADfor project architecture decisions. - Patterns for the next questions after the repair cue:
A.10for evidence claims,B.3for assurance claims,A.20orA.21for gate or release claims when those claims are being made,A.19.CPMfor explicit comparison,A.19.SelectorMechanismfor set-returning selection,G.5for selected-set result declaration,E.17for a source-backed publication face and source return,E.24.PUBfor the occurrence and audience availability,C.11for local choice, andC.32.PADfor project architecture decisions, only after the architecture repair cue has named the object under stress and the repair action. - Boundary: C.32.FAIL contains repair cues for architecture-synthesis failures. It does not decide final candidate selection, evidence sufficiency, assurance, gate passage, release, or an architecture decision.
Footer marker
C.32.FAIL governs conversion of a recognizable architecture-synthesis failure into one repair action over one architecture object under stress.
C.32.FAIL:End
Project Architecture Decision After Candidate Synthesis
Type: Architecture decision pattern under C.32 Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when a project has synthesized candidate architecture configurations and must make the project architecture decision that will guide later design, implementation, construction, operation, governance, or change work.
Primary working reader: an architect or architecture-responsible practitioner who has enough candidate synthesis, comparison input, and architecture-characteristic pressure to decide what architecture will be pursued now.
Typical entry phrases:
First-minute use slice. A product-family architect has a C.32 candidate palette with three module, placement, and evidence-structure variants. C.32.ACS names maintainability, substitutability, and evidence reuse as optimization indicators, and C.32.ACE has evaluated the candidates under one parity frame. Using C.32.PAD, the architect records the exact composite project work, selected configuration, affected selected structures, accepted loss in evidence reuse, method-use instruction for product teams, structures fixed by the decision, refinement left open, source-return condition, and reopen trigger. The result is not an ADR file yet; it is the architecture decision relation concerning that project work which an ADR or another publication form can describe.
The primary EntityOfConcern is ArchitectureDecisionRelation@Project: an architecture decision relation over one bounded architecture question with one exact composite project U.Work as a participant. It links that work, the decision subject, candidate basis, selected architecture option, affected structures, architecture characteristics, rationale, accepted losses, consequences, method and work expectations, publication projection, evidence or eval exits, and reopen conditions.
ArchitectureDecisionRelation@Project is not a new U.* kind. @Project is a compatibility and retrieval cue, not the source of project identity or scope. The relation is project-local only when projectWorkOccurrenceRef identifies the exact composite U.Work that participates in it. When another slot becomes load-bearing as an FPF object, recover the subject pattern for that object.
When this decision designates a project system-of-interest, projectSystemOfInterestRef? names only an independently admitted existing U.System. Before identity inception, keep the intended referent in intendedProjectSystemClaimRef? as U.WorkPlan, decision, system description, or other claim content. A local kind is named separately in systemOfInterestKindRef?, while systemOfInterestClassificationRef? cites an independently obtaining classification judgment; neither entails an assignment. A current assignment uses separate species and occurrence refs, and the occurrence's holder is that System. Route any source phrase such as SystemOfInterestRole through [E.10.ROLE](/generated/patterns/E.10.ROLE) before filling these fields. A taxonomy or scheme is not assignment content. Designation, kind, classification, assignment, Work, change, use facts, and the decision remain distinct. The decision neither establishes a compound project-selection truth nor repairs its missing constructor; when that one truth is required, retain every direct fact and record the A.15.6 result missing-substrate[project-selection-conjunction].
When the decision uses a transformation-flow network, transformationFlowStructureNetworkRef? names only an independently selected E.18.NET TransformationFlowStructureNetwork@Context <: U.Structure; projectNetworkSelectionResultRef? may cite the separate C.2.1 judgment about why that network answers the project question, and architectureTransformationFlowStructureRelationRef? cites C.30.TFS-REL when architecture use is current. A network record, a C.32.CONWAY frame or exact pair row, and this decision create no network member, cross-flow occurrence, architecture-influence occurrence, architecture relation, or other world-side fact.
What goes wrong if C.32.PAD is missed: a team writes an architecture record, diagram, shortlist, ranking, or local choice without a recoverable architecture decision relation to exact project work. Later workers cannot tell which architecture configuration is selected, which structures are affected, which method they must use, which losses were accepted, or when the decision must be reopened.
What C.32.PAD buys in practice: practitioners performing the project work can turn a candidate palette into one governed decision relation that is strong enough to guide work, publish an ADR-like record, support review, and reopen under architecture evolution.
Ordinary working move: recover the live decision question, cite the candidate basis, select the architecture option or bounded exception, record the trade-off over declared architecture characteristics, then bind the decision to method-use expectations, work split, source-return, and reopen conditions.
Adoption test: after using C.32.PAD, another practitioner can answer: what architecture option was selected, from which candidate basis, for which affected structures, under which architecture-characteristic trade-off, with which method and work consequences, and under which reopen condition.
Not this pattern when the current work is candidate synthesis, architecture-description adequacy, ADR publication projection, adequacy evaluation, evidence, assurance, gate passage, local choice, or performed work. Use the pattern for the next question named in Relations for those claims.
The first useful output is ArchitectureDecisionRelation@Project:
The filled ArchitectureDecisionRelation@Project is the decision result. Its selected option, affected structures, criteria and trade-offs, scope, window, consequences, and status make that result recoverable; a second generic result or context record would only duplicate it.
The field names in this first-output form are publication-friendly filled-reference fields. Durable relation positions must be expressible through [A.6.5](/generated/patterns/A.6.5) SlotSpecs: each position has a local SlotKind, an admitted ValueKind, and a by-value or concrete RefKind filling mode. A field name such as decisionSubjectRef is not a SlotKind, not a U-kind, and not an ADR heading; it is the filled-reference field by which this relation record points to the value governed by the slot-bearing relation.
When an instruction cites actual implementation Work, recover each exact actual performer through A.13 and let actualImplementationWorkRef name the U.Work occurrence independently admitted through A.15.1. Assignment species and occurrence fields remain optional neighboring claims. Add actualImplementationWorkAttributionRef only when the instruction or receiving use expressly represents precise assignment-bound attribution through the same obtaining A.13 assignment; missing or failed F.6 leaves the Work ref intact. The decision record creates none of these facts.
Problem
Architecture synthesis produces candidates; the Systems performing project Work still need a decision, while any local system-role kind, direct assignment species, authority, or responsibility claim remains a separate fact established through its own pattern. The decision is not the candidate palette, the declared selected-set result, its publication, the architecture description, or the ADR file. It is the architecture decision relation that identifies the composite project Work, says which architecture option is now pursued for it, and records what follows from that selection.
The problem is difficult because architecture decisions sit between structures and Methods. C.30 keeps an obtaining ArchitectureRelation with its holon and selected U.Structure separate from an ArchitectureClaim carrying candidate, required, desired, or expected content. A project architecture decision can tell intended developer Systems which Method description, architectural style, pattern use, or work boundary to follow so that later work aims to produce or preserve the intended structures. For example, "use the client-server style here" is a Method-use instruction whose intended result is a module and interaction structure of the described System. The decision relation must keep actual or modal structure content, intended Systems, local kinds, separate System-classification judgments, assignment requirements and current assignment occurrences, plans and commitments, permissions and authority, and actual Work as separate branches. Route unresolved role wording through E.10.ROLE. When C.32.CONWAY supplies an influence-source architecture or selected structure, that source remains non-agentive and does not become the performer.
The problem is also multilevel. The architecture decision may fix selected structures at one holon level while leaving lower-level refinement open. It must therefore say which structure is fixed, which refinement remains open, which source detail must remain recoverable, and which result can reopen the decision. If that boundary is missing, the decision becomes either empty advice or uncontrolled micro-management.
Finally, architecture decisions are evolutionary. They are made under current candidate knowledge, current characteristic criteria, current eval readings, and current organization or tool constraints. They should be explicit enough for present work and cheap enough to supersede when a better candidate, changed characteristic pressure, or architecture-influence/transformed-side fit changes.
C.32.PAD solves the post-synthesis decision problem by making the decision relation explicit before any ADR-like publication projection is written.
Forces
Solution
Create ArchitectureDecisionRelation@Project before writing an ADR-like publication record. Treat it as the architecture decision relation that includes the exact composite project U.Work and binds it to the candidate basis, selected architecture option, affected structures, architecture-characteristic trade-offs, rationale, consequences, method expectations, work split, and reopen conditions.
Work in this order:
- Name the composite project
U.Workparticipant and the decision subject: described holon, decision question, intended use, ClaimScope, decision window, and status. If the decision designates a project system-of-interest, cite the existingU.Systemor the pre-inception intended-system claim. Add a local kind only when it is current, add a separate System-classification judgment only when that judgment independently obtains, and add an assignment only through its separately declared A.2.1 species and obtaining occurrence whose holder is that System. RouteSystemOfInterestRolesource wording throughE.10.ROLE; establish every Work, change, and use fact through its own predicate and pattern. A decision designation proves no compound project-selection truth; returnmissing-substrate[project-selection-conjunction]when that stronger truth is required. - Cite the candidate basis. Use
C.32for the candidate palette,C.32.MLAOfor residual-reducing multilevel candidate frames,C.32.CONWAYwhen an influence-source architecture and transformed-side architecture content shaped the candidate, andC.32.FAILfor repaired candidate errors. Cite a C.32.CONWAY synthesis frame while either side is modal or the direct influence relation is unresolved; cite an exact pair row only for its already obtaining direct occurrence and two obtaining C.30 architecture-relation participants. - Cite comparison or selection input only when it exists. Use
A.19.CPMfor explicit comparison,A.19.SelectorMechanismfor set-returning selection,G.5for selected-set result declaration, andC.11for local choice. For publication, useE.17for a source-backed face and source return andE.24.PUBfor the publication occurrence and audience availability. - State the selected architecture option or bounded exception. Name the affected selected structures and the subject pattern for each structure claim.
- Record the architecture-characteristic trade-off. Use criteria rows from
C.32.ACS, eval results fromC.32.ACE, measurement support fromC.16, Q-Bundles fromC.25, modularity or scale support fromC.31, andC.29structural-information lens uses for compressed recoverable structure, accepted description loss, hidden dependency, and source-return. None of those lenses, measures, or bundles decides the architecture by itself. - Record rationale, rejected options, accepted losses, and consequences. A rejected option can remain useful as a stepping stone or archive item; do not turn it into a failure unless the receiving failure pattern is triggered.
- Bind the decision to architecture descriptions. Use
C.30.ADfor architecture-description adequacy andC.30.ASVfor selected-structure view adequacy. A diagram, model, file, or view can describe the decision basis; it does not become the decision relation. - Bind the decision to method-use instructions when the architect needs developers to use a method, pattern, style, toolchain step, or work practice so the described or transformed-side holon is intended to gain or preserve the named structure. Use
A.15,A.15.1,A.15.2,A.15.5,A.6.M,E.8,E.11.PUR, andC.24according to the live claim. - State the architecture-to-refinement boundary. Name selected structures fixed by the decision, refinement scopes left open, source-return conditions, readiness exits, and patterns for any later governance question. When the boundary depends on holon level, changed whole, or BOSC-triggered pressure, fill
holonTransitionOrBOSCTriggerRefs?throughB.2.Pclaim-kind recovery orB.2whole reidentification instead of leaving a generic level note. - Choose a publication projection only after the decision relation is clear. Use
C.32.ADRfor ADR-like projection,E.17for a source-backed publication face and source return, andE.24.PUBfor the publication occurrence and audience availability. - Add evidence, assurance, gate, and governance exits only when those claims are being made. Use
A.10,B.3,A.21, and the local governance pattern rather than adding those statuses to the decision relation by name. - Write reopen and supersession conditions. Reopen when the candidate basis changes, a protected architecture characteristic crosses its guardrail, an independently typed influence-source structure or arrangement no longer fits the transformed-side actual or modal architecture content, a stronger source changes the accepted loss, or the decision's method-use instruction proves unusable.
If one project question uses an E.18.NET network, first preserve that network's independent A.22/E.18.NET selection. A persistent project-network judgment stays in its C.2.1 result episteme under A.15.6, and architecture use docks through C.30.TFS-REL. A C.32.CONWAY exact pair row may be cited in architectureCorrespondenceRowRefs[] of a network record, but that citation is only a qualified reading: it adds no network member or cross-flow occurrence, and PAD repeats none of the network's member, relation, constraint, endpoint, or use-frame fields.
Decision readiness
A C.32.PAD decision is ready to draft when the current decision relation identifies the composite project U.Work participant and can cite at least one candidate basis, one affected selected structure, one architecture-characteristic trade-off or declared reason for no live trade-off, one expected work consequence, one reopen condition, and any triggered holonTransitionOrBOSCTriggerRefs? or structuralInformationLensUseRefs? needed to preserve source return. When system-of-interest local-kind, separate System-classification, assignment, architecture-influence, or network fields are present, the applicable A.15.6, A.2 and A.2.1, C.32.CONWAY, E.18.NET, and C.30.TFS-REL preconditions must already be satisfied or the reference remains absent.
If the candidate basis is absent, require C.32. If architecture-characteristic rows are absent, require C.32.ACS or C.25. If the decision only says "the metric is best", require C.32.ACE, C.16, or A.19.CPM before deciding. If the intended work method is not recoverable, require A.15. If an existing system, role assignment, project-network judgment, network selection, architecture use, or influence pair is unresolved, require its subject pattern and keep only the truthful designation, modal claim, candidate frame, or explicit stop in PAD.
Constructive architecture decision path
Some architecture decisions are constructive: they prescribe Methods that intended developer Systems are expected to use so that later work aims to produce or preserve intended structures. A decision may name intended Systems, local-kind requirements, separate classification requirements, assignment requirements, plans, commitments, permissions, or authority before any assignment or Work obtains. Admit that path only when the decision keeps those prospective facts separate and names:
- the obtaining architecture relation and selected structure, or the exact modal
ArchitectureClaim, to be produced or preserved; - the method description, architectural style, pattern use, or work practice to be used;
- the intended System when known; an optional local kind and an independently optional System-classification judgment; any current assignment through separate species and obtaining-occurrence refs whose holder is that System; and any merely intended assignment as plan, policy, or decision content rather than an occurrence;
- any responsibility or authority relation only when its admitted direct predicate, actual participants, applicability, and identity obtain; otherwise record the exact A.6.RCD missing governor instead of calling the system-role kind or assignment responsible;
- the expected structure effect on the described or transformed-side holon, kept modal until its direct C.30 architecture predicate obtains;
- the work-planning boundary and readiness or gate exit;
- the source-return condition and reopen trigger.
This keeps architecture decisions connected to work without treating the decision description, ADR file, method description, selected network, influence-source structure, or performed Work as the architecture, performer, or proof that the expected structure effect obtains.
Minimum sufficient relation and slot-change impact
A small complete PAD instance can be this short:
When a filled field changes, repair the smallest declaration or claim record that carries the changed content:
Archetypal Grounding
Software service architecture. A platform team compares synchronous service calls, event-carried integration, and a bounded shared kernel. The selected option is event-carried integration for order events with a bounded exception for payment authorization. C.32.PAD records affected module and information structures, latency and substitutability trade-offs, the method-use instruction for service teams, the event-schema source-return condition, and the reopen trigger when payment volume crosses the declared eval band.
Manufacturing fixture architecture. A production architect compares a dedicated fixture per product, a universal fixture with adapters, and a mixed cell layout. The selected option uses a universal fixture only for products inside a scale window. C.32.PAD records module, placement, maintenance, and evidence-structure effects, the accepted setup-time loss, the method instruction for cell design, and the trigger for returning to candidate synthesis when adapter complexity exceeds the guardrail.
Project system-of-interest and network. A plant-modernization decision designates already admitted PumpUnit-3 : U.System as the project system-of-interest and cites exact composite PumpUpgradeWork-7. The designation does not create a project container or the compound truth that the project selected the pump. The source label SystemOfInterestRole is recovered through E.10.ROLE. Exact local kind SystemOfInterestSystemRole is cited through systemOfInterestKindRef, and the separate judgment classifying PumpUnit-3 under it is cited through systemOfInterestClassificationRef. PumpQualificationSystemOfInterestAssignment is cited as the directly declared species; PumpUnit-3-QualificationAssignment-7 is cited separately as its obtaining occurrence with PumpUnit-3 as holder. A taxonomy or scheme is not an assignment participant, and neither kind, classification, nor assignment establishes Work, responsibility, or authority. Each Work-to-pump, Work-to-change, evaluation, production, or use fact keeps its own subject pattern. An independently selected E.18.NET network may connect production-system change, pump change, and qualification flows for the named project question. PAD cites that exact network, the optional C.2.1 selection judgment, and the C.30.TFS-REL architecture-use trace; it does not recreate network identity or infer cross-flow relations from a record or C.32.CONWAY pair row. If the decision needs the still-unsupported compound project-selection truth, the case returns missing-substrate[project-selection-conjunction].
Method-family architecture. The team applies a review Method to compare specialized review contributions, peer rotation, and tool-supported triage. E.10.ROLE first recovers any local kind, assignment, direct-relation position, function claim, or ordinary label hidden by role wording. The selected option uses peer rotation plus a tool-supported evidence handoff. C.32.PAD records those exact recovered relations, Method, evidence, and information structures, the trade-off between teachability and evidence custody, and the refinement scope left open for local checklists.
Architecture influence and transformed-side fit. An automation project changes both a toolchain and the product it is used to change. C.32.CONWAY supplies a synthesis frame or, only after direct settlement, an exact architecture-influence pair row over the obtaining source-side and transformed-side C.30 architecture relations. C.32.PAD records which toolchain structure is decision-relevant, which product-side structure is selected or intended, which Systems are intended, which assignment requirements and Methods are planned, and which fit change reopens the decision. A current assignment or actual Work appears only when it independently obtains. The toolchain architecture and pair row neither act nor prove performance or actual transformation.
Digital-twin structural information loss. A built-asset team publishes a 6D-style digital-twin decision view for construction planning. The view intentionally hides supplier-agreement and temporary-work structures. C.32.PAD records the selected building, placement, schedule, cost, operation, and evidence structures that the decision uses; C.29 records which hidden structures remain recoverable and which accepted loss reopens the decision. The view count, file, and model do not become the decision authority.
Bias-Annotation
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
Rationale
C.32.PAD exists because candidate synthesis and architecture decision are different work moments. C.32 builds the option space; PAD commits the project to a current architecture option or bounded exception and records the method and work consequences of that commitment.
The pattern keeps four layers apart: an obtaining C.30 ArchitectureRelation over one architecture-bearing holon and selected U.Structure; any ArchitectureClaim that states actual, negative, unresolved, candidate, required, desired, or expected content about the holon, relation, or structure; ArchitectureDecisionRelation@Project, which connects composite project Work to the selected option and declared work consequences; and ArchitectureDecisionDescription@Project, whose project use is established through the C.30.AD relation and which can be published in ADR-like or other forms. Optional system-of-interest, local-kind, System-classification, assignment-species, assignment-occurrence, architecture-influence, and network references retain their A.15.6, A.2 and A.2.1, C.32.CONWAY, E.18.NET, and C.30.TFS-REL subject patterns. This lets FPF reuse its existing architecture, description, Method, work, evidence, assurance, measurement, publication, project, and network patterns instead of creating a separate architecture-decision ontology for those facts.
The pattern is architecture-reusable across holon kinds, not because every decision target is itself a holon kind. The same decision relation can apply to admitted holons such as systems, organizations-as-systems, built assets, AI-agent setups, epistemes, work occurrences, or disciplines. It can also concern Method, evidence, or an exact object or relation recovered from role wording, provided those values stay under A.3.1, E.10.ROLE, A.2.7, A.10, and A.15 rather than being admitted as holons by label.
SoTA-Echoing
These rows document transfers from source practice into C.32.PAD. Keep a source citation only when it changes a decision-relation field, boundary, or reopen condition.
Source-currentness boundary. Recheck a source row when an ADR template, architecture-description standard, evolutionary-architecture practice, FPF pattern, or project governance practice changes the decision field, method-work boundary, or reopen condition that PAD uses. Reopen only the affected optional docks if A.15.6 changes the actual or intended System or project-selection stop, A.2 or A.2.1 changes the role or assignment boundary, C.32.CONWAY changes its frame or qualified-pair threshold, or E.18.NET or C.30.TFS-REL changes network identity or architecture-use requirements.
Relations
- Builds on:
A.15.6,A.2,A.2.1,C.30,C.30.ASV,C.30.AD,C.30.TFS-REL,E.18.NET,C.32.P2S,C.32,C.32.MLAO,C.32.ACS,C.32.ACE,C.32.CONWAY,C.32.FAIL,C.25,C.16,C.29,C.31, andC.31.ASAP. - Comparison and selection boundary: Use
A.19.CPMfor comparison,A.19.SelectorMechanismfor set-returning selection,G.5for selected-set result declaration, andC.11for local choice. When audience availability is current, useE.17for a source-backed publication face and return to source andE.24.PUBfor the publication occurrence, form, carrier, audience, bounded use, and availability. PAD records the architecture decision relation with its exact composite project-work participant after those inputs are sufficient. - Description boundary:
C.30.ADandC.30.ASVgovern architecture-description and selected-structure view adequacy. PAD may cite those descriptions but does not replace them. - Structural-information boundary:
C.33,C.34, andC.35may support PAD only for captured structure, lost structure, preservation adequacy, generated-carrier typing, or discovered-carrier typing used by the decision relation. Use PAD for the decision relation, rationale, consequences, accepted losses, Method consequences, Work consequences, source return, repair, and supersession claims. - Publication boundary: Use
C.32.ADRto project anArchitectureDecisionDescription@Projectinto ADR-like form,E.17for a source-backed publication face and source return, andE.24.PUBfor the publication occurrence and audience availability. - Adequacy boundary:
C.32.ADAevaluates a PAD decision relation, method docking, and publication projection for a declared use. - P2S docking: P2S reaches PAD only when implementation commitment is live; PAD records the decision relation and returns reopen conditions to P2S when actual structures, eval results, or source-return change the architecture question.
- Project system-of-interest boundary: Use
A.15.6for composite project Work, actual-versus-intended System designation, independent Work, change and use facts, project-network judgment, andmissing-substrate[project-selection-conjunction].E.10.ROLErecoversSystemOfInterestRolewording; useA.2andA.2.1separately for local kind, classification, and obtaining assignment. PAD cites those objects only when the architecture decision uses them and proves none of them. - Network and architecture-influence boundary: use
E.18.NETto identify the selected network, its members, obtaining cross-flow occurrences, constraints, endpoints, and use frame;C.30.TFS-RELdefines architecture use;C.32.CONWAYis the pattern for the synthesis frame and exact qualified pair row. PAD cites the smallest exact refs and never turns a record or row citation into network membership, a direct relation occurrence, actor identity, performance, or actual structure effect. - Method and work boundary:
A.15,A.15.1,A.15.2,A.15.5,E.8,E.11.PUR, andC.24govern method descriptions, work plans, readiness, pattern-use recommendations, and agentic tool-use work. - Evidence, assurance, and gate boundary:
A.10,B.3, andA.21govern evidence relations, assurance calculus, and gate profiles when those claims are current.
Footer marker
C.32.PAD closes when ArchitectureDecisionRelation@Project names the composite project U.Work, decision subject, candidate basis, selected architecture option or bounded exception, affected structures, architecture-characteristic trade-offs, accepted losses, rationale, consequences, architecture-description refs, Method-use and work-boundary expectations, source-return condition, triggered holon-transition or BOSC refs, triggered structural-information lens uses, publication projection exit, and reopen or supersession conditions. When the decision also cites a project system-of-interest, local kind, separate System-classification judgment, assignment, architecture-influence correspondence, or transformation-flow network, each ref resolves to its separately established object, every actual world-side relation is independently established, and the applicable A.15.6 project-selection stop and E.18.NET and C.30.TFS-REL non-duplication boundaries remain explicit.
C.32.PAD:End
Architecture Decision Record Projection
Type: Architecture publication pattern under C.32 Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when an ArchitectureDecisionRelation@Project or equivalent project architecture decision must be published as an ADR-like record, decision memo, trade-study record, certification rationale, or similar decision-description record.
Primary working reader: an architect or architecture-responsible practitioner preparing a decision record for developers, reviewers, maintainers, operators, certifiers, or future architects.
Typical entry phrases:
First-minute use slice. A platform architect has a C.32.PAD decision relation selecting event-carried integration with a bounded exception. Using C.32.ADR, the architect creates an ADR projection with section functions for problem frame, candidate options, decision outcome, rationale, consequences, method-use instruction, work split, confirmation eval, source-return links, and supersession. The file is short enough for developers to read, but it remains a publication projection of the decision description, not the decision relation and not the architecture itself.
The primary EntityOfConcern is ArchitectureDecisionRecordProjection@Project: a publication projection of ArchitectureDecisionDescription@Project into an ADR-like record or package. Select this pattern only when the work is to publish or package that decision description for a declared reader use; generic ADR advice that cannot be mapped to decision-section functions stays outside C.32.ADR.
ArchitectureDecisionRecordProjection@Project is not a new U.* kind and not a new root publication ontology. It is a project publication projection with filled section-function rows. Use [E.17](/generated/patterns/E.17) and [E.24.PUB](/generated/patterns/E.24.PUB) for publication-face and publication-use claims; use [C.32.PAD](/generated/patterns/C.32.PAD) for the decision relation.
What goes wrong if C.32.ADR is missed: the project either publishes a record-shaped text that hides the actual architecture decision, or it copies architecture descriptions, diagrams, and method material into a record without telling the reader what decision was made and what work must change.
What C.32.ADR buys in practice: a decision record can be small, readable, updateable, and still tied to candidate synthesis, selected structures, architecture characteristics, method-use instructions, work split, confirmation evals, and source-return.
Ordinary working move: start from a PAD decision relation, select the record's publication scope, map each necessary section to the decision content it carries, then publish only what the reader needs to use, check, or reopen the decision.
Adoption test: after using C.32.ADR, a future reader can recover the decision question, considered options, outcome, rationale, consequences, required method or work change, confirmation or eval path, source links, and supersession condition without mistaking the record for the architecture or the decision relation.
Not this pattern when the decision relation is not yet recoverable, the current work is architecture-description adequacy, the record is a general MVPK publication face, or the claim is evidence, assurance, gate passage, local choice, performed work, or pattern authoring. Use the pattern for the next question named in Relations.
The first useful output is ArchitectureDecisionRecordProjection@Project:
Here @Project is a compatibility and retrieval cue only. It does not make the projection a project, project work, or the architecture decision relation. When this record projection is genuinely local to one actual project, projectWorkOccurrenceRef identifies the exact composite U.Work, while architectureDecisionRecordProjectUseRelationRef identifies the direct relation by which the record is published for, relied on by, or otherwise used in that work under the corresponding subject pattern. The decision relation, its description, the publication projection, any publication occurrence, and the composite project work remain separately identifiable.
Problem
ADR practice is useful because it makes architectural decisions small enough to read and update. It is also easy to misuse. A record can become a substitute for the decision relation, a loose essay about architecture, a copied architecture description, or a method prescription with no recoverable target structure.
C.32.ADR treats ADR as a publication projection. The project decision relation belongs to C.32.PAD. The architecture description belongs to C.30.AD and related view patterns. The method description or pattern-use recommendation belongs to A.15, E.8, and E.11.PUR when those claims are live. The ADR-like record publishes a decision description for a declared reader and use.
For a principle framework, use C.32.ADR only in the exceptional case where the accepted framework-architecture answer is also an exact project architecture decision with the ArchitectureDecisionRelation@Project and ArchitectureDecisionDescription@Project required by this pattern. Its prior basis may then cite the accepted answer and the exact E.9 DRR that records it; acceptance remains a separate decision, and E.4.PFAD only profiles the framework-specific content. An ADR-like publication may project the question, selected answer, alternatives, rationale, consequences, status, links, and supersession conditions for declared readers. That projection remains separate from the answer, its acceptance, the DRR, framework realization, pattern quality, and publication adequacy. When the principle-framework answer is not an exact project architecture decision, publish the selected decision episteme or a reader-specific projection through E.17 and E.24.PUB; do not use C.32.ADR.
The section question is therefore not "which headings are allowed?" The section question is "which decision functions must a reader recover?" A heading can vary by organization or industry, but the record must carry the decision question, candidate options or reason no candidate set is live, outcome, rationale, consequences, method-use instruction when the decision guides work, work split, confirmation or eval path, source-return, status, and supersession or reopen condition.
ADR-like projection is not software-only. Engineering trade-study records, safety-certification rationale, design review memos, BIM decision logs, method-governance records, and organization-design records can play the same publication role after the project decision relation and record use are typed. The source form may differ; the FPF section functions stay recoverable.
Forces
Solution
Create ArchitectureDecisionRecordProjection@Project from an existing ArchitectureDecisionRelation@Project and ArchitectureDecisionDescription@Project. If the decision relation is missing, require C.32.PAD before writing the record.
Work in this order:
- Name the publication carrier and intended readers. The carrier can be a Markdown ADR file, decision memo, trade-study record, engineering change note, certification rationale, design-review record, or another typed file or record.
- Cite the decision relation and decision description. If the record cannot cite them, draft them first.
- Choose the smallest record scope that lets intended readers use the decision. Avoid copying architecture descriptions or full method descriptions; cite them by value where possible.
- Map section functions to headings or carrier slots. Use local headings if needed, but keep the function rows recoverable.
- Carry the candidate basis. Record candidate options from
C.32or the reason no candidate-set question is live. Do not invent options in the ADR after the decision. - Carry the decision outcome. State the selected architecture option, bounded exception, or supersession relation from PAD.
- Carry rationale, accepted losses, and consequences. Include architecture-characteristic trade-offs and guardrails, not only benefits.
- Carry method-use instruction and work split when the decision guides developer work. Cite
A.15, method descriptions, pattern-use refs, readiness exits, and expected structure effects rather than burying them in prose. - Carry confirmation, eval, or violation-detection exits. Use
C.32.ACE,C.16,A.10,B.3,A.21, or governance patterns when those claims are live. - Carry publication and source-return boundaries. Use
E.17,E.24.PUB, andC.30.ADfor publication-face and architecture-description claims. - Carry status, supersession, and update conditions. Old records remain useful as history when superseded; the active decision relation tells which one governs current work.
Required section functions
The following section functions are required unless the decision relation states why the function is not live for this record use.
ADR package use
When several records form a package, create a package map that names active, proposed, superseded, and related records. A package map is a publication navigation aid. It does not merge decisions, replace PAD relations, or decide record priority by file order alone.
When one decision changes another, use explicit supersession or amendment links. Do not rewrite history by deleting the old record unless the project has a governed archival policy.
Archetypal Grounding
Software ADR. A team publishes an ADR for event-carried integration. The record uses local headings, but the function rows recover context, options, selected outcome, rationale, consequences, method-use instruction for event schema work, confirmation eval, and supersession. Developers can see what to implement and when the decision reopens.
Manufacturing trade-study record. A fixture decision is published as an engineering trade-study memo rather than a Markdown ADR. The memo carries candidate fixture variants, selected universal-fixture scope, accepted setup-time loss, cell-design method instruction, evidence links, and reopen threshold. C.32.ADR admits the memo because it projects the decision description for the intended reader.
Certification rationale. A regulated product records a safety-architecture decision in a certification rationale. The record carries the decision outcome, rationale, evidence refs, architecture-description refs, and confirmation path, while evidence and assurance claims stay in A.10 and B.3.
Method-use record. A project decision requires reviewers to use an evidence handoff pattern before final review. The ADR-like record cites the Method description and expected evidence-structure effect; the Method family does not decide, and the instruction does not by itself establish performed review Work.
Bias-Annotation
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
Rationale
ADR practice is valuable when it makes architectural decisions communicable and revisitable. It becomes weak when a record is treated as the decision itself or when a template substitutes for decision work.
C.32.ADR therefore uses the record as a projection. The decision relation is made in C.32.PAD; the record publishes a decision description for a declared reader. This preserves the strongest ADR practice, small and updateable records, while adding FPF kind control for architecture descriptions, method descriptions, evidence, assurance, gate, publication, and performed work.
The pattern also generalizes ADR practice beyond software by using section functions rather than software-specific carrier assumptions. A record can be a Markdown file, engineering memo, or certification rationale if it projects the decision description and keeps receiving claims with their subject patterns.
SoTA-Echoing
These rows document transfers from source practice into C.32.ADR. Keep a source citation only when it changes section function, projection boundary, or update condition.
Source-currentness boundary. Recheck a source row when ADR template practice, decision-record tooling, violation-detection practice, architecture-description practice, FPF publication patterns, or project governance changes the section function or update rule used by C.32.ADR.
Relations
- Builds on:
C.32.PAD,C.32.P2S,C.30.AD,C.30.ASV,E.17,E.24.PUB,A.15,E.8,E.11.PUR, andC.32.ADA. - Decision boundary: Use
C.32.PADfor the project architecture decision relation. C.32.ADR publishes anArchitectureDecisionDescription@Project; it is not generic ADR guidance and not a second decision authority. - Structural-information boundary: ADR-like projections may cite
C.33,C.34, orC.35only to show captured structure, lost structure, preservation adequacy, generated-carrier typing, or discovered-carrier typing behind the projected decision. The ADR projection remains a publication projection of a decision description; it is not the architecture, the decision relation, or generated-carrier authority. - P2S docking: P2S may cite an ADR projection as one stage where decision, rationale, method expectation, and source-return are published for readers; ADR does not carry the whole architecturing flow.
- Architecture-description boundary: Use
C.30.ADandC.30.ASVfor architecture-description and view adequacy. ADR carries refs and reader-use slices, not full description authority. - Pattern and method boundary: Use
E.8when the published object is an FPF pattern,E.11.PURfor pattern-use recommendation, andA.15for method and work claims. - Publication boundary: Use
E.17andE.24.PUBfor MVPK face, publication carrier, and publication-use claims not specific to architecture decisions. - Evaluation boundary: Use
C.32.ADAfor decision adequacy; useC.32.ACE,C.16,A.10,B.3, orA.21for eval, measurement, evidence, assurance, or gate claims. - Package boundary: A record package map aids navigation among records. It does not decide active architecture by file order; PAD relations and status refs remain governing.
Footer marker
C.32.ADR closes when ArchitectureDecisionRecordProjection@Project cites the decision relation and decision description, names carrier, readers, scope, status, section-function mapping, decision outcome, rationale, consequences, method and work refs when live, confirmation or eval exit, publication boundaries, and update or supersession condition.
C.32.ADR:End
Architecture Decision Adequacy Scales
Type: Architecture evaluation pattern under C.32 Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when a project architecture decision, its method docking, or its ADR-like publication projection must be evaluated for adequacy before use, review, handoff, governance, or improvement.
Primary working reader: an architect, reviewer, or architecture-responsible practitioner checking whether a project architecture decision is good enough for a declared use and which repair should happen next.
Typical entry phrases:
First-minute use slice. ArchitectureReviewService-4 first has the A.13 core for decision-adequacy evaluation, and A.15.1 independently admits DecisionAdequacyEvaluationWork-12 from 10:00 to 10:20 on 2026-08-12. The Work enacts DecisionAdequacyEvaluationMethod-2 and occurs within ProjectArchitectureReviewService-4. This slice expressly represents evaluator accountability: ArchitectureReviewerAssignment-6 is an obtaining occurrence of directly declared species ArchitectureReviewerAssignment, held by the already recovered performer and covering the Work, and the separate F.6 relation is recorded. A Work-only ADA record would omit those assignment and attribution refs; failed F.6 would leave the evaluation Work intact. One separate result episteme states the declared use and coordinate outcomes. It does not approve the decision; it directs the exact bounded repairs needed before the decision can guide developer Work.
The primary governed object is ArchitectureDecisionAdequacyEvaluation@Project: a C.32.ADA-local evaluation record over one ArchitectureDecisionRelation@Project, optional ArchitectureDecisionRecordProjection@Project, and declared use. It is not the evaluated decision, evaluation Work, or result episteme.
ArchitectureDecisionAdequacyEvaluation@Project is a local record form, not a new U.* kind, gate, evidence, assurance, pattern-quality evaluation, or replacement for [C.32.PAD](/generated/patterns/C.32.PAD). Its coordinate table expresses the ADA result content; when that result must be a durable claim, one separately identified C.2.1 episteme states it. The dated evaluation remains separate U.Work, and any actual evaluation operation application remains with its subject pattern.
What goes wrong if C.32.ADA is missed: a decision can appear complete because it has a record, rationale, or diagram, while it is unusable for the declared work. Weak candidate basis, hidden trade-offs, missing method instructions, absent source-return, and vague supersession conditions remain invisible until implementation or review fails.
What C.32.ADA buys in practice: the project can evaluate architecture decisions by complete coordinate set, keep kinds distinct, and repair the weakest live coordinates without turning adequacy into a single score.
Ordinary working move: declare the evaluation use, evaluate every coordinate with an ordinal value and rationale, then state the repair condition for each weak coordinate and cite the smallest subject-pattern locus containing the required definition or constraint.
Adoption test: after using C.32.ADA, another practitioner can see the declared use, complete coordinate values, rationales, repair targets, and stop condition for the architecture decision.
Not this pattern when the current object is FPF pattern quality, measurement validity, evidence support, assurance, gate passage, candidate synthesis, comparison, selection, local choice, or ADR publication projection itself. Use the pattern for the next question named in Relations.
The first useful output is ArchitectureDecisionAdequacyEvaluation@Project:
Here @Project is a compatibility and retrieval cue only. A project-local ADA record names both the composite U.Work in projectWorkOccurrenceRef and the obtaining record-use relation in architectureDecisionEvaluationProjectUseRelationRef; the evaluated decision's own project relation, the suffix, or either field alone is insufficient. evaluatorSystemRoleKindRef and evaluatorSystemRoleClassificationJudgmentRef remain optional and separate. When actual evaluation is claimed, the evaluator first has its A.13 core and evaluationWorkRef names Work independently admitted under A.15.1. Assignment species, occurrence, and evaluationPerformedUnderAssignmentRef are optional and appear only when the record or receiving use expressly represents precise assignment-bound attribution; any present F.6 ref uses the same obtaining A.13 assignment, and its absence or failure leaves the Work intact. Any operation application and result episteme remain separate. Kind, classification, assignment, Work, attribution, application, responsibility, and result do not substitute for one another.
Problem
Architecture decisions are multi-kind objects in practice. A decision relation can be strong while its ADR projection is weak. A record can be readable while the decision lacks candidate traceability. A candidate basis can be strong while method docking is absent. A method instruction can be clear while the architecture-characteristic trade-off is hidden.
Because of that, a single pass, single grade, or average score is misleading. Adequacy must be evaluated by coordinates tied to the declared use. "Ready for internal architecture review", "ready for developer work", "ready for ADR publication", and "ready for governance enforcement" can require different stop conditions, but each use still needs complete coordinate inspection.
C.32.ADA supplies an E.21-shaped ordinal evaluation pattern for architecture decisions. It uses the E.21 value domain and labels directly, then defines architecture-decision coordinates over PAD relation, method docking, publication projection, structural description, characteristic trade-off, and evolution. Weak coordinates point back to C.32.PAD, C.32.ADR, C.30.AD, A.15, C.32.ACS, C.32.ACE, C.16, C.25, or another subject pattern.
Forces
Solution
Create ArchitectureDecisionAdequacyEvaluation@Project for one declared use. Evaluate the complete coordinate set. Do not average coordinate values. Use the weakest live coordinate to choose the next repair.
Shared value meanings
Use the same ordinal value domain and labels as E.21. ADA specializes what counts as expression for architecture-decision adequacy; it does not create a second scale.
Values are ordinal content evaluations. They are not measures, averages, votes, maturity ladder names, evidence weights, assurance levels, gate statuses, or implementation approval.
The result-bearing coordinate row uses the E.21 label domain with an architecture-decision coordinate:
5 is not required for every use. Stop conditions are declared before evaluation. A lower diagnostic floor may be used for exploration or internal discussion, but it does not make the decision ready for developer work, implementation commitment, or governance enforcement.
Complete coordinate set
Evaluate every coordinate. If a coordinate is not live, mark it notTriggered only with a short reason grounded in the declared use.
Use-specific stop conditions
Declare the use before scoring. Common uses:
Use these as ordinary defaults. A project can declare stricter stop conditions. It must not weaken a triggered coordinate by hiding it under an average, and it must not call a diagnostic result ready for developer work or governance enforcement.
Small complete evaluation slice
PAD adequate, ADR weak. A fixture architecture decision relation can reach 4 wellExpressedForDeclaredUse on every triggered PAD, Method, work-split, trade-off, and reopen coordinate while the trade-study memo omits status and supersession. ADA identifies only the missing publication-projection assertion and cites [C.32.ADR](/generated/patterns/C.32.ADR); it does not rewrite the PAD relation.
ADR readable, PAD weak. A Markdown ADR can have clear headings, status, context, decision, and consequences while the project relation lacks candidate basis, affected selected structures, and Method/Work docking. ADA identifies those missing assertions and cites [C.32.PAD](/generated/patterns/C.32.PAD), [C.32](/generated/patterns/C.32), and [A.15](/generated/patterns/A.15) as their subject-pattern locators; template completeness does not make the architecture decision adequate.
Archetypal Grounding
Developer-work readiness. A service architecture decision has strong candidate traceability and trade-off rationale, but the ADR only says "teams should use events". ADA gives MethodAndWorkDockingAdequacy = 2 partiallyExpressedForDeclaredUse because the acting Systems, MethodDescription, expected structure effect, and readiness condition are not recoverable. In this case the ADR also expressly requires accountable implementation under an exact assignment, so the absent assignment species/current occurrence and F.6 relation are additional attribution defects; a Work-only instruction would not require them. Any responsibility claim must cite its direct domain predicate or exact missing governor.
ADR-publication readiness. A manufacturing architecture decision is clear, but the trade-study memo omits status and supersession. ADA gives PublicationProjectionAdequacy = 2 partiallyExpressedForDeclaredUse and EvolutionAndReopenConditionAdequacy = 3 sufficientlyExpressedForDeclaredUse. The repair states the missing record-status and supersession assertions using C.32.ADR.
Architecture review. A method-family architecture decision has candidate options and Method instructions, but no declared architecture characteristics. ADA gives ArchitectureCharacteristicTradeoffAdequacy = 0 absent. The repair states the missing characteristic assertions using C.32.ACS and C.25 before review can judge the decision.
Governance enforcement. A toolchain-product correspondence decision depends on team and tool structures. ADA evaluates TransformerTransformedCorrespondenceAdequacy; if the correspondence refs are absent, the repair states the missing correspondence assertion using C.32.CONWAY before institutional governance can constrain Method use.
Bias-Annotation
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
Rationale
C.32.ADA exists because architecture-decision adequacy is not one property. It is a family of recoverability and use-readiness coordinates across decision relation, selected structures, architecture characteristics, method docking, work split, publication projection, evidence or eval exits, and evolution.
The pattern follows the same discipline as FPF quality evaluation: declared use first, complete coordinate set, ordinal values with rationale, no average, and targeted repair. It remains architecture-specific because the coordinates are tied to PAD, ADR projection, architecture descriptions, candidate synthesis, method-use instructions, and architecture-characteristic trade-offs.
SoTA-Echoing
These rows document transfers from source practice into C.32.ADA. Keep a source citation only when it changes a coordinate, value meaning, stop condition, or repair exit.
Source-currentness boundary. Recheck a source row when FPF evaluation discipline, architecture-decision practice, ADR violation checking, evolutionary-architecture eval practice, or project governance changes a coordinate, value meaning, or repair exit.
Relations
- Builds on:
C.32.PAD,C.32.ADR,C.32.P2S,C.32,C.32.MLAO,C.32.ACS,C.32.ACE,C.32.CONWAY,C.32.FAIL,C.30.AD,C.30.ASV,A.2.1,A.2.6,A.15,A.15.1,A.19,C.2.1,C.16,C.25,C.29,E.17, andE.21; uses A.1.1 only when a selectedBoundedModelUseStructurechanges evaluation interpretation. - Evaluation boundary: Use ADA only to evaluate architecture-decision adequacy for a declared use. It does not perform candidate synthesis, comparison, selection, selected-set result declaration, actual publication, local choice, evidence support, assurance, gate passage, governance enforcement, or pattern-quality evaluation.
- Decision and projection boundary: Use
C.32.PADto repair the decision relation andC.32.ADRto repair ADR-like publication projection. - Description and structure boundary: Use
C.30,C.30.AD, andC.30.ASVfor architecture claim, description, and view adequacy. - P2S docking: Use
C.32.P2Swhen a weak decision-adequacy row must reopen the connected architecturing flow rather than only repair the decision record. - Method and work boundary: Use
A.15,A.15.1,A.15.2,A.15.5,E.8,E.11.PUR, andC.24for method, work, readiness, pattern-use, and agentic tool-use claims. - Characteristic and eval boundary: Use
C.32.ACS,C.32.HCS,C.25,C.32.ACE,C.16,C.31, andC.31.ASAPfor characteristic rows, Q-Bundles, eval-program framing, typed measurement or evaluation results, modularity, and scale preference. ADA may inspect references to those objects as coordinate evidence, but it does not redefine, execute, or own them. - Evidence, assurance, gate, and governance boundary: Use
A.10,B.3,A.21, and local governance patterns when those claims are live.
Footer marker
C.32.ADA closes when ArchitectureDecisionAdequacyEvaluation@Project declares the use and stop condition; binds the exact claim scope and selected context slices, reference scheme and plane, evaluation window, and decision-question input projection; cites the evaluated decision relation and optional projection; evaluates every coordinate with an E.21 value label and rationale or grounded not-triggered status; names weakest blocking coordinates, repair patterns, and repair instructions; avoids average-score replacement; and, when actual evaluation is claimed, keeps the A.13-qualified evaluator System, independently admitted A.15.1 Work, operation application, any responsibility relation, and result episteme separately identified. Assignment species, occurrence, and F.6 attribution are present only when the record expressly represents that precise attribution.
C.32.ADA:End
Structural Information Adequacy for Architecture Capture and Missing-Structure Return
Type: Architectural pattern Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when an architect has a description, view, decision record, ADR-like projection, eval report, method handoff, generated relation graph, source model, or realized holon observation that carries or describes selected architecture-relevant structure and needs to know which selected structure is actually recoverable for the next architecture use.
Use the same pattern when the carrier is a narrative rendering or principle-framework publication for architecture work: the carrier may preserve a problem-to-structure ordering, problem-situation architecture, solution-move architecture, candidate trade-off, decision rationale, or missing-structure cue, but it may also hide selected structures that the next architecture use still needs. In architecture-mediated rendering, inspect the chain from carrier to architecture description or view, then to architecture as selected structures in context, then to wider selected source structures, because each relation may have captured and lost different structure.
Primary working reader: an architect, architecture reviewer, method steward, or AI-assisted architecture worker who must use one carrier or observation without letting it stand for the whole architecture, the project decision, evidence sufficiency, or realized structure.
Typical entry phrases:
The first useful output is StructuralInformationAdequacyNote@Context. It is a project-side adequacy note for one declared architecture use. It is not a C.16 characteristic, not a measurement, not an evidence record, not an assurance result, not a project decision, and not an architecture description by itself.
For the first pass, fill only the fields that prevent the next wrong use:
Adoption test: after using C.33, another practitioner can tell what selected structure is captured, what structure is expected but not captured, what is lost or hidden, what use is admissible, which non-admissible uses are blocked, and which practical claim, question, rule, or test comes next. Record a stable reference only when that next use must travel independently.
What C.33 buys in practice: the practitioner can use a partial carrier without pretending it is complete. The pattern turns "this diagram, ADR, graph, report, or observation is useful" into a reviewable statement about captured structure, missing structure, missing-structure return, and the next claim or test that needs that structure.
Ordinary working move: underline the carrier sentence, diagram, graph edge set, or observation being relied on; write what selected structure it captures; write what it leaves out; then name the use that remains admissible.
Not this pattern when the current question asks whether the architecture, record, lens, reading, decision, authorization, or publication is admissible. Use the pattern that defines or tests admissibility for that object and question first. Use C.33 only when that test relies on a carrier whose captured structural content and missing structural content must be made explicit.
Problem
Architecture work depends on partial carriers. Diagrams, views, relation graphs, ADRs, model queries, code-agent probes, neural-network architecture reviews, eval reports, method descriptions, and operation observations can carry enough structure for one action while losing structure needed for another action.
The practical problem is not "is the carrier good?" The problem is: what selected structure can be recovered from it for this declared architecture use, and what missing-structure return is needed before relying on it further?
Without C.33:
- a diagram, model, generated graph, ADR, or benchmark trace starts acting as architecture by presentation;
- structural information is confused with a score, entropy value, epiplexity estimate, dashboard reading, or eval result;
- hidden structure becomes invisible exactly when a later candidate, decision, or work method depends on it;
- source labels such as layer, router, expert, cache, memory, block, gate, SSM, pruning, distillation, or architecture search are copied as FPF ontology instead of being recovered through current FPF rules that define the relevant structures and relations;
- partial-observation outputs from code agents or AI tools are treated as internal belief proof, safe-change authority, evidence sufficiency, or release confidence.
Forces
Solution
Create one StructuralInformationAdequacyNote@Context for the declared architecture use.
Read the note as a small missing-structure return tool, not as a new documentation format. Its didactic question is simple: "What can I safely take from this carrier, what must I not take, and where do I go if the missing structure matters?"
Work in this order:
- Name the architecture claim or pre-claim, described holon, architecture concern, intended use, and any ClaimScope or qualification window that changes the adequacy judgment.
- Name the selected structure refs or structure kinds being relied on. If they are not recoverable, stop and use
C.30,C.30.ASV,A.22, orC.32.P2S. - Name the carrier, selected source structure, description, view, narrative rendering, decision record, eval report, method handoff, generated relation graph, or realized observation being used.
- State the captured selected structure in relation terms: relations, constraints, invariants, allocations, compositions, variation classes, operations, dynamics refs, or preserved organization.
- State the expected but uncaptured structure when the next use needs it: hidden placement, data custody, runtime dependency, transformation-flow relation, source label semantics, confidence class, unexplored region, or missing bearer.
- State lost or hidden structure. If no loss is claimed, justify why the carrier is adequate for the declared use rather than for all uses.
- Add observer or budget boundary when the carrier comes from a bounded observer, learned representation, probe, relation graph, or epiplexity-style lens.
- Add source label recovery when source terms come from a domain practice such as neural-network architectures, software modules, built assets, organizational roles, methods, or work.
- Use the pattern that defines or tests each mathematical-lens, measurement, eval, decision, evidence, assurance, gate, release, method, work, or publication claim when one of those claims is current.
- Stop when admissible use, non-admissible use, missing-structure return condition, the next claim or question, and its required rule or test are clear.
CGUS-aware neighbor use: when a carrier, route card, narrative rendering, architecture description, framework publication, or generated relation graph is relied on because it preserves a constraint-governed unfolding structure, C.33 records only what that carrier captures and loses. The selected structure remains ConstraintGovernedUnfoldingStructure@Context or a local U.Structure block governed by A.22.CGUS, E.18.3, C.32.P2S, E.23, or another direct structure pattern. When the carrier is a narrative, A.6.3.NAR governs only its selected-source carry-through, ordering and connective account, loss, reader use, and source return; it neither selects nor admits the structure.
A DemonstrativeUnfoldingSlice@Context may be the U.Episteme slice or presentation whose captured structure and lost structure C.33 records; it is not the selected U.Structure by itself. C.33 does not admit the CGUS; it tells the pattern for the next question what the carrier actually preserved and where missing selected structure must be inspected or repaired.
Archetypal Grounding
Tell: C.33 is the pattern for using a partial carrier that captures or describes selected structure without letting that carrier stand for the whole architecture. The carrier may be a diagram, decision record, query result, eval report, code-agent map, neural-network architecture review, method handoff, or observation of the realized holon. The grounding question is not whether the carrier is impressive. The grounding question is what selected structure it captures, what it leaves out, and which practical claim or question must be addressed next under which concrete rule or test. Add exact C.2.1 identity only if that claim must travel independently.
Show - system case. An ADR-like record says "use event-carried integration with bounded exception." C.33 records that the carrier captures the selected integration style, exception boundary, and method expectation. It does not capture lower-level placement constraints, schema evolution burden, runtime data custody, or deployment topology. The admissible use is decision memory and method handoff; the non-admissible use is proof that the realized modules have the intended architecture. A missing-structure condition reopens the C.32.PAD decision, C.32.ADR projection, C.30.AD description, and, if actual structure diverges, the C.32 synthesis question.
Show - episteme case. A code-agent relation graph finds imports, call edges, inferred module roles, and candidate invariants. C.33 records relation observation class observed | inferred | unknownRegionPresent, typed relation semantics, confidence class, active-passive gap when present, unexplored regions, and lost runtime or deployment structure. The graph can seed C.34 preservation checks or C.35 discovery, but it is not internal belief proof, release evidence, or full architecture adequacy.
Show - neural architecture case. A neural-network architecture review says a model changed attention, SSM block, router, cache placement, pruning mask, and distillation path. C.33 recovers which selected structures are being described: dataflow relation, path-selection relation, memory placement, cache placement, block substitution, and affected characteristics such as latency, compute, memory, and robustness. Source labels remain source labels until recovered through C.30.STRAT, C.30.TFS-REL, C.31, C.32, C.16, or C.32.ACE as applicable.
Show - architecture narrative case. A team narrative says "we moved from candidate A to candidate B because data custody forced placement P and made latency trade-off T acceptable." C.33 records which selected structures the narrative captures: candidate relation, data-custody constraint, placement constraint, trade-off, and missing-structure return condition. It also records lost or hidden structure such as rejected candidate details, quantitative evals, module interfaces, and realization evidence. The narrative can help decision memory or team orientation; it is not by itself an architecture description, decision authority, or evidence of realized structure.
The small working form is enough when it blocks a wrong next use. It is not enough when the next claim needs an architecture description, structural view, decision repair, eval program, evidence record, assurance case, gate, release, or work authorization. In those cases C.33 produces the missing-structure return condition and then exits.
Bias-Annotation
Conformance checklist
Common Anti-Patterns and How to Avoid Them
Consequences
Positive consequences:
- A partial carrier becomes usable without becoming authoritative. The architect can take exactly the structure that is recoverable and stop before overreading the carrier.
- Missing-structure return becomes local and reviewable: the note says which missing structure requires C.30, C.30.ASV, C.32.P2S, C.32, PAD, ADR, C.29, C.16, ACE, evidence, assurance, or work checks before the next use.
- AI-produced maps and maps derived from named source publications, source models, or source codebases become safer architecture inputs because observation class, confidence, unexplored regions, and budget boundary are visible.
- Neural-network and code-architecture source labels become usable without importing those labels as FPF ontology.
Costs and trade-offs:
- C.33 adds one small note before some architecture work. The cost is justified only when a next use might overread a carrier.
- The note can be too weak for decision, evidence, assurance, eval, release, or realized-structure claims. In those cases C.33 should stop early and use the pattern that defines or tests the current claim.
- A team may discover that a familiar diagram or ADR is insufficient for the intended use. That is not a failure of C.33; it is the missing-structure return condition doing its job.
Rationale
Architecture work often starts from carriers that are neither useless nor complete. A mature pattern must preserve both facts. If C.33 only says "do not confuse the carrier with architecture," it becomes a negative catalogue. If it treats every carrier as an architecture description or measurement, it duplicates C.30, C.16, and C.32.ACE. The chosen solution is a small adequacy note whose center is captured selected structure, lost structure, admissible use, and missing-structure return.
This split keeps P2S as the whole architecturing spine and C.32 as the pattern that describes candidate synthesis. C.33 does not synthesize architecture and does not decide the project architecture. It gives the practitioner and the next check a typed account of what a carrier contributes and what must still be recovered.
The source choices explain the fields. Epiplexity motivates observer-bounded structural information but not a universal architecture metric. Multi-relational structural entropy motivates relation-kind awareness but not adequacy by number. Sapunov and ToCS motivate partial observability, active-passive gap, invariant fields, confidence, and unexplored regions. GonzoML motivates richer neural architecture operation language without making those labels FPF ontology.
SoTA-Echoing
C.33 deliberately rejects a popular shortcut: "the richest available diagram, map, score, or model summary is the architecture content." The better practice is to ask what the carrier captures for one declared use and what it cannot support. That is why SoTA rows must change fields, stop conditions, or concrete next-use rules rather than only supplying lineage.
Relations
- Builds on:
A.22,C.30,C.30.AD,C.30.ASV,C.32.P2S, andC.32. - Uses:
C.29when a mathematical lens exposes or compresses structure;C.16,C.25, andC.32.ACEwhen a claim about captured or lost structure is recorded as a measurement, Q-bundle slot, criterion, or eval reading. - Coordinates with:
C.30.STRAT,C.30.TFS-REL,A.6.M,A.6.3.NAR,C.31,C.31.ASAP,C.32.PAD,C.32.ADR,G.5,C.18,C.19,E.18,F.9, andF.15. - Boundary: C.33 governs structure-capture adequacy and missing-structure return for a declared architecture use. It does not ground architecture, select candidates, decide projects, publish records, measure values, supply evidence or assurance, authorize work, or claim realization.
C.33:End
Structural Correspondence, Equivalence, and Morphism Adequacy
Type: Architectural pattern Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when two descriptions, views, models, generated outputs, or realized observations that carry or describe selected structure are being treated as the same enough for architecture work and the practitioner must say what selected structure is preserved, what is lost, and which use the correspondence licenses.
Primary working reader: an architect, reviewer, or model-assisted practitioner comparing views, descriptions, source models, generated graphs, candidate architectures, realized structures, abstraction levels, coarsened models, or transformed models.
Typical entry phrases:
The first useful output is StructuralPreservationAdequacyNote@Context:
Adoption test: after using C.34, another practitioner can tell which mapping mode is being claimed, which structure is preserved, which structure is lost, whether the relation is directional or scoped, and which downstream claim is licensed.
What C.34 buys in practice: the practitioner can say "same enough for this use" without smuggling in stronger equivalence. The pattern makes sameness conditional on preserved relation, declared loss, and receiving use.
Ordinary working move: put the source and target structures side by side, circle the relation or constraint that must survive, name the relation that does not survive, and choose the weakest mapping word that still supports the next use.
Not this pattern when the current claim is only mathematical-lens use, generic bridge translation, measurement, structural view adequacy, architecture-description correspondence, candidate synthesis, decision, evidence, assurance, gate, release, or work authorization. Use the pattern that defines or tests that current claim and keep C.34 only for the architecture-specific preservation claim.
Problem
Architecture work often needs "same enough" claims. A view should correspond to a description. A generated graph should preserve selected dependencies. A candidate should preserve required interfaces while changing placement. A realized structure should match an expected selected structure enough for an evaluation or decision repair. A neural-network substitution should preserve dataflow or routing while changing memory and compute trade-offs.
The dangerous shortcut is to accept visual similarity, label sameness, graph isomorphism, or formal vocabulary as adequacy. An edge-isomorphic graph can lose relation semantics. A projection can preserve module names while dropping control authority. A category-theoretic morphism can be useful as a C.29 lens without proving architecture equivalence. A DSM cluster can preserve co-change pressure while losing functional bearer semantics.
C.34 makes the preservation claim explicit before the result is used.
Forces
Solution
Create one StructuralPreservationAdequacyNote@Context before relying on the same-enough claim.
Read the note as a disciplined "same enough" card. It does not ask for perfect identity unless the use requires it; it asks what must survive for the next architecture action and what loss remains visible.
Work in this order:
- Name the selected source structures and selected target structures. Do not start from labels, diagrams, or tool objects alone.
- Name the intended architecture use: view correspondence, candidate comparison, structure recovery, generated-output admission, realization check, eval support, decision repair, or another receiving claim.
- Choose the weakest mapping mode that is adequate for the use. Use
exactEquivalenceonly when empty loss is justified. - State preserved relations or constraints in domain and FPF terms. Include relation-type semantics when edge or link meaning changes the use.
- State lost structure, hidden structure, directionality, and scope or scale window.
- Cite
C.29only when a mathematical object, graph match, functor, invariant, entropy, or formal mapping is being used as a lens. - Cite
C.30.ASV,C.30.AD, or their correspondence records when the relation is view or architecture-description correspondence. - Cite
A.6.3.NARwhen the target episteme or representation is a narrative rendering whose ordering rationale, preserved selected source structure, source-return condition, and any unresolved stronger assertion with the pattern that defines it must stay inspectable. - Cite
F.9orF.15when the claim crosses bounded contexts, source traditions, or later conformance strengthening. - Stop when admissible use, non-admissible use, preservation-loss return condition, the next claim or use, and its required mapping, bridge, conformance, or other rule are named.
CGUS-aware neighbor use: when a route-shaped publication card, narrative sequence, generated route card, framework publication, or demonstrative slice is claimed to preserve a constraint-governed unfolding structure, use C.34 only to check the sameness relation. The result names selected source and target structures, mapping mode, preserved constraints, preserved ordering or branching relations, lost alternatives, directionality, and admissible use. A.22.CGUS, E.18.3, C.32.P2S, or another direct structure pattern continues to define or constrain the selected unfolding U.Structure; cite an exact ClaimGraph only if that structure claim must travel independently. A DemonstrativeUnfoldingSlice@Context is a U.Episteme presentation or traversal whose correspondence to that structure may be checked here. When that presentation is a narrative, A.6.3.NAR defines its source selection, ordering and connective account, preservation/loss, use, and return, not the selected structure. The C.34 result says only whether the target is same enough for the declared architecture use.
Archetypal Grounding
Tell: C.34 is the pattern for a declared architecture preservation claim. It is used when a practitioner says that one description, view, model, generated output, or realized observation is same enough as another for a specific architecture use. The pattern does not ask for the strongest possible proof. It asks for the weakest adequate mapping mode, preserved structure, lost structure, directionality, scope, admissible use, and the next claim or use plus the concrete rule it needs.
Show - view and description case. Two architecture diagrams are edge-isomorphic. In one diagram an edge means data dependency; in the other it means control authority. C.34 records mapping mode nearSameness, preserved node partition, lost relation-type semantics, and non-admissible use "control separation decision." The repair is to recover relation semantics through C.30.ASV, C.30.TFS-REL, or C.30.LCA before using the mapping for architecture work.
Show - source model and generated graph case. A code-agent dependency graph matches module names in the model used as the source, but marks several edges inferred and several regions unexplored. C.34 records relation observation class, directionality, preserved dependency hints, lost dynamic wiring, and non-admissible use "safe-change authority." The graph may help inspect candidate dependencies, but it cannot prove release readiness.
Show - candidate and realized structure case. A candidate architecture promises that a service split preserves interface substitutability, but the realized structure adds shared storage and a hidden orchestration dependency. C.34 records preserved interface signatures, lost runtime independence, changed coupling, and a preservation-loss condition that requires A.6.M, C.31, C.30, and C.32.PAD checks before the decision is reused.
Show - neural substitution case. A candidate replaces an attention block with an SSM block. C.34 asks which selected structures are preserved: sequence dataflow, routing interface, memory access, latency envelope, training resource boundary, or inference resource boundary. Shape sameness or benchmark improvement does not by itself preserve the architecture relation needed by the next claim.
Show - selected source structure and narrative structure case. An architecture narrative orders a candidate set as "pressure, alternative, trade-off, decision, residual." C.34 records mapping mode correspondence, preserved structure candidate alternative and selected trade-off relation, lost structure full Pareto-front detail and rejected-candidate evals, directionality selected source structure to narrative only, and admissible use team orientation and decision memory. The narrative order is not exact equivalence and does not license implementation, evidence, or assurance use without the rule that defines or tests that downstream claim.
Bias-Annotation
Conformance checklist
Common Anti-Patterns and How to Avoid Them
Consequences
Positive consequences:
- Architects can use partial sameness without pretending to have identity. This keeps comparison, projection, generated-output admission, realization checks, and decision repair usable.
- Formal methods become useful at the right locus: graph matching, category-theoretic morphisms, entropy, and simulation relations can support the mapping without becoming architecture ontology.
- Cross-context and source-tradition risks are visible early because directionality, scope, bridge loss, and the applicable conformance rules are named.
- Later decisions can be repaired locally: the preservation note says which relation failed, which structure was lost, and which claim or check must be reopened.
Costs and trade-offs:
- C.34 adds friction before easy claims such as "same diagram," "same graph," or "same module." That cost prevents stronger authority from entering through weak similarity.
- The pattern does not prove formal equivalence by itself. When proof, measurement, evidence, assurance, gate, release, or work authorization is current, apply the corresponding rule or test.
- Some comparisons will lower from equivalence to correspondence or near-sameness. That lowering is a success when it prevents a false downstream claim.
Rationale
Architecture preservation is use-relative. The same two structures can be equivalent for one use, merely corresponding for another, and unusable for a third. A mature C.34 therefore cannot be a generic formalism pattern. It must start from source and target selected structures, then choose the weakest mapping mode that licenses the next architecture use.
This keeps C.34 separate from its neighbors. C.29 defines mathematical-lens-use accounts. C.30.AD and C.30.ASV define description and view records. F.9 defines cross-context Bridges. F.15 supplies regression and conformance tests. C.32 describes candidate synthesis. C.34 contributes the preservation claim those uses may need, but it does not replace them.
The source families explain the safeguards. Structural-equivalence research shows that symmetry can compact search only under explicit conditions. Applied category theory shows why preservation maps are powerful but still formal lenses until tied to the architecture use. MBSE view practice makes projection and omitted structure ordinary. Sapunov and ToCS, plus GonzoML, show why observed relation maps and neural substitution labels need typed relation, confidence, and source-label recovery before architecture use.
SoTA-Echoing
C.34 rejects one common but weak practice: treating any formal-looking mapping as architecture equivalence. The stronger practice is to say exactly what survives, what is lost, and what downstream use is licensed.
Relations
- Builds on:
A.22,C.30,C.30.ASV,C.30.AD,C.29, andF.9. - Uses:
C.16,C.25, andC.32.ACEwhen a preservation, similarity, distance, entropy, loss, or compression claim is recorded as a reading or eval result. - Coordinates with:
C.32,C.32.PAD,C.32.ADR,C.30.TFS-REL,C.30.STRAT,A.6.M,A.6.3.NAR,C.31,C.31.ASAP,E.18, andF.15. - Boundary: C.34 tests declared preservation adequacy for an architecture use. It does not make a formalism ontology, select a candidate, decide a project, establish evidence or assurance, or authorize substitution across contexts; that substitution still requires the applicable Bridge predicate and conformance rule.
C.34:End
Structural Synthesis and Discovery Adequacy
Type: Architectural pattern Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when a generated, searched, clustered, queried, learned, transformed, simulated, or discovered result may seed or inform architecturing, and the practitioner must decide what that exact result is and whether it can enter architecture work before or around C.32 candidate admission.
Primary working reader: an architect, architecture researcher, AI-assisted architecture worker, model-based engineer, or reviewer receiving an exact result from DSM and MDM modularization, MBSE query and view generation, graph grammar, model transformation, NAS, DSE, QD, OEE, and NQD search, LLM-assisted architecture design, code-agent mapping, simulation, benchmark trace, or source discovery.
Typical entry phrases:
Primary working object. The exact generated or discovered result on which the next architecture use would rely.
First useful move. Recover that result by its truthful kind, then say what organization it concerns, what the intended next use still requires, and what must not be inferred. If the organization is only proposed, keep it modal in an exact C.30 ArchitectureClaim. Treat a graph, diagram, matrix, encoding, or model as a separate C.29 representation when representation operations matter. Publication detail enters only when availability or form changes the use.
Normal first result. One sentence containing the same four facts is conforming. When a visible note is clearer, write only:
Stop there when another practitioner can make the intended next move safely. Only when result identity, branch evidence, or a receiving claim must be reidentified independently, extend those four facts into the optional StructuralSynthesisDiscoveryAdequacyNote@Project C.2.1 episteme:
The note's first four fields reproduce the readable minimum; every later field is conditional on an actual dependency of the selected branch or receiving use. Its EntityOfConcern is the exact result designated by resultRef, not the reference value, representation, publication occurrence, form, or carrier used to reach it. When publication detail is relied on, publicationFormRef, publicationOccurrenceRef, and presentationCarrierRef each name their truthful object; omit every one that the receiving use does not need. Its ClaimGraph states the organization concerned, intended next use and condition, forbidden overread or return, and any additional admissible use or unresolved condition that the receiving use needs. Do not open or fill the dossier merely to prove completeness.
Here @Project is a compatibility and retrieval cue only. It establishes no project entity, composite-work identity, context, authority, viewpoint, or parthood. When the note is genuinely used in one actual project, projectWorkOccurrenceRef identifies the exact composite U.Work and structuralSynthesisAdequacyNoteProjectUseRelationRef identifies the direct relation by which that exact project Work uses the note. The suffix or either reference alone establishes no project locality. The admission-note episteme, its exact result, and the composite project Work remain distinct.
When the admission claim relies on performed generation or discovery, generationOrDiscoveryWorkRef is mandatory and names an independently admitted U.Work occurrence whose exact actual performers have A.13 cores and which A.15.1 admits independently; otherwise omit the Method and Work fields. generationOrDiscoveryWorkAttributionRefs are optional and appear only when the note or receiving use expressly represents precise assignment-bound attribution through the same obtaining A.13 assignment. Missing or failed F.6 leaves the Work ref intact. The Method, Work, attribution, admission-note episteme, generated result, representation, and any publication occurrence or carrier remain different objects.
actualTransformationRefs may cite only independently identified A.3.4 bounded changes; a Method label, transformation trace, graph edge, or before-and-after picture does not make a transformation actual. Any positive link from the Work to an actual transformation or produced entity must cite its declared predicate, an admitted A.6.RCD local claim, or the selected A.15.PROD branch in workToTransformationOrProductionClaimRefs; otherwise keep the objects separate and return missing-governor. An entry in obtainingStructureRefs resolves to an independently selected A.22 U.Structure with independently identified constituents, exact obtaining relation occurrences, applied constraints, and one named use frame. Whenever the result or a branch proposes an organization, modalArchitectureClaimRef is mandatory and identifies the exact C.30 ArchitectureClaim or ClaimAddress; its proposed constituents and relations stay modal until the A.22 basis actually exists. A result, representation, publication item, graph, cluster, description, or plausible modal wording supplies none of those four discriminators.
Adoption test. After using C.35, another practitioner can state the four-line minimum or an equivalent sentence: the exact result, the organization that already obtains or is only proposed, the one condition required for the next use, and the forbidden overread or return. That practitioner can also distinguish claim content, an obtaining A.22 structure, a C.29 representation, and a publication-side object. Additional identity, branch, Work, bearer, publication, evaluation, or next-claim detail appears only when the receiving use relies on it.
What C.35 buys in practice. The practitioner can keep a useful generated or discovered result without handing it architecture authority. Architecture use attaches to the exact result; changing a rendering or file does not silently change the admitted claim, and admitting a carrier does not silently admit claim content.
Ordinary working move. Write the one sentence or four lines first. Recover whether the organization already obtains or is only proposed, and stop if the next move and return are clear. Use A.22 only when its four identity discriminators resolve; otherwise keep the proposal modal in its exact architecture claim. Add a C.29 representation, branch basis, Method, Work, bearer, publication, evaluation, or exact next-claim reference only when the intended use depends on it.
Not this pattern when. If the current question is how to search, choose, measure, decide, authorize, publish, govern a reusable generator, govern a cultural-evolution case, or run the work itself, use the pattern that defines or decides that question first, including [C.36](/generated/patterns/C.36) for the cultural-evolution relation bundle. Use C.35 only when an exact generated or discovered result must be admitted or rejected before another architecture claim relies on it.
Problem
Modern architecture work receives claim-bearing outputs, representations, publication items, and other results from DSM clusters, MDM slices, MBSE queries, generated views, graph grammars, model transformations, LLM architecture proposals, AI-assisted ADD, code-agent relation graphs, NAS graphs, DSE traces, Pareto fronts, QD archives, benchmark traces, simulations, and source-corpus mining.
These results can expose candidate decompositions, relation gaps, hidden invariants, feasible search regions, trade-off points, source labels, or overlooked organization. They are not automatically obtaining A.22 structures, realized holon structures, eval results, evidence sufficiency, or decision authority.
C.35 handles the gap between exact result identity and architecture use. It first asks what the result is; which claim, represented object, or proposed organization it carries; whether representation or publication distinctions matter; and which architecture use is proposed. It then asks only the questions belonging to the actual branch. A transformation names its exact source and result objects, trace, preservation, and loss. A discovery names its observation or extraction basis, what is observed, inferred, or unknown, the covered and unexplored region, uncertainty, and validation. A generative proposal names its constraints, proposed organization or claim content, known omissions, and validation needs; source and preservation enter only when an actual baseline is declared. Method, performed Work, attribution, bearer feasibility, and publication detail enter only when the receiving use relies on them.
Forces
Solution
Start with the readable admission statement. Name the exact result, the organization it concerns, the one condition still required for the intended next use, and the forbidden overread or return. A sentence is enough; use the four-line form when separate lines make the boundary easier to see.
Use the smallest sufficient path:
- Write the sentence or four lines. If they let the receiver act safely, stop.
- When the obtaining-versus-proposed distinction affects use, identify the exact C.30
ArchitectureClaimor ClaimAddress for a proposal, or apply A.22's four discriminators for a positive structure. Add a C.29 representation only when correspondence or representation operations matter. - When the receiving use relies on how the result arose, add exactly one applicable branch. A transformation adds exact source and result objects, trace, preservation, and loss. A discovery adds observation or extraction basis, what is observed, what is inferred, what remains unknown, the covered and unexplored region, uncertainty, and validation. A generative proposal adds constraints, proposed organization content, known omissions, and validation needs; source and preservation enter only for an exact declared baseline.
- When the admission claim relies on performed generation, discovery, production, or change, add the exact Method, dated
U.Work, and the direct production, discovery-use, or Work-to-change claim. Otherwise omit them. - Add bearer feasibility, realized structure, publication, archive or front policy, evaluation, measurement, decision, reusable-generator, or exact next-claim references only when the intended use relies on that exact claim. Use its direct pattern rather than copying its dossier into C.35.
- Stop when the receiver knows the admissible next move, the condition still open, and the limit or return. Materialize the optional full note only when those facts or their relied-on branch details need an independently reidentifiable result.
Conditional exits remain direct: C.32 for candidate-palette use; C.32.ACE for eval programs and results; C.16 for measurement; C.29 for mathematical-lens use; C.30.AD or C.30.ASV for descriptions and views; G.5, C.18, and C.19 for selected-set, archive, front, and pool claims; E.17 and E.24.PUB for publication; C.32.PAD or C.32.ADR for decisions; and E.20, G.1, G.10, or G.11 only when a reusable generator or mechanism suite is actually current.
CGUS-aware neighbor use: when a result is useful because it describes, compresses, or demonstrates a constraint-governed unfolding organization, C.35 admits only that exact result for the declared architecture use. Cite an A.22.CGUS structure only when its positive A.22 and A.22.CGUS basis already obtains; otherwise keep the organization as modal claim content. The structure itself, when it exists, remains with A.22.CGUS, E.18.3, C.32.P2S, E.23, or another direct structure pattern. If the encountered item is only a route card, narrative sequence, demonstrative slice, generated publication form, or presentation carrier, recover its claim-bearing result and represented object before making any positive structure claim. When it is a narrative sequence, A.6.3.NAR governs only the selected-source carry-through, ordering and connective account, loss, reader use, and return.
Archetypal Grounding
Tell: C.35 is the pattern for admitting or rejecting an exact generated or discovered result before another architecture claim relies on it. The result may come from search, clustering, query, learning, transformation, simulation, or discovery. C.35 does not search, select, decide, or realize architecture. It asks what the exact result is, whether the organization it concerns already obtains or is only proposed, what the intended use still requires, and what overread or return keeps it from acquiring false authority.
Show - generated claim and diagram not yet architecture. An LLM returns proposal claim MedicalDeviceProposal-7 and diagram MedicalDeviceDiagram-7. The ordinary C.35 result is:
This is enough for the immediate candidate-use boundary. Add the generative-proposal branch only if the receiver relies on its constraints, omissions, or validation needs. Treat MedicalDeviceDiagram-7 as a separate C.29 representation only when graphical correspondence matters; no source or preservation account is invented without a declared baseline.
Show - DSM and MDM clustering. A DSM modularization returns a clustering result based on co-change and interface hints. This is the discovery branch: C.35 identifies the exact claim-bearing cluster result and its extraction basis and records which dependencies are observed, which modular interpretation is inferred, what remains unknown, which matrix region was covered or unexplored, the uncertainty, and the validation needed before use. The inferred modular organization stays in its exact architecture claim; it is not an A.22 structure until the constituents, obtaining relations, applied constraints, and named use frame resolve. When matrix operations matter, C.29 separately identifies the representation and represented dependency object. A comparison with an earlier modularization may add an exact declared baseline and preservation account, but clustering alone does not require one.
Show - NAS result. A multi-objective NAS run returns a modal architecture claim about a proposed neural organization together with a graph representation and Pareto result. This is the generative-proposal branch: C.35 keeps those identities separate and records the search constraints, proposed organization content, known deployment and evidence omissions, bearer boundary, and validation and eval needs. The graph is a C.29 representation, not proof that the proposed relation occurrences obtain. C.35 does not invent a preserved-dataflow claim unless the run explicitly transforms or compares against a declared baseline. [C.32](/generated/patterns/C.32) may consume the proposal as candidate input; [C.32.ACE](/generated/patterns/C.32.ACE) handles evaluation results.
Show - graph grammar or model transformation. A graph-grammar Method is applied in dated generation Work and returns a claim-bearing result plus a graph representation for a product-line model. This is the transformation branch: C.35 names the Method, exact Work when performed-work reliance is current, exact source and result objects, rules, preserved interfaces, lost manufacturing constraints, and transformation trace. If the resulting organization is only proposed, it remains modal content in an exact architecture claim and the graph remains its C.29 representation. Source or result A.22 structures are cited only when their four discriminators independently resolve. If the use additionally asserts an actual formal or world-side change, it cites the exact A.3.4 occurrence and the separately governed Work-to-change or A.15.PROD claim; otherwise model transformation remains the Method or operation-family label and no U.Transformation is inferred. C.34 may check preservation; C.32 may admit the proposal without actualizing it.
Bias-Annotation
Conformance checklist
Common Anti-Patterns and How to Avoid Them
Consequences
Positive consequences:
-
Generated or discovered results can enter architecture work without becoming authority. Ordinary use stops after one sentence or four lines; the optional dossier appears only for a real downstream dependency.
-
C.35 keeps the result-use return visible. If the exact result cannot support the next architecture claim, repair returns to that result, the obtaining structure or modal organization it concerns, the missing condition, and the required rule or test; the return never turns the proposal into an A.22 member.
-
C.32 continues to define candidate-palette admission. C.35 supplies the result-use boundary that C.32 may need.
-
Search, query, transformation, and AI-assisted results become auditable without conflating claim-bearing content, represented objects, representations, publication items, and carriers.
-
Reusable generator governance stays outside C.35 until explicitly opened, which prevents one-case result review from becoming a hidden method or mechanism-suite pattern. Costs and trade-offs:
-
C.35 adds an admission step before fast use of generated outputs. That is a real cost when teams want quick candidate expansion.
-
Some outputs will be useful but not yet admissible. The repair is not to discard them or fill irrelevant preservation rows; it is to supply the missing branch-specific basis, bearer boundary, validation, or next claim plus its required rule.
-
The pattern is intentionally narrow. It does not choose among alternatives, manage archives, define eval programs, or authorize work.
Rationale
Architecture synthesis increasingly receives results from search, model transformation, LLM proposal, code-agent mapping, DSM modularization, NAS, simulation, benchmark, and source discovery. Refusing those results would waste useful structure. Accepting them as architecture would create false authority. Four readable facts are normally enough to hold the middle position: exact result, actual or proposed organization, next-use condition, and limit or return. The larger record is justified only by a receiving use that depends on its additional distinctions.
The separation among claim-bearing result, modal architecture claim, obtaining A.22 structure, represented object, C.29 representation, publication occurrence or form, presentation carrier, bearer boundary, eval result, and decision authority is the core ontology of the pattern. Without that separation, C.35 would duplicate C.29, C.32, PAD, ADR, ACE, C.16, C.18, C.19, G.5, E.24.PUB, and the patterns for evidence, assurance, gates, release, methods, and Work. The source families explain why the branches differ. MBSE query practice, DSM and MDM work, and code-agent mapping expose discovery questions about extraction basis, observation, inference, unexplored regions, uncertainty, and validation. Graph grammars and model transformations expose the distinct need for exact source and result objects, trace, preservation, and loss. Multi-objective NAS and LLM-assisted design expose proposal questions about constraints, proposed organization, omissions, and validation without inventing a source structure. GonzoML shows why source labels still need recovery before any branch can support candidate admission.
SoTA-Echoing
C.35 rejects the popular shortcut that a generated result, Pareto point, cluster, graph, or diagram is architecture because it looks useful. Recover the exact result first; add representation or publication details only when they matter; then state the intended use, missing condition, forbidden overread, and return.
Relations
- Builds on:
C.30,C.30.AD,C.30.ASV,A.22,C.32.P2S, andC.32. - Uses:
C.34when the transformation branch or an explicit baseline comparison must preserve selected source structure;C.33when capture and loss in the output are the current issue;C.29when a formal search, graph, entropy, category, or learned representation is being used as a mathematical lens. - Coordinates with:
A.3.4for each actual bounded change;A.15.1,A.2.1, andF.6for performed generation or discovery Work;A.15.PRODandA.6.RCDfor exact production or Work-to-change claims;C.36when a cultural-evolution case supplies the generated or discovered result while retaining governance of that case;C.30.STRAT,C.30.TFS-REL,A.6.M,C.31,C.31.ASAP,C.32.ACS,C.32.ACE,C.16,C.25,G.5,C.18,C.19,E.18,C.32.PAD, andC.32.ADR. - Boundary: C.35 governs exact-result use admission before or around C.32 candidate admission. It does not build the candidate palette, select from alternatives, govern reusable generators, define eval programs, measure values, decide projects, supply evidence or assurance, authorize work, publish the result, or prove realization.
C.35:End
Cultural Evolution and Cultural-Evolution Engineering
Tech-name:
CulturalEvolutionEngineeringPlain-name: cultural evolution and cultural-evolution engineering Type: Conceptual and project-use pattern (C) Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Use this pattern when the current project question is about how a culture, style, tradition, discipline practice, method family, work family, canon, recognition regime, selection regime, or mediating system changes and can be deliberately influenced.
Typical first-use situations:
- an engineering group treats its product family, toolchain, platform family, research program, or AI-agent framework as an evolving set of variants rather than one fixed system;
- a scientific, medical, pedagogical, engineering, music, dance, organizational, or AI-agent discipline is changing through related methods, work products, training forms, memory epistemes, recognition regimes, and selected variants;
- a music or dance steward needs to compare style, genre, technique, scene, canon, platform, or tradition labels without assuming that the label names one root kind;
- a project lead wants to influence the evolving practice—for example by changing how variants are generated, transmitted, recognized, selected, remembered, measured, or refreshed, or by changing a Method family, Work family, assignment, mediating architecture, or performed intervention.
What goes wrong if missed
The team treats culture as shared vocabulary, treats style as a genre tree, treats a platform as the cultural object, treats a QD archive as the decision, or treats one scalar popularity or quality score as cultural development. The project can then generate many variants but still lose the relations that make those variants transmissible, recognizable, selectable, retained, refreshed, or turned into work.
What this buys
The practitioner gets one small statement of what is changing, which relations transmit, recognize, select, retain, or mediate variants, what intervention is current, and what to do next. Add collective holons, local system-role kinds, classifications, assignments, Work and Method families, canon or memory epistemes, architectures, measurements, and refresh relations only when the current claim actually needs them.
First useful move
Start with one ordinary sentence. For example: In this dance school, teachers transmit variants through teaching, the festival archive retains and presents records of variants, jury recognition and peer copying select variants, and the current intervention changes how new variants enter the syllabus. Add the next pattern only when its definition or test changes the action.
When the result must be retained or handed on, use a small card:
@Context is part of the card's retrieval name; it names no universal Context. CaseScopeOrModelUseBoundary names the actual project, discipline, scene, product-family, publication, or model-use boundary. This boundary stops a local trend from becoming the whole culture merely by wording. PublicationRefs is optional: when a publication distinction matters, name only the exact E.17 source-backed face or exact E.24.PUB publication occurrence, publication form, presentation carrier, audience-declaration episteme, bounded-use-declaration episteme, or availability claim needed by this case. The card does not require a complete publication record. Actual access, reliance, use, and Work stay outside this field unless their own direct relations or occurrences are separately current.
Variants may be generated, retained, inherited, or observed. An archive or front claim still uses C.18 or C.19.
Expand the card only when later use needs more detail. Possible additions include direct participation or position relations; local system-role kinds, separate System-classification judgments, assignment species and obtaining occurrences; Work and Method families; Method relation structures and descriptions; canon or memory epistemes; recognition and selection regimes; mediation systems or architectures; characteristic spaces; style or tradition term rows; publication relations; measurement; and refresh. Each addition identifies its own object or obtaining relation; the card creates none of them.
The card is optional. It is not a root U-kind, lifecycle step, evidence, decision, publication authority, or substitute for the patterns that define or test its referenced claims.
Working scope
Many current projects no longer develop one isolated object. They shape evolving sets, for example product families, methods, research directions, medical and pedagogical practices, AI-agent frameworks, artistic styles, engineering traditions, canons, archives, frontiers, and recognition regimes. The project often generates variants cheaply, while the hard work shifts to the relations that determine what is produced, recognized, retained, selected, used, changed, or kept current. That work can include, for example, problem production, characterization, archive stewardship, comparison, selected-set result declaration, actual publication, local choice, performed Work, effect measurement, and refresh.
Cultural evolution is current when the question is how a collective or discipline generates, transmits, recognizes, selects, retains, or changes variants. Memory or canon epistemes, recognition and selection relations, comparison, platform or algorithmic mediation, and changing Method families may all matter.
When the case says that Work was performed, recover each exact actual performer through A.13 and let A.15.1 independently admit the dated Work occurrence and enacted Method. Add A.2.1 and F.6 only when the case or receiving use expressly represents precise assignment-bound attribution; missing or failed F.6 leaves the Work intact. A local system-role kind, classification judgment, assignment species, assignment occurrence, Work occurrence, Method, effect claim, responsibility relation, and family description remain separate.
This pattern gives FPF a first-use cultural-evolution case without adding a new top-level part or a root ontology of culture. The same pattern can serve engineering product families, scientific research programs, medical disciplines, pedagogy, music styles, dance styles, organizational cultures, and AI-agent framework evolution because it begins with existing FPF objects and relations rather than domain labels.
Problem
Culture, style, tradition, genre, scene, practice, platform, regime, technique, and developmental-machinery wording is useful but dangerous. In source and project prose, one label may point, for example, to:
- a method family or method relation structure;
- a work family or family of performed works;
- an exact local system-role kind, its classification judgment, or a separately obtaining system-role-assignment occurrence;
- a discipline or collective holon;
- a canon or memory episteme;
- a recognition, selection, measurement, or visibility relation;
- a mediation system, product architecture, platform architecture, or algorithmic mediator;
- an archive, front, current pool, selected set, lineage, or edition set;
- a publication label or cross-context term bridge.
If the project accepts the word as ontology, FPF grows a second ontology beside method, Work, system-role kind and assignment, discipline, episteme, architecture, selection, publication, and refresh. If the project hides the case as an example inside open-ended search, the cultural-evolution question becomes invisible and the first useful move is lost.
Forces
Solution
First state the cultural-evolution case in ordinary language: what collective or discipline-facing activity is changing, which variants are in play, which relations transmit, recognize, select, retain, or mediate them, and what next action follows. Then use the applicable FPF pattern only for a claim whose definition or test matters.
An admitted System may perform dated Work, and that Work may enact a Method. Work and Method families may organize comparison. Canon or memory epistemes, recognition and selection relations, mediation systems or architectures, measurement or visibility relations, and publication forms may preserve, transmit, select, suppress, or refresh variants.
These are separate facts. For every claimed Work occurrence, recover each exact actual performer through A.13 and let A.15.1 independently admit the Work. Add assignment and F.6 only when the case or receiving use expressly represents precise assignment-bound attribution. A case card does not make a family, assignment, Method, episteme, or selected structure act.
Cultural-evolution engineering proposes or performs a deliberate change to one or more of these relations. Proposal, performed Work, actual transformation, measured effect, responsibility, authority, selected structure, and publication are different claims. Name each only when its own predicate obtains.
Keep a project choice separate from what happens across a practice or population. A project may choose or authorize an intervention, but that does not show that variants were transmitted, recognized, selected, retained, or lost. Conversely, observed spread or persistence does not authorize the project action or show that it succeeded. When both questions matter, record the project choice and performed intervention through their own patterns, then record the cultural relations and their observed change here.
When the question is how the practice may develop, keep more than one serious hypothesis and name an observation that would distinguish them. Use B.5 and B.5.2 for hypotheses and their testable consequences. Use A.3.3 when the claim states a state space and transition law, and use C.28 when the current use relies on a causal claim. During ongoing Work, use A.15.7 to choose the next action. Use C.11 only when a named deciding System already knows what it is deciding, has an already formed set of options, and another observation can change the choice. Without that bounded choice, use the applicable DPF or field Method for experiment or probe design. Use A.10, C.16, and C.27 for evidence, measurement, and time limits.
Use only the smallest form the current task needs:
CulturalEvolutionCaseCard@Contextkeeps a multi-relation case together;StyleTraditionTermBridgeTable@Contextkeeps a familiar local label connected to the recovered FPF value or relation;CulturalEvolutionInterventionCard@Projectretains an intervention when proposal, Work, effect, or later comparison needs explicit identity.
These forms assemble existing FPF values. They do not mint U.Culture, U.Style, U.Tradition, U.Practice, U.Genre, U.Scene, U.Technique, U.Platform, U.PlatformRegime, U.MeasurementRegime, or U.DevelopmentalMachine.
Style And Tradition Term Bridge
Use a term bridge when a source or project label must remain usable across contexts.
The table records term use and any actual bridge. F.17 supplies durable term rows, F.18 supplies naming restoration, and F.9 defines bridge relations. C.36 uses the result only to keep the cultural-evolution case connected to those exact contributions.
For music and dance, a label such as prog, post-prog, contemporary, hip-hop, battle, TikTok dance, canon, school, or technique may point to different FPF values in different contexts. The bridge row says which one is current before the project relies on the label.
Intervention Card
Use an intervention card when a project must retain the identity of a proposed or performed intervention. First write the ordinary claim: what relation will change, by what proposed action, what effect is expected, how it will be measured, and what would stop or redirect the attempt. For example: The festival will change jury feedback timing; adoption in the next teaching cycle is the measured effect; use A.15.2 for the plan and A.3.4 only if an actual change later obtains.
Keep proposal and performance separate. The full card below is an assurance expansion, not a first-use form.
Open its Work, assignment, transformation, effect, architecture, and publication fields only when those identities matter. AffectedMediationSystemOrArchitectureRefs names actual mediating Systems or architectures only. Publication refs name only the exact objects needed by the intervention; omit them otherwise. Actual access, reliance, use, and Work stay outside this field unless separately current. If actual performance is claimed, recover each exact performer through A.13 and let A.15.1 independently admit the U.Work. Add assignment and F.6 only when the card or receiving use expressly represents precise assignment-bound attribution; missing or failed F.6 leaves the Work intact. Add actual change and a Work-to-change relation only when each independently obtains. An effect can obtain without manufacturing a performer, assignment, or Work. Recover unresolved claim-bearing role wording through E.10.ROLE; a local system-role kind and classification judgment remain independently optional.
@Project is part of the card's retrieval name. It establishes no project entity, composite-work identity, context, authority, viewpoint, or parthood.
When the card is used in an actual project, ProjectWorkOccurrenceRef identifies the composite U.Work, and InterventionCardProjectUseRelationRef identifies the direct relation by which that Work uses the card. The suffix or either reference alone establishes no project locality. The proposed intervention, card, and project Work remain separate.
Use the expanded identity fields only when a later claim or comparison needs them. For performed intervention Work, recover each exact actual performer through A.13 and let PerformedInterventionWorkRef name an independently admitted A.15.1 U.Work. PerformedInterventionWorkAttributionRefs, assignment species, and assignment occurrence are optional and appear only when the card or receiving use expressly represents precise assignment-bound attribution through the same obtaining A.13 assignment. A proposal omits Work and attribution fields. A local system-role kind and classification judgment remain optional and separate. Assignment establishes no classification, Work, capability, functioning, authority, or responsibility.
Responsibility and change. A positive responsibility claim needs an admitted domain predicate through TargetedRelation or EffectClaimOrRelationRefs; otherwise return A.6.RCD's missing-governor. ActualTransformationRefs may cite only changes independently identified under A.3.4.
Flow representation. TransformationFlowStructureRef may cite an E.18 transformation-flow structure selected under A.22. Membership or adjacency in that structure proves neither actual change nor a Work-to-change link.
Work-to-change. A positive link from intervention Work to an actual transformation or effect needs a direct predicate that obtains for those participants, an exact A.6.1 application binding when that declaration supplies the link, or an admitted A.6.RCD local claim. If none applies, return the reason-specific non-assertability result.
Effects and production. A.15.PROD answers only its production-work, entity-inception, or completion question; it does not supply the Work-to-change link. An effect that does not require Work stays on its own direct relation. Observing a value neither creates nor proves the effect.
The intervention card does not authorize Work, and its targeted relation does not assert that an effect obtains. It keeps the proposed intervention, targeted relation, and next applicable pattern together.
For planning and performance, use E.18.1 for P2W carry-through, A.15.2 for work planning, A.13 and A.15.1 for exact actual performers and independently admitted Work, and A.2.1/F.6 only when precise assignment-bound attribution is expressly consumed. Use A.3.4 for actual change. A.15.PROD may answer one current production-work, entity-inception, or completion question; the Work-to-change link still uses the direct predicate, A.6.1 binding, A.6.RCD local claim, or non-assertability result above.
For archive or pool treatment use C.18 or C.19; for a selected-set result use G.5; for local choice use C.11; for carrier admission before architecture use C.35; for an architecture question use C.30; and for refresh use G.11. If audience availability is current, use E.17 for a source-backed publication face and return to source, and E.24.PUB for the publication occurrence, form, carrier, audience, bounded use, and availability.
Evolution Sense Split
When generic development or evolution wording still hides the changed or represented subject, needed continuity or membership, posture, direction or value basis, or direct owner, enter through E.10.DEV before this split. A recovered cultural-population or discipline-facing variant claim may continue here. A non-cultural population or lineage without an admitted owner remains the exact architecture gap returned by E.10.DEV; do not substitute C.36. Open E.10.MOVE afterward only when a separately relied-on trajectory, route, path, ordering, posture, or representation ambiguity remains.
Then use this cultural split:
An engineering development loop may use C.36, but it does not automatically become cultural evolution. It becomes C.36 work only when the collective-holon or discipline-facing cultural-evolution relations above are current.
Platform, Regime, And Attractor Wording
Recover the current object before accepting platform, regime, or attractor wording.
- Platform, recommendation environment, visibility infrastructure, algorithmic mediator, or platform-regime wording may name a System, a System classified under a local system-role kind, another relation participant, a system or product architecture, recognition or selection relation, measurement or visibility relation, publication relation, model-use boundary, project scope, or source-currentness relation.
- Measurement regime wording may name a characteristic space, measurement relation, visibility relation, publication relation, dashboard relation, source-currentness relation, or comparison setup.
- Attractor, basin, stable-dynamics, state-transition-law, and mathematical-model wording uses
A.3.3,C.27, andC.29when that claim is current. Loose style metaphor remains term and bridge work throughF.17,F.18, andF.9.
Archetypal Grounding
Tell. The dance-school sentence in the Problem frame is the minimum case: teachers transmit variants through teaching; an archive retains and presents records; recognition and peer copying supply their own selection relations; and one proposed intervention targets how variants enter the syllabus without claiming success.
Show. The engineering-product-family and music-and-dance slices below show how unlike projects recover Methods, Work, variants, memory epistemes, recognition or selection relations, mediating Systems, and refresh without inventing one root culture kind.
Show again. The AI-agent slice separates a project's benchmark choice from performed change and from later evidence that a wider practice generated, copied, recognized, selected, retained, or lost variants. The neighboring-boundary table then gives reduced non-use cases for claims that stay with their direct patterns.
Engineering Product Family
An engineering lead has an archive of candidate cooling-module designs, a Q-front over energy use and maintainability, competitor product families, and a roadmap pressure to keep more than one line current. The first C.36 question is not "which module is best?" but whether the project is shaping a product-family culture: shared methods, work products, review criteria, memory epistemes, exact local system-role kinds and any obtaining assignments needed for Work attribution, architecture-candidate generation, selection regimes, and refresh rhythm.
If the question is only archive or front treatment, use C.18 and C.19. If the team is changing how the engineering organization generates, recognizes, retains, compares, and learns from module variants, write a CulturalEvolutionCaseCard@Context and then use E.18.1 to carry the accepted problem-side distinction into the next use. When that work yields a generated or discovered carrier that carries or describes selected structure and may enter architecturing, use C.35 for carrier admission before C.32; the cultural-evolution case remains in C.36.
Music And Dance Style Engineering
A dance community uses the same label for a battle practice, a theater style, a short-video platform format, a pedagogy, and a canon. C.36 starts by writing a style or tradition bridge row:
The bridge row is not enough when the project is changing the style ecology. Then write the case card:
The next project move may be [C.18](/generated/patterns/C.18) archive generation, [C.19](/generated/patterns/C.19) current-pool treatment, [G.5](/generated/patterns/G.5) selected-set result declaration, or an intervention card that targets recognition, pedagogy, canon, or platform mediation. If publication is current, use [E.17](/generated/patterns/E.17) for a source-backed face and source return and [E.24.PUB](/generated/patterns/E.24.PUB) for the publication occurrence and audience availability. The card alone does not prove that the targeted change occurred.
If the case also claims a new level, new holon, model-use or scope reframe, feedback-down relation, whole reidentification, cross-scope frustration residual, or interlevel ethical conflict, keep the C.36 result and test the additional claim separately.
For example, use B.2 or B.2.P for MHT and whole reidentification; A.1 or the applicable System or holon pattern for kind and boundary claims; B.2.5 for an obtaining supervisor-subholon feedback relation; C.30.ILC and C.29 for cross-scope architecture residual or mathematical-lens use; and D.2, D.3, or D.4 for value, harm, responsibility, or admissible sacrifice across levels.
AI-Agent Framework Culture
A team develops several AI-agent framework variants and notices that evaluation dashboards change which agent patterns the community copies. The cultural-evolution case includes agent-framework method families, work products, benchmark or dashboard publications, recognition and selection regimes, mediating systems, memory epistemes, and refresh. The case keeps those values visible before the project decides whether to change the benchmark, generate new variants, declare a selected-set result, publish it, or revise the method family.
If the team chooses a new benchmark, that is a project choice, not evidence that the wider practice selected it. Record the choice with C.11 and any planned or performed change through the applicable Work and change patterns. Use C.36 separately for later evidence that agent patterns were generated, copied, recognized, selected, retained, or lost across the practice. Widespread persistence does not retroactively authorize the project choice.
Neighbor boundaries
Bias-Annotation
Scope: Limited to cultural-evolution questions about variants and their generation, transmission, recognition, selection, retention, loss, mediation, and deliberate influence across one named practice, population, collective, or Discipline boundary. C.36 is not a universal culture ontology, a project-authority rule, or a claim that every evolving engineering object is cultural evolution.
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
Positive consequences:
- cultural-evolution work becomes a visible first-use pattern instead of disappearing into examples;
- style, tradition, practice, platform, regime, and technique labels remain usable without becoming root kinds;
- engineering development loops, cultural-evolution cases, archive and front relations, selected-set result declaration, publication, and refresh stay distinct, with the definition and test for each current claim applied;
- music, dance, science, medicine, pedagogy, organization, product-family, and AI-agent cases can share one FPF modeling line.
Costs:
- first use must name more than one value; a cultural-evolution case is not captured by one label;
- projects must decide whether their question is variant-set generation and retention, cultural-evolution structure, architecture work, local choice, or refresh;
- durable style and tradition terms need term rows and bridge refs when they cross contexts.
Rationale
C.36 keeps a complex practical situation usable by naming a small bundle of existing FPF objects and relations instead of minting a root kind for every source word. This preserves the gain from cultural-evolution and open-ended-engineering sources while leaving Method, Work, system-role kind and assignment, discipline, episteme, selection, architecture, publication, and refresh claims with the patterns that define or test them.
SoTA-Echoing
Source-use currentness. One row's adopted move, rejected overread, and named field or boundary form the smallest source-use decision and stay current only until its cited edition changes, a materially newer cultural-evolution or algorithmic-mediation result challenges that transfer, the current QD/OEE line changes its archive, front, pool, selection, or refresh account, or a directly consumed FPF interface changes. At that trigger, recheck only the affected row and exact field or boundary; revise or withdraw an unsupported transfer and leave unrelated rows current.
Relations
Builds on: A.1, A.2.1, A.3.1, A.3.2, A.3.4, A.15, A.15.1, A.15.6, A.15.PROD, A.22, C.18, C.19, C.20, C.23, E.18, E.18.1, F.6, F.9, F.17, F.18, G.5, and G.11.
Coordinates with: E.10.DEV for generic development or evolution wording before the cultural case is known, E.10.MOVE for a remaining independent trajectory or path ambiguity, C.36.P for cultural-evolution wording repair, A.3.3, A.6.1, A.6.RCD, C.11, C.16, C.27, C.29, C.30, C.30.AD, C.30.ASV, C.32, and C.35.
C.36:End
Use-Bounded Representation Selection and Co-Use
Type: Method pattern Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Plain name. Selecting and using representations for one action.
Use this when. One person, team, organization, or other consuming System must take one exact action or make one exact decision, and several diagrams, tables, models, records, plans, descriptions, views, notations, or other results may each support only part of that use.
This is the one-use selection branch of representation work. The governed move is to decide how the receiver may use independently governed candidate results for that exact action. C.37 does not decide what those results are, whether their subject-side claims obtain, whether an episteme is a view, whether a graph is mathematically admitted, whether evidence may be relied on, or whether the receiving action is authorized. Those answers remain with their direct patterns.
Primary working reader. A practitioner who has more than one plausible way of seeing or carrying information into an action and needs a defensible selection without building a universal representation taxonomy.
First useful move. Name the receiving System and exact action or decision in one sentence. For each candidate, name the direct result it already has, the exact claim this use would rely on, what the candidate exposes and withholds, and the direct result that permits, declines, or leaves that use unresolved. Stop after one row if one row is enough.
First useful result. One logically complete use-bounded representation-selection account: one or more completed candidate rows plus the exact receiving action those rows support, decline, or leave unresolved. Its join key and use boundary are <receiving System, exact action or decision>. If the account is retained as a standalone claim-bearing object, it has the ordinary C.2.1 identity of its claims, exact EntityOfConcern, and effective reference scheme; the join key does not replace episteme identity.
What goes wrong if missed. A readable diagram is treated as a conforming view; provenance is treated as approval; an evidence classification is treated as permission; several adjacent results are treated as one coherent structure; or a choice made for one action silently travels into another action with different loss, evidence, and decision conditions.
What this buys. The practitioner can say which candidate is selected, declined, or unresolved for one use; which exact claim is being carried; what remains hidden or transformed; what direct result supports the use; and what change requires return or reconsideration.
Not this pattern when. Use the direct pattern and stop when it already returns the complete one-result/one-use selection and limits. Use E.17.0 for view conformance, C.29 for a mathematical-lens use, A.6.3.RT for changing representation while preserving content, A.22 for selected structure, C.13 for a construction or collection question, E.24.PUB for publication, and C.2.P.DR for declarative-representation overread. Use C.37 only when the receiving action still needs the cross-kind selection account after those direct results are available.
Problem
Representations are useful because they foreground different things. A workflow diagram may expose order while hiding effort. A work plan may expose intended timing while saying nothing about actual performance. A work record may expose an observed breakdown while saying nothing about whether a proposed change will repair it. A graph may support traversal or calculation while omitting distinctions needed by a receiving decision.
The practical question is therefore not “which representation is best?” It is “which exact candidate result may this receiver use for this action, for which claim, under which limits, and what direct result makes that use available?”
Five recurrent shortcuts make the answer unsafe:
- Object shortcut. A label such as diagram, view, model, graph, or record substitutes for the direct result that identifies the candidate and its subject-side claim.
- Classification shortcut. An A.2.4 intended first evidence-use classification is treated as evidence sufficiency or permission.
- Provenance shortcut. A source path, current carrier, or authentic publication is treated as a positive
RelianceDispositionor receiving result. - Decision shortcut. A selected row is treated as choosing, authorizing, permitting, or passing a gate without the direct receiving pattern.
- Composition shortcut. Several rows are treated as a collection, structure, integrated view, world model, or graph merely because one receiver reads them together.
Forces
Solution
Use one action spine:
- name the receiving System and exact action or decision;
- recover each candidate and its direct subject result;
- separate the direct subject result, optional first-use classification, bounded reliance, receiving result, and auxiliary facts;
- state what the candidate exposes or preserves and what it withholds, loses, transforms, or leaves uncertain;
- mark the row
select,decline, orunresolvedfor the named use and give its return trigger; - co-record only rows that support the same receiver and exact action or decision.
Local mantra. One receiver, one action. Recover each candidate under its direct pattern. Name the claim, reliance, loss, receiving result, disposition, and return. Put rows together only for that action.
The mantra is a recall aid, not a decision rule. The receiving pattern still emits the choice, gate, permission, authorization, or domain result.
Fix the receiving use before inspecting candidates
Write one sentence:
Every row in the account uses that same receiver and action. A diagram used to select a proposed Method edition and the same diagram used later to tailor that Method belong to different accounts. Adjacent actions, one project, one carrier, or one meeting do not merge their use boundaries.
If one direct pattern already returns the complete representation–operation choice and limits for this use, take that direct exit. Do not add C.37 merely to rename its result.
Recover each row through five separate layers
Open only the layers required by the attempted use.
If a layer required by the attempted use is negative, missing, or unresolved, do not borrow support from another layer. Decline the row or mark it unresolved and name the missing fact or direct result.
State exposure, loss, and the row disposition
For each candidate, state only distinctions that change the receiving action:
- what it exposes, foregrounds, or preserves;
- what it withholds, omits, loses, transforms, or leaves uncertain;
- the exact claim for which it is selected or declined;
- the direct result and, when material, A.10 disposition that bounds that claim;
- the condition that sends the reader back to the source or reopens selection.
Use exactly these ordinary row dispositions:
Selection is use-bounded. It does not make the candidate true, complete, current, published, conforming, relied on, assured, or authorized outside the exact claim and action stated in the row.
Use the smallest complete account
Use this readable shape when the result must be retained:
One row is a valid minimum when C.37 still adds a needed layer separation. If the direct pattern already supplies the same complete one-result/one-use answer, use the direct exit instead.
This is a logical claim group, not a universal record kind, U.Representation, RepresentationOf relation, taxonomy, manifest, view family, collection, or structure. Do not give it another schema merely because several domains use the same questions.
Realize the result once
Use one deterministic realization rule:
- If an owning domain result already carries this same receiving use, embed the complete row claims and action boundary in that result.
- Otherwise retain the complete account as one ordinary C.2.1 episteme.
- Never create both an embedded copy and a standalone duplicate for the same use.
Embedding does not weaken the required separation: direct subject result, optional A.2.4 classification, A.10 reliance when material, receiving result, exposure and loss, disposition, and return trigger all remain recoverable. A cross-use ensemble may later relate several accounts under its own direct pattern; C.37 does not perform that later organization.
Keep co-use local to one action
Co-use means only that the same receiver relies on two or more completed rows for one exact action or decision. Each row keeps its own direct result, premise, reliance boundary, loss, and return trigger. One positive row cannot repair another row's missing subject result or reliance path.
Co-use does not establish:
- one collection or selected structure;
- one multi-view family or mutual conformance;
- one integrated model or coherent world account;
- one constructional whole or composition relation;
- one shared representation scheme, graph, or correspondence;
- one assurance result or authorization.
Open C.13, A.22, E.17.0, C.29, a domain integration pattern, or another direct governor only when the receiving action depends on that additional claim.
Recognition, reliance, assurance, and action remain separate
Recognition asks what the candidate is and which direct result or relation obtains. A.2.4 may add only its first evidence-use or status-use classification. A.10 adds one bounded evidence-provenance and reliance result only when the exact use relies on evidence. B.3 enters only when an actual named assurance claim is current; consequence or reuse alone does not require an assurance package. The receiving pattern then owns the action result.
This split lets ordinary reversible work stop cheaply. A practitioner may inspect or compare a candidate under its direct result and visible limit without opening A.10 or B.3 when no evidence reliance or assurance claim is being made. When reliance is material, the exact path and disposition become mandatory for that use.
Direct exits and boundary cases
Archetypal Grounding
Method change selected for one bounded trial
MethodEngineer-ME1 must select or decline MethodChange-MC7 as the proposed Method edition for one bounded trial in planned Work item WP4. This one decision is the join key for all three rows. A C.11 ChoiceResult, or the corresponding direct Method Engineering decision result, owns the selection.
The resulting account does not say that three rows jointly prove MC7. It says which bounded premises the receiver may use, what each leaves out, and which C.11 result follows under those limits. If the same diagram is later used for a tailoring choice or W19 for a learning decision, start another account.
Failed diagram use
A release team receives a polished architecture diagram and wants to authorize deployment. E.24.PUB establishes that the diagram edition is available through a current carrier. C.2.P.DR repairs one route-shaped arrow that had been read as operational authority. Neither result establishes view conformance, a representation correspondence, runtime structure, evidence reliance, or deployment permission. Until the needed direct subject result, A.10 path and disposition, and permission or gate result are available, the row is unresolved; visual polish and provenance cannot upgrade it. If the direct release gate or permission pattern instead returns a negative result because its required basis is absent, the row is decline; classification, publication, provenance, and repair facts cannot override that direct result.
Bias-Annotation (informative)
Conformance Checklist
Common Anti-Patterns and How to Avoid Them
Consequences
The gain is a small, repeatable bridge from heterogeneous results to one practical action. A practitioner sees exactly why each candidate may be used, what it cannot support, and where the decision must return when sources, conditions, or reliance change. Domain results remain authoritative and can embed the claim group without duplicating it.
The cost is disciplined incompleteness: some attractive candidates remain declined or unresolved because publication, provenance, classification, or visual form cannot supply a missing direct result. That cost is preferable to an account that looks integrated while borrowing warrant across incompatible layers.
Rationale
The receiving use is the smallest stable boundary shared across domains. Representation kinds, correspondence relations, view predicates, plan claims, Work records, mathematical objects, and decision results do not converge on one ontology, but practitioners repeatedly need the same action sequence over them: recover the direct result, state the relied-on claim and loss, test bounded reliance when material, obtain the receiving result, and select, decline, or stop.
Co-use is chosen instead of composition because the rows need not form a new whole. The same receiver may use them together while every candidate and relation retains its own identity, predicate, and return condition.
SoTA-Echoing (informative)
Reopen this source use when newer representation, provenance, view, or decision practice supplies a lower-effort way to keep the same direct-result and receiving-action boundaries, or when real interoperability requires a common standalone account kind that cannot preserve them through ordinary C.2.1 identity and direct references.
Relations
- Builds on:
C.2.1for any standalone account episteme and for the identity of claim-bearing candidate results. - Coordinates with: the direct pattern governing each candidate's subject result;
A.2.4for optional first evidence-use or status-use classification;A.10for evidence-provenance and bounded reliance; and the direct choice, gate, permission, authorization, acceptance, or domain pattern for the receiving result. - Coordinates with:
E.17.0for view conformance,C.29for mathematical-lens use,E.24.PUBfor publication,A.6.3.RTfor representation transitions,A.22for selected structure,C.13for construction and collection boundaries, andC.2.P.DRfor declarative-representation overread repair. - Used by: domain patterns only when differently governed candidate results must support one exact receiving action and the direct one-result/one-use path is not already complete.
C.37:End
Construct Comparable Ways to Obtain One Result
Type: Method pattern Status: Stable Normativity: Normative unless explicitly marked informative
Problem frame
Plain name. Turn labels such as build, buy, reuse, provider, internal team, outsource, or AI into comparable complete ways of getting the same result.
Use this when. A person, team, organization, or other deciding System must choose how one named result will become available, but its candidate list mixes relations, performers, Systems, Methods, commercial labels, and enabling branches. The rows do not yet seek the same result or expose the same burdens, so sending them directly to C.11 would create a false choice.
Primary reader. The practitioner preparing decision-ready alternatives for one receiver. The pattern forms candidates; it neither chooses for the receiver nor realizes a retained way.
First useful result. A finite same-result comparison containing at least two materially different complete-enough possible-future ways, one shared parity basis, explicit supported/proposed/unknown premises and gaps, and the truthful next handoff. When choice is current, hand the resulting OptionSet to C.11; its ChoiceResult is separate. For a retained way, name the first unsupported realization branch.
What changes in practice. Instead of comparing buy against AI or internal as if the labels were peer kinds, the practitioner asks how each whole way could make the same accepted result available. Duplicate labels merge, materially different ways under one label split, and omitted integration, evidence, support, capability, custody, resource, consequence, and exit burdens become visible before commitment.
Cheap non-use. Stop if a direct domain Method already returns the complete useful comparison for this result and use, if one mandatory path leaves no real comparison decision, or if a complete OptionSet already exists and only C.11 is needed.
Not this pattern when. Use A.15.9 for one missing or unqualified bounded result from another practice; C.18 for open-ended generation or reframing; C.19 for live-pool exploration policy; C.32 for architecture-candidate synthesis; A.15.8 for one actual-Work or present-WorkPlan support configuration; and the direct domain Method for realization, production, provision, contracting, acceptance, or use.
Problem
Common option labels name unlike things. Buy may name a purchase relation, provider a continuing arrangement, internal a performer location, reuse an already available System, AI one possible Agent, and build many kinds of Work. Two labels can describe the same whole way, while two offers carrying the same label can differ in integration, custody, support, evidence, capability, and exit enough to reverse the choice.
The error is not merely missing detail. If candidate rows seek different results, use different acceptance bases, or silently switch situations and horizons, no amount of scoring restores comparability. If possible-future rows are written as facts, the table also invents capability, authority, Work, provision, delivery, acceptance, and availability.
The needed move is to fix one result question, construct complete-enough materially different ways on one parity basis, keep premise modality visible, and freeze only truthful candidates for choice. It is smaller than a procurement or architecture programme and more complete than a make-or-buy label table.
Forces
Solution
Fix one result, receiving use, situation, horizon, and acceptance basis. Construct at least two materially different complete ways by resolving labels into the Agents, Work, Methods, Systems, values, relations, conditions, and enabling branches that can change this decision. Ask the same decision-changing questions of every way, preserve unknowns, then freeze only complete-enough ways for C.11.
Follow the seven-step same-result sequence
- Fix one result question. Name the sought result by its direct governed kind, the receiver and use, applicable configuration or situation, horizon, acceptance conditions, deciding System, authority boundary, and commitment the decision may make. If rows seek a System, performed service, capability, access relation, and episteme interchangeably, split the questions before comparing.
- Recover available inputs and exact gaps. Use already-available subject and specialist results only where they fit the same question. Apply
A.15.9only when one bounded result from another practice is missing or needs qualification. That request or return is an input to a way, not the whole way and not the choice. - Construct at least two materially different complete ways. Use labels only as prompts. For each surviving way, describe the relevant proposed or already-available Agents, Work, Methods, Systems, values, provision or access relations, enabling branches, and conditions through which the same result could become available. Mark every decision-bearing premise as supported now, proposed, or unknown. Merge labels that resolve to the same decision-changing contents; split ways under one label when a content difference can change the choice. If no second way can be supported, return the missing-alternative or search gap rather than fabricating a peer.
- Use one decision-changing parity basis. Ask the same bounded questions of every way: result and availability condition; performers, Work, Methods, and means; production, transfer, provision, access, custody, or ownership; fit, interfaces, integration, and configuration; evidence, uncertainty, and assurance; support, maintenance, change, exit, and recovery; capability consequences; resources; and consequences for affected Systems. Omit a group only when it cannot change this choice. Keep a decision-reversing unknown as a visible gap.
- Restore comparability without forcing totality. Keep the result, receiving use, acceptance conditions, situation, configuration boundary, evidence horizon, and burden categories shared. Use ordinary comparison when the ordering is direct. Use
A.19.CPMandA.19.SelectorMechanismonly when evidence gates, partial orders, incomparability, abstention, or set-valued retention matter. Do not hide protected conditions inside an unexplained score. - Freeze and hand off a finite option set. Put only complete-enough whole ways into the current
OptionSet, with gaps that the chooser can see. Then applyC.11for local choice. Its result may choose one way or a retained tie-set, reject the current set, probe again, or reroute.C.38does not choose by implication and does not gain the chooser's authority. - Name the truthful continuation and reopen. For a retained way, identify the first unsupported realization branch or the direct pattern that now owns the question. Reopen only when a changed result identity, use, acceptance basis, candidate, specialist result, capability, interface, evidence item, burden, support condition, affected-System consequence, exit condition, or observation can change the comparison or choice.
Use a proportional parity view
There is no universal arrangement schema. For the current decision, a small table or a few parallel paragraphs are enough if another reader can answer these questions for every way:
Delete a row that changes no candidate comparison. Add a local question when omitting it could reverse the choice. A candidate is complete enough when its important means, dependencies, burdens, and gaps are visible to this decision—not when it fills a universal checklist.
Return the first result in plain language
For a small case, use this form:
One result and use: [governed result, receiver, situation, horizon, acceptance basis].
Way A / Way B / ...: [complete-enough contents, premise status, decision-changing burdens, explicit gaps].
Shared parity basis: [questions actually asked of every way].
Next: [hand the finite set to C.11 / return a missing alternative or probe / use the direct domain Method / begin the first unsupported realization branch after a separate choice].
The result is a comparison claim, not an obtaining arrangement in the world. It establishes no actual performer, capability, authorization, Work, purchase, service, production, delivery, acceptance, availability, or use.
Choose the truthful carrier
Use the least burdensome carrier that keeps the comparison recoverable:
- If a domain result already carries the complete same-use comparison and declares this specialization, keep it there rather than producing a second account.
- Otherwise retain one ordinary
C.2.1episteme about the one result-obtaining comparison, with a truthful EntityOfConcern and effective reference scheme. - If a direct domain Method already returns the complete useful comparison more cheaply, use that Method and do not add a
C.38account.
The episteme, table, document, or diagram that carries the claims is not a world-side arrangement, selected Structure, architecture, plan, Work, or result availability. Use A.22, C.30, C.29, E.17, or another direct pattern only when its separate question is current.
Separate recognition from assurance
- Recognition. A candidate list whose labels name unlike things, or whose rows omit different burdens, is enough to open
C.38. Two parallel ordinary descriptions can be enough for a reversible decision. - Assurance. Consequential use checks that every row seeks the same result on the same basis, every actual premise has direct support, modal premises remain modal, protected conditions remain visible, and no omitted burden can plausibly reverse the choice unnoticed. Domain acceptance, assurance, authority, realization, and release stay with their direct Methods.
Worked cases
Greenhouse climate-control result
A project needs one accepted result: a named greenhouse configuration maintains the required temperature and humidity envelope through the next operating horizon. Its first list says build, buy, provider, and AI.
The team resolves those labels into three materially different ways: integrate internally owned equipment and control Work; obtain a configurable control System and perform local integration and operation; or obtain a provider-operated climate-control result with continuing sensing, access, support, and exit dependence. An AI Agent may perform forecasting or tuning Work inside any way; it is not a peer arrangement kind.
The same parity questions expose plant interfaces, commissioning evidence, response to sensor loss, maintenance, operating capability, data access, affected crops, support, and exit. The direct engineering pattern keeps the greenhouse-specific architecture and assurance. C.38 supplies only the same-result formation and comparison, then hands the finite set to C.11. After a choice, the first unsupported realization branch returns to the direct Systems Engineering Method.
A performance recording needs one usable artifact
A music project intends one bounded Music Work occurrence and a recording through which a later learner can recover the required timing and spatial relation. Before production, the project compares a local live-capture way, a specialist mobile-team way, and a venue-service way for that same result and use.
C.38 makes the three proposed ways answer the same fidelity, access, rights, setup, performer-interference, evidence, support, resource, and recovery questions. The comparison remains one standalone ordinary episteme and its finite set goes to C.11; neither result says that performance or recording Work has occurred. After a way is retained, unchanged MDPE.5 integrates the selected production and presentation inputs, tests the load-bearing artistic or participatory relation, and records the actual performed Work, artifact, and unresolved limits separately. C.38 absorbs none of that Work, artistic authority, publication, or rights decision.
Direct Method-base stop
A Method Engineering team needs an enactment-support configuration for one bounded task set. Its direct Method already constructs candidate configurations on one basis, preserves evidence status and incomparability, tests retained routes, and returns a supported configuration, retained set, split, or gap.
Use that direct Method. Adding a C.38 account for the same decision would duplicate its action and result. Open C.38 only if a different wider question appears—for example, several complete ways to make an independently named support result available to another receiver.
Precision restoration
Bias check. Do not privilege the official, fashionable, familiar, widely adopted, or institutionally praised arrangement. Popular practice often describes the previous generation's compromise. Prefer the candidate whose claimed improvement over known weaknesses is explicit and supported for this result and situation. A standard or common provider can still be the best current way, but neither officiality nor popularity proves it.
Conformance and practical checks
A use conforms only when the checks needed by its claimed comparison pass:
- One governed result, receiver, use, situation or configuration, horizon, acceptance basis, deciding System, and authority boundary are explicit.
- At least two materially different complete-enough ways seek that same result. Duplicate labels merge and material differences under one label split.
- Every decision-bearing premise is visibly supported now, proposed, or unknown; modal rows create no actual capability, authority, Work, provision, delivery, acceptance, availability, or use.
- The same decision-changing parity questions are applied to every way; an omitted group is justified by irrelevance to this choice.
- A decision-reversing unknown remains a gap or probe. Protected conditions are not hidden inside one unexplained scalar.
A.19.CPMorA.19.SelectorMechanismis used only when its evidence-gating, incomparability, abstention, or set-return contribution is actually needed.- Only complete-enough whole ways enter the finite
OptionSet;C.11alone makes the local choice and emits theChoiceResult. - The truthful carrier rule prevents a duplicate episteme when an owning domain result already carries the complete comparison.
- A retained way names its first unsupported realization branch, but no realization or later Work is claimed by the comparison.
- The reopen condition names a changed premise or result that can alter the comparison or choice.
Recognition check. Give a cold reader a build/buy/provider/AI list. The reader should be able to name one common result and expose at least one hidden difference or duplicate without inventing an arrangement taxonomy.
Assurance check. For a consequential use, inspect each actual premise under its direct evidence and authority patterns, challenge one omitted burden that could reverse the choice, and verify that the selected domain assurance and acceptance Methods remain outside C.38.
Anti-patterns
- Labels as option kinds. Build, buy, provider, internal, reuse, or AI are compared as peers without resolving their contents.
- Different results in one table. One row supplies a System, another a service, another a capability, and another an episteme, while all are scored as if equivalent.
- Universal arrangement schema. A local parity view becomes a mandatory ontology, graph, taxonomy, or workflow for every domain.
- Modal-to-actual leap. A possible-future row is treated as capability, authority, Work, provision, purchase, delivery, acceptance, or availability.
- Score before parity. Numbers conceal different assumptions, missing burdens, or protected conditions.
- Endless generation. Open-ended candidate invention is kept inside
C.38instead of moving toC.18andC.19. - Choice by formatting. The most detailed or first row is treated as selected before
C.11. - Domain takeover. The common Method absorbs architecture, procurement, contracting, finance, legal, artistic, operational, or assurance decisions.
- Duplicate account. A domain Method already returns the full comparison, but a second generic episteme is added anyway.
Consequences and trade-offs
Rationale and SoTA use
The practice question is how to construct several decision-ready ways to obtain one named result without smuggling in a choice, false actuality, or a domain-specific arrangement schema. The best-known current line is result-first, whole-way, and parity-first: begin with the one receiving result and use, expand every serious candidate into a complete-enough possible-future way, expose the same decision-relevant burdens and limits for each, and only then hand a finite OptionSet to C.11.
The serious default is to list familiar labels such as internal, provider, buy, build, partner, procurement vehicle, or lifecycle stage and score them immediately. Those labels mix unlike grains and hide missing integration, evidence, support, capability, custody, consequence, recovery, and exit burdens. Familiarity, official standing, adoption breadth, recency, or institutional praise can make such rows look credible; none shows that they are complete or comparable ways. C.38 repairs that defect by fixing one result and receiver, resolving every label into a whole possible-future way, applying a bounded parity basis, marking unknowns without inventing current relations, and stopping before local choice or actual Work.
Current SYSE.24 supplies the strongest complete domain comparator and the subtraction boundary: C.38 keeps only same-result candidate formation and the parity move, while Systems Engineering keeps the engineered-System context, engineering arrangement content, specialist boundaries, realization, and assurance. MDPE.5 is a transfer check whose unchanged downstream Method consumes a prior comparison without yielding performance-production authority to C.38. The direct Method-base case is the non-use test: when a domain Method already returns the full comparison, no generic duplicate is added. These sources serve as comparator, transfer, and non-use evidence; their names or institutional positions do not rank an alternative.
A source changes this pattern only when it exposes a defect in the current move or demonstrates a better repair. Reopen the smallest affected candidate or parity question when a decision-changing premise changes; reopen the common line itself only when a current direct pattern supplies the whole move at comparable effort, or evidence shows that result-first whole-way parity systematically hides a burden that changes the decision.
Relations
- Builds on: the direct pattern for the sought result;
A.10for evidence and bounded reliance on actual premises;A.19.CPMandA.19.SelectorMechanismonly for comparison mechanisms that are actually needed; andC.2.1when a standalone comparison episteme must persist. - Hands to:
C.11only after a finite complete-enoughOptionSetexists.C.11owns choose, reject, probe-again, and reroute results. - Coordinates with:
C.18for open-ended generation or reframing;C.19for pool policy;C.32for architecture-candidate synthesis;A.22andC.30only when a separate Structure or architecture question is current; and direct domain Methods for realization, production, provision, acceptance, assurance, and use. - Question-change boundary with A.15.9: use
A.15.9only for one missing or unqualified bounded result from another practice inside a way. Stay inC.38when the question is several complete ways to obtain the same receiving result. A contribution request or return is never the whole way by implication. - Keeps outside: universal arrangement kinds, graphs, taxonomies, schemas, workflows, authority transfer, open-ended search, local choice, and all actual Work or obtaining relations inferred only from possible-future rows.
C.38:End
Cultural-Evolution Wording-Use Precision Restoration
Tech-name:
CulturalEvolutionWordingUsePrecisionRestorationPlain-name: cultural-evolution wording-use precision restoration Type: Precision-restoration companion pattern (C) Status: Stable Normativity: Normative unless explicitly marked informative Placement: Part C -> C.36 companion Builds on:E.10,E.10.ARCH,E.10.DEV,E.10.ROLE,C.36,F.17,F.18,F.9,A.3.1,A.3.2,A.15,C.18,C.19,G.5, andG.11. Purpose: recover the object, relation, or claim hidden by culture, style, tradition, genre, scene, practice, technique, platform, regime, attractor, or developmental-machinery wording, then return to the project question without turning the label into ontology.
Use This When
Use this pattern when source or project prose uses cultural-evolution wording and a current claim or action depends on what that wording means here. If the word is only ordinary or quoted language and no FPF claim relies on it, leave it alone.
When generic development, evolution, or lineage wording still hides the changed or represented subject, continuity or membership, posture, direction or value basis, or direct owner, use E.10.DEV first. Continue here only when that recovery exposes a cultural-population, discipline, style, tradition, recognition, selection, transmission, retention, or mediation question whose wording is still unclear. Use E.10.MOVE only for a separately relied-on trajectory or path ambiguity.
Trigger expressions include, for example, culture, cultural evolution, style, tradition, genre, scene, technique, practice, platform, platform regime, measurement regime, attractor, developmental machinery, cultural lineage, canon, and school. They are recognition cues, not a lexical taxonomy.
What Goes Wrong If Missed
The repair becomes a synonym swap. Style becomes method, platform regime becomes context, practice becomes a generic process label, or attractor becomes dynamics before the sentence says which object, relation, or claim is current. The result looks cleaner but still carries an accidental ontology.
What This Buys
The first result is a short ordinary statement: what the expression means in this use and which pattern supplies the next needed definition or test. For example: Here “platform” refers to the short-video recommendation System and to the visibility and recognition relations around it. The claim is that changes in those relations altered which dance variants were copied; use C.36 for the cultural-evolution case and C.18 only if archive retention is the next question.
Use C.36 for a cultural-evolution case. For a Method, Work, discipline, bridge, archive, pool, selected-set result declaration, publication, architecture, dynamics, measurement, choice, or refresh claim, use the pattern that defines or tests that claim.
First Useful Move
Write the short ordinary statement first. Stop when it makes the next project action clear.
When a handoff or repeated use needs durable memory, keep the same result in this optional line:
Fill only the fields the receiving use needs. If the object, relation, claim, or applicable rule cannot yet be recovered, keep the label as quoted source wording, ordinary prose, or a blocked-use cue. Do not choose a smoother umbrella word merely to fill the line.
Problem Frame
Cultural-evolution sources and project documents use compact labels because ordinary language has to move quickly. A word such as style, genre, practice, platform, or technique may be a useful local sign. It may also hide one or more distinct objects, relations, or claims—for example a Method family, Work family, local system-role kind, System-classification judgment, assignment species or occurrence, direct participation relation, discipline, canon or memory episteme, recognition relation, selected set, archive, front, mediation System, architecture, measurement relation, publication label, or mathematical-lens claim. Ambiguity alone does not prove that several of these claims are present.
C.36.P does not decide the cultural-evolution case; C.36 does that. This companion recovers only enough meaning to write the ordinary claim and use the pattern that defines or tests the next needed distinction.
Problem
Without the repeatable recovery move above, each cultural-evolution phrase gets repaired locally. That creates four failures:
- source labels become root kinds by spelling;
- platform and regime labels become hidden Systems, scope containers, or authorities;
- style and tradition labels become genre trees or single trajectories;
- developmental-machinery and practice labels become method, work, or process labels by taste rather than by current relation.
The repair must keep useful local labels while stopping them from carrying unearned ontology.
Forces
Solution
Use the intended claim, not the trigger word, to select the result. Write the short ordinary statement, then open only the branch whose distinction changes the next action. The branches below name common routes; their trigger lists are examples, not a new cultural-language taxonomy.
Before these cultural routes, send unresolved generic development or evolution wording to E.10.DEV. Return here only when its repaired claim has a cultural-evolution subject and a cultural wording question remains; preserve its ordinary non-use, missing-information result, non-cultural population or lineage architecture gap, and one-pass stop otherwise.
-
Cultural-evolution case. Use C.36 when the claim concerns how a collective or discipline generates, transmits, recognizes, selects, retains, or deliberately changes variants. Method and Work families, system-role facts, canons or memory epistemes, mediation, style or tradition terms, variant sets, and interventions remain separately identifiable inside that case.
-
Term and bridge work. Use F.17 and F.18 when a durable source or project term needs a stable local meaning or name. Use F.9 only when an actual relation between distinct source-local cells is current. Keep C.36 only for the cultural-evolution case that makes the term matter.
-
Practice, technique, and developmental-machinery wording. Ask what the phrase names:
- For a reusable way of doing, use A.3.1; for a description of that way, use A.3.2; for a plan, use A.15.2; and for dated doing, use A.15.1.
- If several Methods are related or assembled, use A.3.1's method-relation route; it keeps ordinary relations, order-sensitive composition, and a selected Structure distinct.
- If the wording is about who acts or how someone is assigned, E.10.ROLE separates direct participation, a local system-role kind or classification under A.2, an assignment under A.2.1, and a relation between system-role kinds under A.2.7.
- Use A.1.1 only when the decision depends on bounded model use or one of its direct model-applicability, actual-use, or fixed-content-coherence relations. Use A.10, C.20, or C.23 only when the claim is about evidence use, discipline composition, or method-family maturity.
-
Variant-set, archive, front, pool, selected-set, publication, and refresh wording. Use C.18, C.19, G.5, E.17, E.24.PUB, G.11, or E.18.1 according to whether the next question concerns generation or retention, current-pool treatment, a selected-set result declaration, publication, refresh, or problem-to-work carry-through.
-
Platform, regime, and mediator wording. Do not presume a System. The phrase may identify, for example, a mediating System or architecture, recognition or selection relation, measurement or visibility relation, publication or source-currentness relation, episteme, bounded model-use structure, direct model-use relation, claim scope, or ordinary project label. Admit a System only when that System is the object. Keep any local system-role kind, classification, and assignment separate and optional. If no admitted FPF relation states the intended claim, return A.6.RCD's
missing-governorinstead of inventing a System-plus-relation construction. Do not introduce a holon-in-role value. -
Meta-holon-transition (MHT), level, boundary, feedback, model-use or scope reframe, and frustration wording. Recover whether the claim concerns a new holon or level, whole reidentification, a System boundary, a relation that crosses a holon boundary, supervisor-subholon feedback, bounded model use or claim scope, cross-scope architecture residual, mathematical-lens use, or interlevel ethical conflict. Use A.1, A.1.1, B.2.P, B.2, B.2.2, B.2.3, B.2.4, B.2.5, C.30.ILC, C.29, D.2, D.3, or D.4 according to that recovered claim. Keep C.36 only for the cultural-evolution case.
-
Attractor and dynamics wording. Use A.3.3, C.27, and C.29 only when the claim is about stable dynamics, a basin, state-transition law, temporal behavior, or mathematical-lens use. Otherwise keep the label as style or tradition term work.
-
Architecture wording. Use C.30 for an architecture question or ArchitectureClaim, C.30.ASV for a structural-view question, and C.30.AD for an architecture-description question. A selected structure, ArchitectureRelation, claim, description, view, representation, and publication remain distinct. Treat
ArchitectureOf@Contextonly as a legacy retrieval phrase resolved by the current C.30 edition, not as a current record or ontology.
A C.36.P repair closes when the short ordinary statement names the needed object, relation, or claim and makes the next use or stop visible. The optional recovery line is not required for a clean local repair.
C.36.P does not define or test development-loop semantics, archive or front relations, pool policy, selected-set result declarations, Method-family semantics, measurement, refresh, publication use, or architecture use. It returns each claim to the pattern that does.
Recovery Result Table
The trigger phrases are examples, not a closed lexical kind. Recover the intended object, relation, or claim first; then use the pattern that defines or tests the distinction needed by the next action.
Worked Micro-Examples
"The Platform Changed The Style"
Short ordinary statement: Here “platform” refers to the short-video recommendation System and to the visibility, recognition, and selection relations around it. The claim is that changes in those relations altered which dance variants were copied and retained.
That short statement may be enough. If the result must be handed on or reused, retain it as:
"This Tradition Is An Attractor"
If attractor is a loose metaphor for a stable recognizable style, use a term bridge and C.36 case. If the project claims basin structure, stable dynamics, or state-transition law, use A.3.3, C.27, and C.29 before C.36 relies on the claim.
"Technique As Developmental Machinery"
If technique names a way of doing work, use A.3.1 U.Method. If it names a training plan, use A.15.2 U.WorkPlan. If it names performed rehearsal or production, use dated U.Work. If the same term carries different source-local meanings, use F.17 and F.18; use F.9 only when an actual relation between distinct cells is current. Use C.36 only when the technique participates in a cultural-evolution case.
"The Scene Became A New Level"
If a music or dance source says a scene, platform circulation, or canon “became a new level”, first recover the claim. Use C.36 for a changed recognition regime, C.18 for an archive relation, G.5 for a selected-set result declaration, G.11 for refresh, and F.17, F.18, or F.9 for term and actual-bridge work. A whole-reidentification or MHT claim uses B.2.P and then B.2 or its System or episteme specialization when current. A feedback-down claim uses B.2.5. A frustration or residual claim uses C.30.ILC for an architecture residual, C.29 for a mathematical lens, and D.3 or D.4 for ethical level conflict or mediation.
Boundaries
This pattern does not define the cultural-evolution case or intervention. Use C.36 for those questions.
Use C.36.P to recover one ordinary claim. Keep the optional recovery line only when a handoff or repeated use needs it. Once the meaning and applicable rule are clear, stop the wording repair and return to the project question.
Earlier retrieval text may call the optional line CulturalEvolutionWordingRecoveryLine@Context. In this edition that name resolves to CulturalEvolutionWordingRecoveryLine; the suffix supplies no Context object, scope, relation, or field.
This pattern does not create U.Culture, U.Style, U.Tradition, U.Practice, U.Genre, U.Scene, U.Technique, U.Platform, U.PlatformRegime, U.MeasurementRegime, or U.DevelopmentalMachine.
Relations
Builds on: E.10, E.10.ARCH, E.10.DEV, E.10.ROLE, C.36, F.17, F.18, F.9, A.3.1, A.3.2, A.15, C.18, C.19, G.5, and G.11.
Coordinates with: E.10.MOVE for a remaining independent trajectory or path ambiguity, A.1, A.1.1, A.6.RCD, B.2, B.2.P, B.2.2, B.2.3, B.2.4, B.2.5, A.3.3, C.16, C.20, C.23, C.27, C.29, C.30, C.30.AD, C.30.ASV, C.30.ILC, D.2, D.3, D.4, E.17, and E.18.1.
C.36.P:End
Last Updated: 2026-09-03 — upstream FPF commit b999972c (github.com/ailev/FPF)